İki planı yan yana koyuyorsunuz: biri 2.4 GHz frekanslı 8 çekirdek, diğeri 3.8 GHz frekanslı 4 çekirdek. Her ikisinde de 32 GB RAM var. Fiyat farkı da az değil. Sorun şu ki, bu sayıların hiçbiri tek başına sitenizin ağır yük altında nasıl davranacağını söylemez. Sunucu özellikleri, tablodaki en büyük sayıya göre değil, gerçekte üzerinde çalıştırılan işe göre okunmalıdır.
Çekirdek ve Frekans: Hangisi Web Yükünü Belirler
Tipik web yükü için (PHP-FPM, Node, ilişkisel veritabanı) tek çekirdek frekansı genellikle çekirdek sayısından daha önemlidir; tabii çekirdek sayısı eşzamanlı worker sayısından az olmadığı sürece. Bir PHP isteği neredeyse her zaman tek bir çekirdekte tamamlanır; paralelleştirme istekler arasında gerçekleşir, tek bir istek içinde değil. Yani 4 çekirdek 3.8 GHz'iniz varsa ve yükünüz 20 eşzamanlı istekse, çekirdekler kuyruğa girer ve daha yüksek frekans her isteğe daha hızlı yanıt verir.
Buna karşılık, aynı sunucuda Elasticsearch veya bir görüntü işleme kuyruğu çalıştırıyorsanız, hikaye değişir. Bu yükler gerçekten çok iş parçacıklıdır ve 16 çekirdek 2.4 GHz, 4 çekirdek 3.8 GHz'i geçer. İşte burada hata yapılıyor: WordPress sitesini 2.0 GHz temel frekanslı 32 çekirdekli bir makineye taşıyan ve sonra "sunucu güçlendi ama site yavaşladı" diyen kişi. Nedeni, MySQL'in tek iş parçacıklı çalışması ve o tek iş parçacığının artık daha yavaş yürütülmesidir.
Pratik bir sayı: top açıp %Cpu(s)'nin yüzde 100'de olduğunu ama load average'ın sadece 1.2 olduğunu görürseniz, sorununuz kapasite değil frekanstır. 4 çekirdekte load 8'in üzerindeyse ama her çekirdek yüzde 40 kullanımdaysa, sorun I/O'dur. Bu iki durum arasındaki fark, tüm satın alma kararını değiştirir ve yüksek sunucu yükünün nedenini teşhis etme rehberinde adım adım açılmıştır.
ECC ve CPU Nesli: Satış Tablosunda Görünmeyen Özellikler
ECC Gerçekte Neyi Değiştirir
ECC, tek bitlik bellek hatalarını düzeltir ve çift bitlik hataları tespit eder. Normal bir web sunucusunda, böyle bir hatanın bir yıl içinde ortaya çıkma olasılığı düşüktür. Ancak ZFS çalıştıran veya aylarca yeniden başlatılmadan açık kalan bir makinede, ECC'nin olmaması, dönen bir bitin diske yazılan veriye ulaşabileceği ve checksum'ı da bozabileceği anlamına gelir. ZFS veya Ceph kullanıyorsanız, ECC'yi tartışılmaz kabul edin. Basit bir kurumsal site için VPS ise, ECC için ödediğiniz ekstra para daha iyi NVMe'ye harcanır.
İşlemci Nesli ve Benchmark'ta Görmedikleriniz
Eski nesil 16 çekirdekli bir Xeon, çok iş parçacıklı bir benchmark'ta yeni nesil 8 çekirdekli bir işlemciyi geçebilir ve pratikte daha yavaş olabilir. Bunun nedeni iki şeydir: daha düşük IPC ve bazı şifreleme ve vektör işleme kütüphanelerinin kullandığı AVX-512 gibi daha yeni komut setleri desteği. TLS için, yeni işlemciler daha iyi AES-NI'ye sahiptir ve bu doğrudan saniyedeki handshake sayısını etkiler.
Hızlı değerlendirme yöntemi: satın almadan önce, test etme imkanınız varsa bunu çalıştırın ve sayıyı mevcut planınızla karşılaştırın.
openssl speed -evp aes-256-gcm
sysbench cpu --threads=4 --time=30 runopenssl speed çıktısı size aes-256-gcm 1.2 GB/s gibi bir sayı verir. Yeni plan bu sayıyı ikiye katlamıyorsa, muhtemelen şifrelenmiş yük için yükseltmeye değmez.
RAM, Disk ve Bant Genişliği: Birbirine Yalan Söyleyen Üç Sayı
| Özellik | Mağazada Gördüğünüz Sayı | Pratikte Önemli Olan Sayı |
|---|---|---|
| RAM | 32 GB | Yoğun saatte boş RAM ve swap oranı |
| Disk | 500 GB SSD | Rastgele IOPS ve kuyruk derinliği |
| Bant Genişliği | Aylık 10 TB | 1Gbps port ve 10Gbps port karşılaştırması |
RAM'e free -h ile bakmayın; vmstat 1 ile bakın. si ve so sütunları sıfırdan farklı bir sayı gösteriyorsa, RAM sıkıntınız var ve hiçbir PHP-FPM ayarı bunu çözmez. 16 GB RAM'li ve sıfır swap'lı bir sunucu, sürekli swap yapan 32 GB'lık bir sunucudan daha hızlıdır.
Diskte, kapasite sayısı neredeyse anlamsızdır. Veritabanı yükünü belirleyen rastgele IOPS'tir. PCIe 4.0 üzerinde bir NVMe, 500 binin üzerinde rastgele 4K IOPS verebilir; bir SATA SSD aynı testte 100 binin altında kalır. MySQL SATA diskteyse ve iostat -x 1 %util'in 100'de olduğunu gösterirken await 20 milisaniyenin üzerindeyse, darboğaz CPU değil disktir. Bu aşamada iki sunucu arasında veri taşımak için, scp ve rsync ile dosya aktarımı aracısız en hızlı yoldur.
Sanal ve Tahsisli: Yanlış Seçim Nerede Yapılır
Tahsisli sunucu, ya ECC ve tam çekirdek kontrolüne ihtiyacınız olduğunda ya da yükünüz sürekli olarak bir sanal makinenin kapasitesini aştığında doğrudur. Sadece ara sıra zirve yapıyorsanız, sanallaştırma daha iyidir çünkü kaynakları paylaştırır. Ancak daha az söylenen bir nokta var: sanal makinede "8 çekirdek", 4 fiziksel çekirdek üzerine oturabilen 8 vCPU anlamına gelir. Komşular yüksek tüketimliyse, steal time görürsünüz.
top ile st sütununa bakın. Yüzde 5'in üzerindeyse, sorun sizin kodunuzda değildir. Bu sayıyı yoğun saatte birkaç kez ölçün; sürekli yüksekse, plan değiştirme veya tahsisli sunucuya geçme zamanıdır. Dalgalanması yüksek olan ve kaynakları yukarı aşağı çekmek istediğiniz yükler için, bulut sunucu daha fazla esneklik verir ve üç saatlik bir zirve için bir yıl sabit ücret ödemeniz gerekmez.
Ortamı yeni kuruyorsanız ve yükün ne kadar olacağından henüz emin değilseniz, bir Linux hosting ile başlayıp gerçek tüketimi ölçmek, tahmine dayalı büyük bir makine satın almaktan daha mantıklıdır.
Sık Sorulan Sorular
Yüksek trafikli bir WordPress sitesi için kaç çekirdek yeterlidir?
Genellikle yüksek frekanslı 4 çekirdek yeterlidir, yeter ki önbellek doğru ayarlanmış olsun. Çoğu WordPress sitesinin darboğazı CPU değildir; indekssiz sorgu sayısı ve nesne önbelleğinin olmamasıdır. Yükseltmeden önce, her sayfanın sorgu sayısını ölçün.
Tam önbelleklemeden sonra hâlâ CPU doymuşsa, o zaman yükseltme anlamlıdır. O aşamaya kadar, çekirdek için ödediğiniz fazla para boşa gider.
NVMe gerçekten SATA SSD'den hızlı mı yoksa reklam mı?
Veritabanı yükünde fark gerçek ve ölçülebilirdir. NVMe, PCIe arayüzü üzerinde çalışır ve daha derin kuyruğu destekler; bu da rastgele IOPS'ta SATA'nın birkaç katı olmasını sağlar. Statik bir site için farkı hissetmezsiniz, yoğun yazma yapan MySQL için fark gece ile gündüz gibidir.
RAM sıkıntım mı yoksa CPU sıkıntım mı olduğunu nasıl anlarım?
vmstat 1 si ve so sütunlarında sıfırdan farklı bir sayı gösteriyorsa, sorun RAM'dir. Bu iki sütun sıfırsa ama load average çekirdek sayısından fazlaysa ve %Cpu(s) yüzde 80'in üzerinde kalıyorsa, sorun CPU'dur.
Üçüncü durumu da göz önünde bulundurun: her iki sayı da normaldir ama site yavaştır. O zaman darboğaz ağ veya disktir ve iostat ile TTFB'yi ayrı ayrı incelemelisiniz.
Web sunucusu için ECC gerekli mi?
Normal bir web sunucusu için hayır, üzerinde ZFS, Ceph veya yazılım depolama çalıştırılan her şey için evet. Daha fazla RAM ile ECC RAM arasında birini seçmeniz gerekiyorsa ve yükünüz dosya sunucusu değilse, daha fazla RAM'i alın.
Herhangi bir karardan önce, mevcut sunucunun gerçek tüketimini bir hafta boyunca sar veya vmstat ile kaydedin. Tablo sayısına göre satın almak, bu dersi öğrenmenin en pahalı yoludur. ServerNet'in teknik dokümantasyonu bilgi tabanında tam da bu ölçümler için yazılmıştır ve sayıları okuduktan sonra hâlâ şüpheniz varsa, ServerNet blogu gerçek yük örneklerini incelemiştir.