Bir VDS'te Kaç Web Sitesi Barındırılabilir?

Bir VDS'e kaç web sitesi sığacağını disk alanı ya da site adedi söylemez. Sınırı, yoğun saatte aynı anda çalışan dinamik isteklerin bellek ve işlemci tüketimi, veritabanlarının sık okunan verisi ve önbelleğin bu isteklerin ne kadarını PHP'ye uğratmadan karşıladığı çizer. Hesap bu yüzden ölçümle başlar: her sitenin tepe saatteki eşzamanlı istek sayısını ve PHP işçisi başına belleğini bulun, bellek bütçesini toplayın, işlemci ihtiyacını saniyedeki istek sayısı ile istek başına işlemci süresinden çıkarın. Önbellekli bir tanıtım sitesiyle bir WooCommerce mağazası aynı terazide tartılmaz.

Site sayısını gerçekte ne sınırlıyor?

Disk dolmadan çok önce başka bir kaynak tükenir. Pratikte beş etken birlikte çalışır ve her birinin ölçüldüğü yer farklıdır.

Listenin ilk iki satırı çarpan gibi davranır. Yirmi sitenin her birine "ne olur ne olmaz" diye on işçi izni verirseniz kâğıt üzerinde iki yüz işçilik bir bellek borcu doğar, sunucu da bunu ancak siteler aynı anda yüklenmediği sürece ödeyebilir. Sunucu boyutunu ilk kez seçiyorsanız darboğazı bulma adımlarını VDS seçerken mevcut kullanımı ölçme yöntemi yazısında anlattık. Paylaşımlı cPanel paketlerinde gördüğünüz "web sitesi" değeri ise başka bir şeydir: sağlayıcının hesap başına koyduğu bir sınırdır ve cPanel paketindeki site sınırının anlamını ayrıca ele aldık.

Önce mevcut siteleri ölçün

Siteler bugün başka bir hostingte ya da sunucuda çalışıyorsa elinizde altın değerinde bir veri var. Üç değer toplamanız yeterli: tepe dakikadaki PHP isteği, işçi başına bellek ve veritabanlarının boyutu.

Tepe dakikadaki dinamik istek sayısı

Erişim günlüğünden statik dosyaları ayıklayıp dakika başına istek sayısını çıkarabilirsiniz. Aşağıdaki komut Apache ve Nginx'in yaygın "combined" günlük biçimini varsayar:

grep -v -E '\.(css|js|png|jpe?g|gif|svg|webp|woff2?|ico)' access.log \
  | awk '{print substr($4, 2, 17)}' \
  | sort | uniq -c | sort -rn | head -5

Çıktıdaki her satır bir dakikayı ve o dakikadaki istek sayısını gösterir; 412 29/Oct/2026:11:42 gibi bir satır, o dakikada statik olmayan 412 istek geldiği anlamına gelir. Bu sayı bir üst sınırdır. Sayfa önbelleğinden dönen istekler de günlüğe yazılır ama PHP'ye ulaşmaz.

Eşzamanlılığa geçmek için basit bir ilişki kullanılır: aynı anda meşgul işçi sayısı ≈ saniyedeki PHP isteği × ortalama yanıt süresi. Dakikada 300 PHP isteği saniyede 5 eder. İstekler ortalama 0,4 saniye sürüyorsa aynı anda ortalama iki işçi çalışır. Tepe anlarında bunun birkaç katı görülür, o yüzden kararı ortalamaya değil ölçülmüş en yüksek değere bağlayın.

PHP-FPM durum sayfası ve günlüğü

Günlükten daha doğrudan bir kaynak, PHP-FPM'in kendi durum sayfasıdır. Havuz ayarında pm.status_path tanımlanırsa sayfada active processes, max active processes, max children reached ve listen queue değerleri görünür. Bu sayfayı yalnız sunucunun kendisine açın; herkese açık bir durum sayfası iç yapınızı dışarıya anlatır.

İşçi tavanına çarpan bir havuz, FPM günlüğüne server reached pm.max_children setting uyarısı yazar (ondemand modunda ifade max_children setting olarak geçer). Günlüğün yolu dağıtıma ve panele göre değişir:

grep -i "max_children setting" /var/log/php*-fpm*.log

Hiç satır gelmiyorsa havuz tavanı bugüne kadar yetmiş demektir. Sık tekrar eden satırlar ise ziyaretçinin sırada beklediğini gösterir.

İşçi başına bellek

Her site ayrı bir Linux kullanıcısıyla çalışıyorsa o kullanıcının PHP işlemlerini toplayarak site başına ortalamayı bulursunuz:

ps -u kullanici -o rss=,comm= | grep php-fpm \
  | awk '{t+=$1; n++} END {printf "%d işçi, ortalama %.0f MB\n", n, t/n/1024}'

rss değeri kilobayt cinsindendir ve paylaşılan belleği (OPcache'in ortak bellek alanı, kütüphaneler) her işleme ayrı ayrı yazar. Toplam bu yüzden gerçeğin biraz üstünde çıkar, bütçe için de bu temkinli taraf işinize yarar. Sunucuda smem kuruluysa paylaşılan sayfaları bölüştüren PSS değeri daha gerçekçi bir tablo verir.

Veritabanı boyutu ve sık okunan veri

SELECT table_schema,
       ROUND(SUM(data_length + index_length) / 1024 / 1024) AS mb
FROM information_schema.tables
GROUP BY table_schema
ORDER BY mb DESC;

Toplam boyut, belleğe sığması gereken miktar değildir. Asıl ihtiyaç, sorguların sürekli dokunduğu kısımdır. Mevcut sunucuda SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'; çıktısına bakın: Innodb_buffer_pool_reads diskten okunmak zorunda kalan okumaları, Innodb_buffer_pool_read_requests ise bütün mantıksal okumaları sayar. İlki ikincisine göre küçük kalıyorsa sıcak veri belleğe sığıyor demektir.

Bellek bütçesi nasıl toplanır?

Ölçtüğünüz değerleri tek bir toplamda birleştirin:

Gereken bellek ≈ işletim sistemi + panel (varsa)
              + web sunucusu
              + veritabanı (buffer pool + bağlantı başına tamponlar)
              + Redis/Memcached (maxmemory değeri)
              + Σ (site başına pm.max_children × işçi başına bellek)
              + %20–30 pay (disk önbelleği, yedek, güncelleme)

Bileşenlerin tipik tüketim aralıklarını sunucuda RAM ihtiyacını bileşen bileşen hesaplama rehberindeki tabloda verdik, burada tekrar etmeyelim. Çok siteli sunucularda hesabı asıl bozan üç tuzak var.

Birincisi toplam işareti. Her havuzun pm.max_children değeri tek başına makul görünür, toplamları ise çoğu zaman sunucunun belleğini aşar. Siteler aynı anda yüklenmedikçe sorun görünmez. Bir bot taraması ya da kampanya birkaç havuzu aynı anda tavana çıkardığında bellek biter ve çekirdek bir işlemi öldürür. Bunun izini çekirdek günlüklerindeki OOM kayıtlarından sürmek mümkündür ama önlemek daha ucuzdur. Aynı FPM ana işlemine bağlı çok sayıda havuz için PHP-FPM'in genel ayarlarındaki process.max, bütün havuzların toplam işçi sayısına bir tavan koyar. PHP belgesi bunu dikkatli kullanılacak bir ayar olarak niteliyor, yani tavan dolduğunda istekler sıraya girer.

İkincisi boşta bekleyen işçiler. pm = dynamic modunda her havuz, hiç ziyaretçi yokken bile pm.min_spare_servers kadar işçiyi ayakta tutar. pm = ondemand modunda işçiler istek geldikçe açılır ve pm.process_idle_timeout (varsayılanı 10 saniye) sonra kapanır. Az ziyaret alan sitelerde ondemand, boşa duran belleği neredeyse sıfıra indirir. Karşılığında ilk isteğe işçi açılırken küçük bir gecikme eklenir.

Üçüncüsü sınırsız önbellek servisi. Redis'in maxmemory değeri 64 bit sistemlerde varsayılan olarak 0'dır, yani veri kümesine sınır konmaz. Nesne önbelleği kullanan siteler büyüdükçe Redis de büyür. Bütçeye girecek rakam, sizin açıkça yazdığınız maxmemory değeridir.

İşlemci tarafı: saniyedeki istek × istek başına süre

Bellek "aynı anda kaç iş ayakta kalabilir" sorusunu yanıtlar. İşlemci ise bu işlerin ne kadar çabuk biteceğini belirler. Hesap şöyle kurulur:

Gereken vCore ≈ Σ (site başına tepe PHP isteği/sn × istek başına işlemci süresi)
               ÷ 0,7 (yoğun saatte hedeflenen en yüksek kullanım)

İstek başına işlemci süresi yanıt süresiyle aynı şey değildir. Bir istek 0,8 saniye sürüp bunun yalnız 0,2 saniyesini işlemcide geçirebilir, kalanı veritabanını ya da dış bir servisi bekler. Ölçmek için yoğun bir dakikada PHP işlemlerinin işlemci kullanımını alın:

pidstat -u -C php-fpm 60 1

Komut 60 saniye boyunca adında php-fpm geçen işlemlerin ortalama işlemci yüzdesini verir. Average satırlarındaki %CPU değerlerini toplayın: toplam %85 ise PHP o dakika ortalama 0,85 vCore kullanmıştır. Aynı dakikada günlükte 510 PHP isteği saydıysanız saniyede 8,5 istek eder, istek başına işlemci süresi de 0,85 ÷ 8,5 = 0,1 saniye çıkar. Veritabanı işlemcisini -C mysqld ya da -C mariadbd ile ayrıca ölçüp ekleyin.

%70 hedefi kampanya ve bot dalgalanmalarına pay bırakmak içindir. vCore sanal işlemci birimidir ve fiziksel çekirdekle bire bir aynı şey değildir. Netx VDS'te paketteki vCore ve RAM size ayrılmış kaynak olarak tanımlanır. Hesabı bu ayrılmış değerler üzerinden yapabilirsiniz.

Üç varsayımsal senaryo

Aşağıdaki rakamlar ölçüm sonucu değildir. Yöntemin nasıl işlediğini göstermek için seçilmiş varsayımlardır ve kendi değerlerinizi koyduğunuz anda sonuç değişir. Sonuçları "şu kadar site sığar" diye değil, "bu karışım şu kadar kaynak ister" diye okuyun.

Varsayımsal senaryo 1: önbellekli 20 tanıtım sitesi

Her sitede sayfa önbelleği açık, yoğun saatte sayfa görüntülemelerin %90'ı önbellekten dönüyor. Yönetim paneli, iletişim formu ve botlarla birlikte site başına dakikada 6 istek PHP'ye ulaşıyor. Toplam saniyede 2 istek, 0,1 saniyelik işlemci süresiyle 0,2 vCore eder. İşlemci neredeyse boşta.

Bellekte tablo farklı. Her havuz 5 işçiye izin verirse toplam 100 işçi × 70 MB = yaklaşık 7 GB'lık bir kâğıt borcu çıkar. Oysa ölçülen eşzamanlılık saniyede 2 istek × 0,4 saniye, yani ortalama bir işçinin biraz altında kalıyor. Havuzları ondemand moduna alıp site başına 2–3 işçiyle sınırladığınızda en kötü durum 2,8–4,2 GB'a iner. Üzerine işletim sistemi ve web sunucusu (yaklaşık 0,7 GB), 1 GB'lık bir buffer pool ve %25 pay eklenince bütçe kabaca 5,6–7,4 GB aralığına oturur. Bu senaryoda kapasiteyi trafik değil, havuz ayarlarının ne kadar özenli yapıldığı belirliyor.

Varsayımsal senaryo 2: iki mağaza ve altı kurumsal site

Mağazalarda sepet, hesap, ödeme ve AJAX istekleri önbelleğe alınamaz. Varsayımımız, yoğun saatte mağaza başına dakikada 300 sayfa isteğinin %40'ının PHP'ye ulaşması. İki mağaza normal tepe saatinde saniyede 4 istek üretir, kampanya gününde trafik üç katına çıkınca 12 istek. 0,3 saniyelik işlemci süresiyle kampanya tepesi 3,6 vCore ister. Veritabanı için 1 vCore daha ekleyip %70 hedefine böldüğünüzde ihtiyaç yaklaşık 6,6 vCore'a çıkar.

Kampanya anında eşzamanlılık 12 × 0,8 saniye ≈ 10 işçiye ulaşır. Mağaza başına 10 işçilik tavan (20 × 128 MB ≈ 2,5 GB), kurumsal siteler için 18 işçi (≈ 1,3 GB), iki mağazanın sıcak verisini taşıyacak 3 GB'lık buffer pool, 512 MB Redis ve 0,7 GB sistem payı toplamı yaklaşık 8 GB eder. %25 payla 10 GB civarı. Burada site sayısının neredeyse hiç önemi yok. Altı kurumsal siteyi çıkarsanız ihtiyaç pek değişmez, mağazalardan birinin kampanyası ise her şeyi değiştirir. Varsayımlar kâğıt üstünde kaldığı için kampanyadan önce gerçekçi bir yük testiyle sınamak şart.

Varsayımsal senaryo 3: ajansın 40 az ziyaretli sitesi

Trafik birinci senaryodakiyle aynı: toplamda saniyede 2 PHP isteği. Bu kez havuzlar panelin varsayılanında, pm = dynamic ve pm.min_spare_servers = 1 ile çalışıyor. Kimse siteye girmezken bile 40 işçi × 60 MB = 2,4 GB bellek boşta bekler. Havuz başına başlangıç işçisi 2 ise servis yeniden başladığında bu rakam 4,8 GB'a çıkar.

Görünmeyen yükler de bu senaryoda öne çıkar. Kırk sitenin WordPress zamanlanmış görevleri, gece aynı saatte başlayan kırk ayrı yedek sıkıştırması, güvenlik taramaları ve kırk ayrı giriş sayfasına gelen bot denemeleri trafikten bağımsız olarak işlemci ve disk tüketir. Açıkçası bu sunucuda sınıra önce ziyaretçi yüküyle değil, gece yedeklerinin sabaha yetişmemesiyle ya da kırk sitenin güncelleme yüküyle varırsınız.

Siteleri birbirinden ayırmak

Kapasite hesabı tek başına yetmez, aynı sunucudaki sitelerin birbirine ne kadar dokunabildiği de bir sınırdır. Her site için ayrı bir Linux kullanıcısı ve ayrı bir PHP-FPM havuzu açın: havuzun user ve group ayarları, o sitenin PHP kodunun hangi kullanıcıyla çalışacağını belirler. Dosya izinleri doğru kurulduğunda ele geçirilen bir site komşusunun dosyalarına yazamaz. Veritabanında da her siteye yalnız kendi veritabanında yetkili ayrı bir kullanıcı verin.

Havuz başına pm.max_children, güvenlik kadar adalet işi de görür. Bir sitenin eşzamanlılık tavanıdır, dolayısıyla tek bir sitenin bütün belleği yutmasını engelleyen ilk sınırdır. Siteler müşterilerinize aitse kaynak tüketen bir müşteriyle nasıl konuşacağınızı ve sözleşmeye ne yazacağınızı da baştan düşünün. Bayi hostingte bir müşterinin kaynakları tüketmesi durumunda izlenen yol (tespit, müşteriyle konuşma, geçici sınırlama, gerekirse ayrı pakete taşıma) VDS'teki çok müşterili düzende de büyük ölçüde geçerlidir.

cPanel ya da Plesk gibi bir panel bu ayrımı hesap veya abonelik başına kendiliğinden yapar, karşılığında kendi belleğini ve lisans bedelini ister. Lisans bazen donanımdan önce sınır koyar. cPanel lisansları sunucudaki hesap sayısına göre kademelenir, ayrıntısını cPanel lisansının hesap sayısına göre nasıl fiyatlandığı yazısında anlattık. Plesk'in sürüm sayfasında Web Admin sürümü 10, Web Pro sürümü 30 alan adıyla sınırlı, Web Host sürümü sınırsız olarak listeleniyor. Seçtiğiniz kademenin üst sınırı, sunucunuzun fiilî site sınırı olabilir.

Yedek ve zamanlanmış işler için yer ayırın

Gece yedeği çok siteli bir sunucunun en ağır işidir. Sıkıştırma işlemciyi, dosyaları baştan sona okumak diski yorar. Kırk siteyi aynı dakikada yedeğe almak yerine işleri saatlere yayın ve yedeği sunucu dışında bir yere gönderin. Netx VDS'te yedekleme fiyata dahil değildir; siparişte ek yedek alanı seçebilir ya da kendi dış deponuzu kullanabilirsiniz.

WordPress sitelerinde ziyaretle tetiklenen zamanlanmış görevleri (WP-Cron) sistem cron'una taşıyıp her sitenin çalışma dakikasını kaydırmak, hepsinin aynı anda uyanmasını önler. Kırk sitenin görevi saatin başında birlikte başlarsa o dakika, gün içindeki en yoğun dakikanız olabilir.

Hesabı canlıda doğrulayın

Siteleri taşıdıktan sonraki bir iki hafta, hesabınızın sınavıdır. Yoğun saatlerde şu göstergeleri izleyin:

• free -h çıktısındaki available sütunu tepe saatte de rahat bir pay bırakıyor mu?
• FPM günlüğünde max_children setting uyarısı çıkıyor mu, hangi havuzda?
• vmstat 1 çıktısında si ve so sütunları sürekli sıfırın üzerinde mi?
• cat /proc/pressure/memory çıktısındaki some avg60 değeri sıfırdan belirgin biçimde uzaklaşıyor mu? Bu değer, işlemlerin bellek beklerken geçirdiği zamanın yüzdesidir. Dosya yoksa çekirdeğiniz bu ölçümü sunmuyordur.
• İşlemci kullanımı yoğun saatte %70'in altında kalıyor mu?

Sayfalar hatasız ama yavaş açılıyorsa sorun büyük olasılıkla işlemci ya da disk tarafındadır. Bu durumda yavaşlığı steal, iowait ve load average değerlerinden ayırt etmek doğru başlangıç noktasıdır.

Ne zaman bölmeli?

Her şeyi tek sunucuda tutmanın bir kolaylığı var, bir de riski. Şu işaretlerden biri tekrar ediyorsa büyütmek yerine bölmeyi düşünün:

• Tek bir site, kampanya dönemlerinde kaynakların yarısından fazlasını tüketip diğerlerini yavaşlatıyor.
• Veritabanının sıcak verisi büyüdükçe buffer pool'u PHP'ye bırakılan bellekle yarıştırıyorsunuz.
• Gece yedekleri sabaha yetişmiyor ya da yoğun saate taşıyor.
• Sitelerden biri ödeme ya da kişisel veri nedeniyle farklı güvenlik ve erişim kuralları istiyor.
• Tek bir güncelleme hatası bütün siteleri birlikte düşürüyor ve bu risk artık kabul edilemiyor.

Bölmenin iki yaygın yolu var: yükü taşıyan mağazayı ayrı bir sunucuya almak ya da veritabanını uygulamadan ayırmak. Sorun yalnız bir kaynakta toplanıyorsa dikey büyütme daha basittir. Netx VDS Sihirbazı'nda vCore, RAM ve NVMe diski ayrı ayrı seçebildiğiniz için yapılandırmayı darboğaz olan kaynağa göre kurabilirsiniz. Hazır kademeler ve altyapının ayrıntıları VDS sunucu sayfasında yer alıyor. Hangi yolu seçerseniz seçin, ölçtüğünüz tepe kullanımın üzerine %30–40 pay bırakmak sonraki taşınmayı geciktirir.