Bulut planı satın alma sayfasında duruyorsunuz ve iki sütun görüyorsunuz: birinde «4 vCPU / 8GB RAM / 80GB SSD», diğerinde «2 vCPU / 8GB RAM / 80GB NVMe» yazıyor. Fiyat farkı da az değil. Gerçek soru şu: gerçek yük altında hangi sayı darboğaz olur? Kısa cevap şu ki neredeyse hiçbir zaman ilk baktığınız sayı değildir.
vCPU tam olarak neyi garanti eder
vCPU fiziksel bir çekirdek değildir. Fiziksel çekirdek üzerinde zamanlanmış bir iş parçacığıdır. Bir plan 4 vCPU diyorsa, hipervizörün makinenize her anda dört paralel yürütme iş parçacığına sahip olma izni verdiği anlamına gelir. Bu dört iş parçacığının her zaman dört boş çekirdek üzerinde oturacağını garanti etmez.
Linux'ta gerçekte kaç çekirdeğe sahip olduğunuzu görebilirsiniz:
lscpu | grep -E '^CPU\(s\)|Model name|MHz'
nproc
cat /proc/cpuinfo | grep -c processorEğer nproc 4 sayısını döndürüyor ama lscpu yük altında CPU modelini düşük frekansla gösteriyorsa, muhtemelen paylaşımlı çekirdeklerle karşı karşıyasınız. Bu kötü değil; sadece steal time'ı ciddiye almanız gerektiği anlamına gelir:
top -bn1 | head -5
# %st sütununa bakınSürekli %5'in üzerinde %st değeri, makinenizin CPU sırası beklediği anlamına gelir. %1'in altındaysa sorun başka bir yerdedir ve vCPU yükseltmek para israfıdır.
Daha fazla vCPU ne zaman gerçekten yardımcı olur
CPU-bound yükler: kod derleme, yüksek hacimde TLS şifreleme, görüntü işleme, küçük model çalıştırma. Eğer load average sürekli vCPU sayısından fazlaysa ve %st düşükse, yükseltme mantıklıdır. Eğer %st yüksekse, sorun komşuluktadır, sayıda değil.
RAM: her zaman doğru olan sayı, ama düşündüğünüz şekilde değil
RAM ayrılmıştır. 8 gigabayt 8 gigabayt demektir ve bu plandaki neredeyse hiç belirsizliği olmayan tek sayıdır. Ancak pratikte insanları şaşırtan iki nokta var.
- Arabellek ve çekirdek önbelleği RAM'i ayrı hesaplanır. Eğer
free -hçalıştırıyorsanız veavailablesütununu görmüyorsanız, yanlış sayıyı okuyorsunuz. Yüksekusedile yüksekavailable, sistemin sağlıklı olduğu anlamına gelir. - Ağ diskinde swap felakettir. Eğer planınızda swap varsa ve paylaşımlı storage üzerinde oturuyorsa, her swap-in bir I/O gidiş-dönüşüdür.
vmstat 1ilesivesosütunlarına bakın; sürekli sıfır olmayan her sayı, CPU değil RAM eksikliğiniz olduğu anlamına gelir.
Pratikte işe yarayan bir kural: MySQL veya PostgreSQL için RAM'i innodb_buffer_pool_size toplam RAM'in yaklaşık %60 ila %70'i olacak şekilde ayarlayın. Eğer 4 GB'lık bir planınız varsa ve veritabanı 3 GB arabellek istiyorsa, web sunucusu ve PHP-FPM'in nefes alacak yeri yoktur. Burada doğru olan RAM yükseltmesidir, CPU yükseltmesi değil.
Disk türü: bulut planı özelliklerinin yalan söylemediği ama az söylediği yer
«80GB SSD» bir kapasite sayısıdır, performans sayısı değil. Aynı kapasiteye sahip iki plan IOPS'te on kat fark gösterebilir. Bu farkı özelliklerde görmezsiniz, iostat'ta görürsünüz.
iostat -x 1 5
# %util ve await sütunlarına bakınEğer ana diskte await sürekli 20 milisaniyenin üzerindeyse ve %util 100'e yakınsa, sorun kapasite değil; sorun IOPS'tir. NVMe, rastgele yükte genellikle SATA SSD'den birkaç kat daha fazla saniye başına işlem verir, ancak sıralı yükte (büyük bir dosya okumak gibi) fark reklamların söylediğinden çok daha azdır.
| Disk türü | Uygun olduğu yer | Nerede yetersiz kalır |
|---|---|---|
| SATA SSD | Normal web sitesi, log dosyaları | Ağır rastgele yazma yapan veritabanı |
| NVMe | Veritabanı, mesaj kuyruğu, önbellek | Maliyet; ve büyük sıralı yük |
| Ağ depolaması | Yedek, arşiv, birden fazla sunucu arasında paylaşım | Milisaniye altı gecikme isteyen her şey |
Burada şu hata yapılır: kullanıcı «veritabanı yavaş» diye diski SATA'dan NVMe'ye yükseltir, ama yavaşlık indekssiz sorgudan kaynaklanmıştır. Belirtisi şudur: yükseltmeden sonra await düşer ama uygulama yanıt süresi aynı kalır. Önce EXPLAIN ANALYZE çalıştırın, sonra diske para harcayın.
Trafik: aylık, giriş, çıkış
Plan trafiği genellikle «ayda X terabayt» olarak yazılır ve neredeyse her zaman çıkış kastedilir. Giriş trafiği çoğu sağlayıcıda ücretsizdir çünkü onlar için pahalı değildir. Eğer planınız girişi de sayıyorsa, bunu satış sayfasında değil sözleşmede görün.
Pratik nokta: trafiği panel ile değil, kendiniz vnstat veya iftop ile ölçün.
vnstat -m
iftop -i eth0 -nEğer çıkış trafiğiniz sürekli üst sınıra dayanıyorsa iki yolunuz var: daha fazla trafikli bir plan, ya da statik dosyaları bir nesne depolama alanına taşıyıp bunları içerik dağıtım ağından sunmak. İkinci yol yüksek hacimde neredeyse her zaman daha ucuza gelir, çünkü CDN trafiği genellikle ayrı hesaplanır ve ana sunucudan geçmez.
Sonradan pişman olmamak için planı nasıl okumalıyız
- Satın almadan önce kendi gerçek yükünüzü ölçün. Bir hafta boyunca
vmstatveiostatkaydedin. - Darboğazı bulun: yüksek
%stCPU demektir, sıfır olmayansi/soRAM demektir, yüksekawaitdisk demektir. - Yalnızca darboğaz olan kaynağı yükseltin. Her şeyi aynı anda yükseltmek, kullanılmayan şey için fazladan para demektir.
- Her değişiklikten önce snapshot alın. Bulut ortamında snapshot satın aldığınız en ucuz sigortadır.
Ölçeklendirme hakkında bir uyarı: planı büyütürseniz, sağlayıcıda hot-resize yoksa genellikle reboot gerekir. Kesintiye uğrayamayacak yükler için bunu önceden sorun. Kesintisiz bulut kaynaklarını ölçeklendirme rehberi tam da bu senaryoyu kapsıyor.
Ve eğer yükünüz dikey değil yatay büyüyorsa (load balancer arkasında birkaç web örneği), satın alma mantığı değişir: dev bir plan yerine load balancer ve health check ile birkaç orta plan genellikle hem daha ucuz hem daha dayanıklıdır. Konteyner yükleri için de yönetilen Kubernetes bunu kendisi yapar.
Sık sorulan sorular
vCPU paylaşımlı mı yoksa ayrılmış mı?
Çoğu bulut planında vCPU paylaşımlıdır; yani iş parçacıklarınız ortak fiziksel çekirdekler üzerinde zamanlanır. Eğer plan «ayrılmış» veya dedicated CPU ise, bu özelliklerde belirtilir ve fiyatı da genellikle daha yüksektir. Pratikte ayırt etmek için top içindeki %st sütununa bakın; sürekli %5'in üzerindeyse, sizin payınız pratikte plan sayısından daha azdır.
Yeterli RAM'im olduğu halde sunucu neden yavaş?
Çünkü darboğaz başka bir yerdedir. Üç ana aday: yüksek %st (CPU payı eksikliği), yüksek disk await (IOPS eksikliği) ve indekssiz sorgular. vmstat 1 ve iostat -x 1 ile üçü de iki dakikada elenebilir veya doğrulanabilir. si ve so sıfırken RAM yükseltmek hiçbir şeyi iyileştirmez.
Aylık plan trafiği girişi de kapsar mı?
Çoğu sağlayıcıda yalnızca çıkış hesaplanır ve giriş ücretsizdir, ancak bu teknik bir kural değil bir sözleşmedir. Eğer yükünüz giriş odaklıysa (örneğin yükleme alma veya log ingest), bu maddeyi sözleşmede okuyun. Sunucuda vnstat -m ile bağımsız ölçüm, panelden daha güvenilir bir referanstır.
NVMe her zaman SSD'den daha mı iyi?
Hayır. Ağır sıralı yükte (büyük dosyaları okuma ve yazma) NVMe ile SATA SSD arasındaki fark rastgele yüke göre çok daha azdır. NVMe, rastgele IOPS darboğaz olduğunda değerlidir: veritabanı, mesaj kuyruğu, önbellek. Eğer darboğaz sorgu veya CPU ise, disk yükseltmek sadece maliyettir.
Sonraki adım: herhangi bir yükseltmeden önce bir hafta boyunca vmstat ve iostat logu toplayın ve hangi sütunun kırmızı olduğunu görün. Hangi kaynağın darboğaz olduğundan hâlâ emin değilseniz, bulut izleme ve uyarı rehberi doğru başlangıç noktasıdır; ondan sonra plan seçimi bir tahmin değil mühendislik kararı olur.