Sanal Sunucu Seçimi: Ne Kadar CPU ve RAM Gerekli?

Sunucunu ayağa kaldırdın, site de üzerinde yanıt veriyor, ama birkaç saatte bir TTFB 200 milisaniyeden iki saniyeye fırlıyor ve sonra kendiliğinden geri dönüyor. Ya da tam tersi: ayda birkaç yüz bin lira, hiç yarısını bile kullanmadığın kaynaklara ödüyorsun. Gerçek sorun "ne kadar CPU ve RAM iyi" değil; sorun hangi kaynağın önce tükendiği ve bunu satın almadan önce nasıl anlayacağın.

Önce hangi kaynağın darboğaz olduğunu anla, sonra sanal sunucu seç

Çoğu insan tam tersini yapar. Önce 4 vCPU ve 8 GB RAM'li bir plan alırlar, sonra sorunun doğru indeksle çözülecek MySQL sorguları olduğunu fark ederler. Veri olmadan kaynak tahmini, tahminden ibarettir. Veriyle ise basit bir hesap işidir.

Her şeyden önce, mevcut sunucuda şunu çalıştır ve bir hafta sakla:

vmstat 5 720 >> /var/log/vmstat.log
sar -u -r -d 5 1

vmstat'ta si ve so sütunları sıfırdan farklı bir sayı gösteriyorsa, sistem swap yapıyor ve RAM yetersiz demektir. wa (iowait) sütununun yüzde 10'un üzerinde olması, darboğazın CPU değil disk olduğu anlamına gelir. Bu iki satır, satın alma kararının yarısını sana netleştirir.

Her kaynağın yetersizlik belirtileri, ayrı ayrı

• CPU yetersizliği: load average sürekli olarak vCPU sayısının üzerinde kalır, ama iowait düşüktür. Site eşzamanlı yük altında yavaşlar ve trafik düşünce hemen düzelir.
• RAM yetersizliği: OOM killer dmesg'de iz bırakır. PHP-FPM veya MySQL sebepsiz yeniden başlar. Bunu logda Out of memory: Killed process şeklinde görürsün.
• Disk yetersizliği: iowait yüksek, ama CPU boşta. HDD üzerindeysen bu, düşündüğünden çok daha erken gerçekleşir.
• Bant genişliği yetersizliği: Yukarıdakilerin hiçbiri yok, ama dosya indirme yavaş. Burada sorun başka bir yerdedir.

Az söylenen bir nokta: sanal sunucularda vCPU bir kotadır, ayrılmış çekirdek değil. 4 vCPU'lu bir plan alıyorsun ama hipervizör yoğunsa, yoğun saatlerde yalnızca 2 çekirdek karşılığı alabilirsin. Bu yüzden top içinde steal time'ı kontrol et; yüzde 5'in üzerindeyse sorun senin kodunda değil.

Tahmini gerçek trafikten yap, varsayımdan değil

Pratikte işe yarayan bir kaba formül: günlük ziyaret sayısını değil, eşzamanlı istek sayısını hesapla. Sitenin günde 50.000 ziyareti varsa ve her ziyaret ortalama 8 istek oluşturuyorsa, bu günde 400.000 istek demektir. 24 saate yayıldığında saniyede yaklaşık 4,6 istek eder. Ama sitelerin trafiği tekdüze değildir; pik katsayısını 5 ila 10 kat al. Yani saniyede 25 ila 50 isteğe hazır olmalısın.

Şimdi her isteğin ne kadar CPU tükettiğine bağlı. Birkaç ağır eklentili, önbelleğe alınmamış bir WordPress sayfası 150 ila 300 milisaniye CPU tüketebilir. Basit bir API endpoint'i 10 milisaniyenin altında. Saniyede 50 istek ve her biri için 200 milisaniye CPU ile 10 tam çekirdeğe ihtiyacın olur. Bu sayıyı önbellekleme ile ciddi ölçüde düşürürsün.

Burada şu hata yapılır: insanlar veritabanı için az RAM alır ve sonra varsayılan 128 megabaytlık innodb_buffer_pool_size ile çalışırlar. Sonuç, her sorgunun diske gitmesi ve iowait'in yükselmesi, CPU'nun ise neredeyse boşta kalmasıdır. Belirtileri görürler ve "sunucu zayıf" derler, gidip daha fazla CPU alırlar. Teşhisteki hata, parayı boşa harcar.

Dikey ölçekleme ne zaman işe yarar, ne zaman yaramaz

Bir noktaya kadar, aynı sunucuyu büyütmek en basit yoldur. 8 çekirdek ve 32 GB RAM'li bir sunucu, mimaride hiçbir değişiklik yapmadan yükü kaldırır. Trafiğin mevcut kapasitenin birkaç katının altında olduğu sürece bunu seç.

Ama bu yol iki yerde kırılır. Birincisi, planların tavanına ulaştığında ve artık daha yukarı çıkmadığında. İkincisi, kesinti olmadan daha fazla kapasiteye ulaşmak istediğinde; çünkü plan değişikliği genellikle yeniden başlatma gerektirir. Siten iki dakikalık kesintiyi bile tolere edemiyorsa, en baştan yatay mimari kurmalısın. Bu iki yaklaşım arasındaki farkı Otomatik ölçekleme; yatay mı dikey mi? Doğru seçim kılavuzu yazısında sayısal örneklerle anlattım.

Yaygın bir tuzak: RAM'i anlık tüketime göre seçme. Sakin saatlerdeki anlık tüketim, pik tüketimin yarısıdır. Sakin saatlere göre alırsan, pikte swap yaparsın ve her şey yavaşlar. Her zaman ortalamaya değil, tüketimin 95. yüzdelik dilimine göre karar ver.

Diski hafife alma

Sanal sunucuda diskin türü, kapasitesi kadar önemlidir. 100 GB'lık bir NVMe, veritabanı için 500 GB'lık bir SATA'dan daha hızlıdır. IOPS senin için önemliyse, satın almadan önce diskin hangi tür olduğunu ve bir IOPS kotası olup olmadığını sor. Bazı sağlayıcılar IOPS'u müşteriler arasında paylaştırır ve yoğun saatlerde gerçek sayı, reklamlarda gördüğünden çok daha düşük olur.

Gerçek bir test için, kurulumdan sonra şunu çalıştır:

fio --name=randread --ioengine=libaio --rw=randread \
  --bs=4k --numjobs=4 --size=1G --runtime=60 --group_reporting

Çıktıdaki iops sayısı, sözleşmede satın aldığın şeydir. Beklediğinle arasında büyük bir fark varsa, ilk hafta içinde takip et.

Sanal sunucu seçiminden sonra ilk yapılandırma

Kaynakları seçtikten sonra, ilk gün üç şey yap. Birincisi, swap'ı vm.swappiness=10 ile ayarla ki yalnızca gerçek baskı altında kullanılsın. İkincisi, sorun ortaya çıkmadan önce izlemeyi başlat; pratik kılavuzu Sunucu izleme: akıllı izleme ve uyarı için pratik kılavuz yazısında. Üçüncüsü, statik dosyalar ve yedekler için ayrı depolama alanı kullan ki sunucunun ana diski dolmasın.

Siten görsel veya dosya trafiği barındırıyorsa, nesne depolamayı en baştan ayır. Bu hem sunucu diskini boş tutar hem de yedeklemeyi kolaylaştırır. Statik içerik için de sunucunun önüne bir içerik dağıtım ağı koy; bu, CPU yükünün yarısına kadarını sunucunun omuzlarından alabilir, çünkü statik istekler sunucuna hiç ulaşmaz.

İş yükün gerçekten değişkense ve pik için para ödemek istemiyorsan, büyük bir sunucu satın almak yerine kaynakları talebe göre yukarı ve aşağı ölçekleyebileceğin bir altyapı kullan. Bulut altyapısı (IaaS) ServerNet bu esnekliği sunar; ancak dikkat et, doğru izleme olmadan otomatik ölçekleme yalnızca maliyeti artırır.

Sık sorulan sorular

Ortalama bir WordPress sitesi için kaç CPU çekirdeği ve kaç GB RAM gerekir?

Orta trafikli ve önbelleği etkin bir site için 2 CPU çekirdeği ve 4 GB RAM mantıklı bir başlangıç noktasıdır. Sayfa önbelleği ve nesne önbelleği kullanıyorsan, bu miktar trafiğin birkaç katına kadar yeter. RAM genellikle CPU'dan önce tükenir, bu yüzden ikisi arasında birini daha fazla almak zorundaysan RAM'i seç.

Sorunun RAM yetersizliğinden mi yoksa CPU'dan mı olduğunu nasıl anlarım?

iowait düşükse ama load average çekirdek sayısının üzerinde kalıyorsa sorun CPU'dur. Swap etkinleşmişse veya dmesg'de OOM killer mesajı görüyorsan sorun RAM'dir. vmstat çıktısındaki si ve so sütunları teşhisin en hızlı yoludur.

vCPU fiziksel çekirdeğe eşit midir?

Hayır. vCPU, birden fazla sanal makine arasında paylaşılan fiziksel çekirdekten bir işlem kotasıdır. top'ta steal time değeri yüzde 5'in üzerindeyse, aynı çekirdek üzerindeki diğer makineler baskı uyguluyor ve sen kotandan daha azını alıyorsun demektir. Bu sayıyı sakin saatte değil, yoğun saatlerde kontrol et.

Tek bir büyük sunucudan birkaç küçük sunucuya ne zaman geçmeliyim?

Mevcut planların tavanına ulaştığında ya da plan değişikliğinden kaynaklanan kesintiyi kabul edemediğinde. O noktada, veritabanını web sunucusundan ayırmak ilk adımdır ve sonrasında web katmanını yatay olarak büyütebilirsin. Bu noktadan önce, aynı sunucuyu büyütmek en basit ve en az zahmetli yoldur.

Bir sonraki planı satın almadan önce bir hafta veri topla. Bundan sonra hâlâ hangi kaynağın darboğaz olduğundan emin değilsen, sorun muhtemelen sunucunun boyutunda değil, kodda veya yapılandırmadadır.