Web Sunucusu İşçi Ayarları: Kaç Süreç, Ne Kadar Bellek?

Sunucunuzda varsayılan ayarlar duruyor. Trafik arttığında ya istekler sıraya giriyor ya da bellek tükeniyor. İki durumun da nedeni aynı: işçi sayısı iş yükünüze göre ayarlanmamış.

Bu yazı, süreç havuzu ayarlarını iş yükünüze göre belirlemeyi ele alıyor.

Süreç Havuzu Nasıl Çalışır?

PHP uygulamaları genellikle bir süreç havuzu üzerinden çalışır:

1. Belirli sayıda işçi süreç önceden başlatılır
2. Gelen istek boştaki bir işçiye verilir
3. İşçi isteği işler ve serbest kalır
4. Tüm işçiler meşgulse istek sıraya girer

Dördüncü adım iki sonuç üretir: işçi sayısı yetersizse istekler bekler, fazlaysa bellek tükenir — ve doğru sayı bu iki sınır arasındadır.

Varsayılan değerler genellikle küçük sunucular için ayarlanmıştır ve gerçek iş yükünüzle ilgisi yoktur.

Doğru Sayıyı Hesaplamak

Hesap belleğe dayanır ve basittir:

Üçüncü adım en çok yanılınan noktadır: işçi başına bellek tüketimi uygulamadan uygulamaya kat kat değişir — genel bir tahmin kullanmak yerine kendi sunucunuzda ölçmek gerekir.

Ağır bir çerçeve kullanan bir uygulamanın işçisi, basit bir betiğin işçisinden çok daha fazla bellek tutar.

Beşinci adım ihmal edilirse sistem takasa düşer. Belleği tam sınırına kadar planlamak, ilk trafik dalgasında sunucuyu durdurur.

Takasa Düşmenin Bedeli

Bellek tükendiğinde sistem diski bellek gibi kullanmaya başlar:

• Her erişim kat kat yavaşlar.
• Disk yoğunlaşır.
• Yanıt süreleri patlar.
• Sıra uzar, durum kötüleşir.

Dördüncü madde bir kısır döngü kurar: yavaşlayan işçiler daha uzun süre meşgul kalır, bekleyen istekler birikir ve sistem kendini toparlayamaz.

Bu durumda sunucu teknik olarak çalışıyordur ama kullanılamaz hâldedir. Çoğu zaman yeniden başlatmak tek çıkış olur.

Bu yüzden işçi sayısını fazla ayarlamak, az ayarlamaktan daha tehlikelidir. Yetersiz işçi sayısında istekler bekler ama sistem ayakta kalır.

Statik mi Dinamik mi?

Havuz yönetiminde iki temel yaklaşım vardır:

1. Statik: Sabit sayıda işçi hep açık kalır.
2. Dinamik: Yüke göre işçi açılıp kapanır.
3. İstek üzerine: Yalnızca ihtiyaç oldukça açılır.

Birinci seçenek öngörülebilirlik sağlar: statik havuzda bellek kullanımı sabittir ve sürpriz yaşanmaz — sunucu yalnızca bu uygulamaya hizmet ediyorsa doğru tercihtir.

İkinci seçenek boşta kaynak tasarrufu sağlar ama trafik dalgalarında işçi başlatma gecikmesi getirir.

Üçüncü seçenek nadiren kullanılan siteler içindir. Boşta neredeyse hiç bellek tüketmez ama ilk istek yavaş olur.

İşçi Ömrü

Bir işçinin kaç istek işledikten sonra yenileneceği de bir ayardır:

Birinci satır uzun çalışan sunucularda sorun üretir: küçük bir bellek sızıntısı bile binlerce istek sonrasında işçiyi şişirir ve toplam bellek kullanımı zamanla artar.

İşçiyi belirli sayıda istekten sonra yenilemek, bu birikimi otomatik olarak temizler. Bu, sızıntıyı düzeltmez ama etkisini sınırlar.

Ölçüm Yapmak

Ayarların doğru olduğunu anlamak için izlenecekler:

• Aktif işçi sayısı. Zirvede kaça çıkıyor?
• Sıra uzunluğu. İstekler bekliyor mu?
• Bellek kullanımı. Sınıra ne kadar yakın?
• Yavaş istek sayısı.
• Takas kullanımı. Sıfır olmalı.

İkinci madde en doğrudan göstergedir: sıra sürekli doluysa işçi sayısı yetersizdir, sıra hiç dolmuyorsa fazla olabilir.

Beşinci madde ise kırmızı çizgidir. Takas kullanımı sıfırdan farklıysa, ayarlar hemen düşürülmelidir.

Yavaş İsteklerin Etkisi

İşçi sayısı hesabını bozan asıl etken istek süresidir:

1. Bir işçi, isteği bitirene kadar meşguldür
2. Uzun süren istekler işçiyi uzun süre tutar
3. Az sayıda yavaş istek tüm havuzu doldurabilir
4. Hızlı istekler de beklemeye başlar

Üçüncü madde en sık yaşanan tıkanma biçimidir: dış bir servise zaman aşımı olmadan bağlanan tek bir uç nokta, tüm işçileri kilitleyip siteyi durdurabilir.

Bu durumda işçi sayısını artırmak çözüm değildir — yeni işçiler de aynı yerde takılır. Asıl çözüm, uzun süren işlemleri kuyruğa taşımak ve dış çağrılara zaman aşımı koymaktır.

Havuz Ayırmak

Farklı iş yükleri için ayrı havuzlar tanımlanabilir:

• Normal sayfa istekleri — büyük havuz, kısa süre.
• API uç noktaları — ayrı havuz.
• Yönetim paneli — küçük havuz.
• Uzun süren işlemler — ayrı havuz, uzun zaman aşımı.

Dördüncü madde izolasyon sağlar: rapor üretimi gibi uzun işlemleri ayrı bir havuza almak, normal sayfaların bunlardan etkilenmesini önler.

Böylece bir rapor sorgusu yavaşlasa bile ana sayfa normal hızda açılmaya devam eder.

Bu tür havuz ayrımlarını yapılandırma dosyasında tanımlayabildiğiniz VDS hizmetleri ortamında, her havuza farklı kaynak sınırı vermek mümkündür.

Sonuç

İşçi sayısı hesabı belleğe dayanır ve kritik nokta ölçümdedir: işçi başına bellek tüketimi uygulamadan uygulamaya kat kat değişir, genel tahminler işe yaramaz. Fazla ayarlamak az ayarlamaktan tehlikelidir — yetersiz işçide istekler bekler ama sistem ayakta kalır, fazlada takasa düşüp toparlanamaz. Havuzu dolduran asıl etken ise istek süresidir: zaman aşımı olmayan tek bir dış çağrı, tüm işçileri kilitleyip siteyi durdurabilir.

Sıkça Sorulan Sorular (SSS)

Kaç işçi ayarlamalıyım?

Kullanılabilir belleği işçi başına gerçek bellek tüketimine bölün ve sonucun altında kalın. Kritik nokta, işçi başına belleği tahmin etmek yerine kendi sunucunuzda ölçmektir — bu değer uygulamadan uygulamaya kat kat değişir.

Fazla işçi ayarlarsam ne olur?

Bellek tükenir ve sistem takasa düşer. Bu bir kısır döngü kurar: yavaşlayan işçiler daha uzun meşgul kalır, sıra birikir ve sistem toparlanamaz. Yetersiz işçi sayısında ise istekler bekler ama sunucu ayakta kalır — bu yüzden fazla ayarlamak daha tehlikelidir.

İşçi sayısını artırdım ama site hâlâ tıkanıyor?

Sorun sayıda değil, istek süresinde olabilir. Zaman aşımı tanımlanmamış bir dış servis çağrısı işçileri kilitler ve yeni işçiler de aynı yerde takılır. Uzun işlemleri kuyruğa taşıyın ve dış çağrılara zaman aşımı koyun.

İşçi ömrünü sınırlamalı mıyım?

Evet. Küçük bir bellek sızıntısı bile binlerce istek sonrasında işçiyi şişirir ve toplam bellek kullanımı zamanla artar. Belirli sayıda istekten sonra işçiyi yenilemek bu birikimi otomatik temizler — sızıntıyı düzeltmez ama etkisini sınırlar.