Sunucu kaynak planlaması: CPU, RAM ve diski doğru ölçmek

Sunucu seçerken en sık yapılan iki hata birbirinin zıddıdır: ihtiyacın üç katını alıp her ay boşa ödemek ya da sınırda bir yapılandırma alıp ilk yoğunlukta düşmek. İkisinden de kaçınmanın yolu, tahmin yerine ölçümle başlamaktır.

Önce mevcut kullanımı ölçün

Zaten çalışan bir siteniz varsa cevabın büyük bölümü elinizde. Bir hafta boyunca şu değerleri toplayın:

• Tepe saatlerdeki CPU kullanımı ve yük ortalaması.
• Kullanılan bellek — önbelleği hariç tutarak.
• Disk kullanımı ve haftalık büyüme hızı.
• Eşzamanlı ziyaretçi ve saniyedeki istek sayısı.
• Veritabanı boyutu.

Ortalama değil tepe değerlere bakın. Günün %95'inde boşta duran bir sunucu, akşam sekizde tıkanıyorsa sorun vardır.

Bu veriyi toplamak için ayrı bir araca gerek yok. sysstat paketini kurup sar -u, sar -r ve sar -d ile geçmiş günlerin saat saat dökümünü alabilirsiniz; paket zaten arka planda örnek toplar, siz yalnız okursunuz. Süreç başına gerçek bellek tüketimini görmek için:

ps --no-headers -o rss -C php-fpm | awk '{s+=$1; n++} END {print s/n/1024, "MB"}'

Çıkan sayı, aşağıdaki bellek hesabının en kritik girdisidir; internetteki genel tavsiyeler yerine kendi uygulamanızın gerçek rakamını kullanın.

CPU: çekirdek sayısı mı, frekans mı?

Web uygulamalarında her istek genellikle tek bir çekirdekte işlenir. Bu yüzden tek çekirdek performansı (frekans), toplam çekirdek sayısından çoğu zaman daha belirleyicidir. Kural:

• Çok sayıda eşzamanlı istek varsa çekirdek sayısını artırın.
• Tek tek istekler yavaşsa yüksek frekanslı işlemci seçin. Oyun sunucularında ve gerçek zamanlı uygulamalarda belirleyici olan budur.

Ölçek için kaba bir başlangıç: PHP tabanlı, önbellekli bir sitede tek çekirdek saniyede 20–50 dinamik istek karşılar. Önbelleksiz ve ağır sorgulu bir uygulamada bu sayı 5'e kadar düşer.

RAM: bileşenleri toplayın

Bellek ihtiyacı tahmin edilmez, toplanır:

1. İşletim sistemi: 512 MB – 1 GB.
2. Web sunucusu ve PHP: Süreç başına 40–120 MB. Eşzamanlı süreç sayısıyla çarpın; 20 süreç × 80 MB = 1,6 GB.
3. Veritabanı: InnoDB tampon havuzu için, sık erişilen veri kümesinin belleğe sığmasını hedefleyin. Ayrıntısı burada.
4. Önbellek servisi (Redis): Sakladığınız veri kadar, artı pay.
5. Pay: Toplamın üzerine %25 ekleyin. Takasa düşmek, yetersiz bellekten daha kötü bir durumdur.

Toplam çıktıktan sonra bunu bir yapılandırma satırına çevirmeniz gerekir. PHP-FPM'de eşzamanlı süreç tavanı şöyle hesaplanır:

pm.max_children = (uygulamaya ayrılan RAM) / (ortalama süreç boyutu)

8 GB belleğin 2 GB'ını veritabanına, 1 GB'ını sisteme ve önbelleğe ayırdıysanız kalan 5 GB'ı ölçtüğünüz 80 MB'a bölersiniz: yaklaşık 60 süreç. Bu sayıyı olduğundan büyük yazmak, yoğunlukta sunucunun takasa düşüp tamamen kilitlenmesi demektir; küçük yazmak ise istekleri kuyruğa aldırır ama sunucu ayakta kalır. İkisi arasında kalırsanız küçük olanı seçin.

Diskin gerçek hızını ölçün

Sağlayıcının belirttiği IOPS değeri en iyi durumu anlatır. Kendi ölçümünüzü tek komutla alabilirsiniz:

fio --name=t --rw=randrw --rwmixread=70 --bs=4k --size=1G --numjobs=4 --runtime=60 --group_reporting

Veritabanı yükü rastgele ve küçük bloklu olduğu için ölçümün 4k blok boyutuyla yapılması önemlidir. Büyük ardışık blokla alınan parlak sonuçlar, gerçek veritabanı davranışını temsil etmez. Testi boş bir sunucuda yapın; canlı sistemde çalıştırılan bir disk testi, o an gerçek kullanıcıları bekletir.

Disk: boyut kadar hız da önemli

Depolamada iki ayrı büyüklük vardır. Kapasite kolay hesaplanır: mevcut kullanım, artı haftalık büyümenin 12 aylık izdüşümü, artı yedek alanı. IOPS ise saniyede yapılabilen giriş çıkış işlemi sayısıdır ve veritabanı ağırlıklı yüklerde asıl darboğaz genellikle buradadır.

NVMe diskler, SATA SSD'lere göre birkaç kat daha yüksek IOPS verir; dönen diskler ise veritabanı yükü için artık uygun değildir. Veritabanınız yoğun yazma yapıyorsa disk teknolojisini ilk sırada değerlendirin.

Büyüme payı ve ölçekleme yönü

Kapasiteyi 12 aylık büyümeye göre planlayın, ama tepe kullanımın %70'ini geçmeyecek şekilde. %70 üzerinde sürekli çalışan bir sistemde küçük dalgalanmalar bile kesintiye dönüşür.

Dikey büyüme (aynı sunucuyu büyütmek) basittir ve çoğu iş için yeterlidir; sınırı donanımın en büyük yapılandırmasıdır. Yatay büyüme (sunucu eklemek) sınırsızdır ama uygulamanın buna hazır olmasını gerektirir: oturumların paylaşılan bir yerde tutulması, yüklenen dosyaların ortak depoda olması, veritabanının ayrılması. Cloud sunucularda dikey büyüme dakikalar sürer, bu yüzden baştan büyük almak yerine ihtiyaç doğdukça büyütmek daha ekonomiktir.

Sık yapılan üç hata

• Boş bellek görüp "RAM fazla" sanmak. Linux kullanılmayan belleği disk önbelleği yapar; free -m çıktısında bakılacak sütun available olandır. Gerçek darlığın işareti takas alanının aktif kullanımıdır.
• vCPU'yu fiziksel çekirdek sanmak. Paylaşımlı sanallaştırmada komşu yoğunlaştığında size düşen pay azalır. top çıktısındaki %st (steal) değeri sürekli sıfırın üzerindeyse sorun sizin uygulamanızda değil, sunucunun paylaşıldığı katmandadır.
• Kaynak artırarak yazılım sorununu örtmek. Belirtisi: sunucu iki katına çıkarıldığı hâlde yanıt süresinin aynı kalması. Tek bir yavaş sorgu ya da indekssiz bir tablo, hiçbir donanımla telafi edilmez; kaynak artırmadan önce sorgu tarafını denetleyin.

Bu yaklaşım ne zaman yanlış olur

Ölçüp boyutlandırma mantığı, yükü öngörülebilir ve süregelen sistemler içindir. Henüz yayına girmemiş bir projede ölçecek veri yoktur; orada doğru hamle küçük başlayıp ilk ayın gerçek rakamlarına göre büyütmektir. Trafiği yılda birkaç güne sıkışan bir yapıda (kayıt dönemi, kampanya günü) tepe değere göre satın almak, yılın geri kalanında boşa ödemektir; geçici olarak büyütülüp küçültülebilen bir yapı daha ekonomiktir. Aynı şekilde gecikmesi milisaniyelerle sınırlı gerçek zamanlı uygulamalarda ortalama kullanım yanıltıcıdır: orada kapasite, tepe anındaki en kötü duruma göre planlanır ve %70 kuralı bile fazla cömert kalabilir.

Üç örnek yapılandırma

Bu değerler başlangıç noktasıdır, sonuç değil. Kurulumdan sonraki ilk ay kullanımınızı izleyin ve gerçek rakamlara göre düzeltin. Hangi hizmet türünün size uyduğuna karar vermek için karşılaştırma yazısına, yapılandırma seçenekleri için VDS paketlerine bakabilirsiniz.