Merhaba arkadaşlar, bugün sizlere özellikle yoğun trafik alan sunucularda performansı ve stabiliteyi doğrudan etkileyen, PHP-FPM optimizasyonunun kalbi diyebileceğimiz `pm.max_children` ve `pm.start_servers` gibi kritik ayarların nasıl hesaplanacağını ve yapılandırılacağını anlatacağım. Bu ayarları doğru yapmak, sitenizin yavaşlamasını, 502/504 hatalarını ve bellek tükenmesi (OOM) sorunlarını büyük ölçüde önler.
Neden Bu Ayarlar Çok Önemli?
PHP-FPM, gelen istekleri işlemek için "child process" (çocuk süreçler) oluşturur. Bu ayarlar, kaç tane sürecin aynı anda çalışabileceğini ve ne zaman başlatılacağını kontrol eder. Yanlış ayarlar şu sorunlara yol açar:
`max_children` düşükse: Yoğun anlarda tüm süreçler meşgul olur, yeni istekler kuyrukta bekler veya 502 hatası alır.
`max_children` yüksekse: Sunucu belleği (RAM) tükenir, sistem takılır veya çöker.
`start_servers` dengesizse: Süreçler sürekli ölüp yeniden doğar, bu da CPU ve I/O yükü getirir.
Ayarları Hesaplama Yöntemi
Öncelikle, sunucumuzdaki mevcut kaynak durumunu görelim. SSH üzerinden aşağıdaki komutları çalıştıralım.
Toplam kullanılabilir belleği (MB cinsinden) görmek için:
Tek bir PHP-FPM sürecinin ortalama ne kadar RAM tükettiğini ölçmek için. Bu komutu, siteniz normal trafikteyken birkaç kez çalıştırıp ortalamasını alın:
Çıkan sonuç (örneğin "80M") tek bir PHP sürecinin ortalama RAM kullanımıdır. Şimdi temel formülümüzü uygulayalım:
`pm.max_children = (Toplam Kullanılabilir RAM - Sistem Gereksinimleri) / Bir PHP Sürecinin Ortalama RAM Kullanımı`
Benim pratiğimde, sunucuda sadece Nginx, PHP-FPM ve MySQL/MariaDB çalışıyorsa, toplam RAM'in %20'sini sistem için ayırıyorum. Örnek hesaplayalım:
Sunucu RAM'i: 4096 MB (4GB)
Sistem için ayrılacak: ~820 MB
PHP-FPM için ayrılacak: 4096 - 820 = 3276 MB
Tek PHP süreci RAM'i: 80 MB
`pm.max_children` = 3276 / 80 ≈ 40
Bu, teorik maksimum değerdir. Güvenlik payı bırakarak ben genelde 35 gibi bir değerle başlarım.
Diğer Parametrelerin Ayarlanması
`pm.max_children` belirlendikten sonra, diğer ayarları da buna uygun şekilde yapılandırmalıyız. En verimli `pm` (process manager) modu genellikle `ondemand` veya `dynamic`'tir. Yoğun ve sabit trafiğiniz varsa `dynamic` öneririm.
`dynamic` mod için örnek config:
`pm.start_servers`: FPM başladığında açılacak süreç sayısı. `min_spare_servers` ile aynı veya yakın tutuyorum.
`pm.min_spare_servers`: Boşta bekleyen minimum süreç. Trafiği karşılamak için hazır bekleyen askerler gibi düşünün. `max_children`'ın %10-25'i iyidir.
`pm.max_spare_servers`: Boşta bekleyen maksimum süreç. Gereksiz yere fazla sürecin RAM yememesi için `max_children`'dan önemli ölçüde düşük tutulmalı.
`pm.max_requests`: Bir sürecin kaç istekten sonra öldürülüp yeniden başlatılacağı. Hafif sızıntıları (memory leak) temizler. 500-1000 arası makuldur.
Bu ayarları genellikle /etc/php/7.4/fpm/pool.d/www.conf (PHP versiyonunuza göre değişir) veya /etc/php-fpm.d/www.conf dosyasında bulup düzenleyebilirsiniz.
Dikkat Edilmesi Gerekenler
1. Test Edin! Bu ayarları canlı sunucuda yaparken, önce bir `php-fpm` pool'unda test edin. Tüm siteleri aynı anda riske atmayın.
2. Monitorize Edin: Ayarları yaptıktan sonra `htop`, `glances` veya `nmon` gibi araçlarla RAM ve süreç durumunu mutlaka izleyin.
3. OOM Killer'dan Korkun: Eğer `max_children` çok yüksekse, Linux OOM Killer en çok RAM yiyen süçleri (genelde PHP-FPM'leri) aniden öldürmeye başlar. Logları (/var/log/kern.log) kontrol edin.
4. Statik Dosyaları Nginx'e Bırakın: Resim, CSS, JS gibi dosyaların PHP'ye uğramaması için Nginx konfigürasyonunuzda `location` bloklarınızı doğru ayarlayın. Bu, PHP-FPM yükünü inanılmaz azaltır.
Sonuç ve Öneriler
Bu ayarlar sihirli değnek değildir, sunucunuzun ve uygulamanızın profilini sürekli izleyip ince ayar yapmanız gerekir. Özellikle `pm.max_children` değeri, uygulamanızın kod kalitesi, kullandığı eklentiler ve framework'e göre değişkenlik gösterecektir.
Benim genel tavsiyem, hesapladığınız değerden daha düşük bir rakamla başlayıp, yavaş yavaş artırarak test etmeniz yönünde.
Peki siz bu konfigürasyonu kendi sunucularınızda nasıl yapıyorsunuz? Farklı bir yaklaşımınız veya sorunuz varsa aşağıya yazmaktan çekinmeyin. Herkese sorunsuz sunucular dilerim!
Neden Bu Ayarlar Çok Önemli?PHP-FPM, gelen istekleri işlemek için "child process" (çocuk süreçler) oluşturur. Bu ayarlar, kaç tane sürecin aynı anda çalışabileceğini ve ne zaman başlatılacağını kontrol eder. Yanlış ayarlar şu sorunlara yol açar:
`max_children` düşükse: Yoğun anlarda tüm süreçler meşgul olur, yeni istekler kuyrukta bekler veya 502 hatası alır.
`max_children` yüksekse: Sunucu belleği (RAM) tükenir, sistem takılır veya çöker.
`start_servers` dengesizse: Süreçler sürekli ölüp yeniden doğar, bu da CPU ve I/O yükü getirir.
Ayarları Hesaplama YöntemiÖncelikle, sunucumuzdaki mevcut kaynak durumunu görelim. SSH üzerinden aşağıdaki komutları çalıştıralım.
Toplam kullanılabilir belleği (MB cinsinden) görmek için:
Bash:
free -mTek bir PHP-FPM sürecinin ortalama ne kadar RAM tükettiğini ölçmek için. Bu komutu, siteniz normal trafikteyken birkaç kez çalıştırıp ortalamasını alın:
Bash:
ps --no-headers -o "rss,cmd" -C php-fpm | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"M") }'Çıkan sonuç (örneğin "80M") tek bir PHP sürecinin ortalama RAM kullanımıdır. Şimdi temel formülümüzü uygulayalım:
`pm.max_children = (Toplam Kullanılabilir RAM - Sistem Gereksinimleri) / Bir PHP Sürecinin Ortalama RAM Kullanımı`
Benim pratiğimde, sunucuda sadece Nginx, PHP-FPM ve MySQL/MariaDB çalışıyorsa, toplam RAM'in %20'sini sistem için ayırıyorum. Örnek hesaplayalım:
Sunucu RAM'i: 4096 MB (4GB)
Sistem için ayrılacak: ~820 MB
PHP-FPM için ayrılacak: 4096 - 820 = 3276 MB
Tek PHP süreci RAM'i: 80 MB
`pm.max_children` = 3276 / 80 ≈ 40
Bu, teorik maksimum değerdir. Güvenlik payı bırakarak ben genelde 35 gibi bir değerle başlarım.
Diğer Parametrelerin Ayarlanması`pm.max_children` belirlendikten sonra, diğer ayarları da buna uygun şekilde yapılandırmalıyız. En verimli `pm` (process manager) modu genellikle `ondemand` veya `dynamic`'tir. Yoğun ve sabit trafiğiniz varsa `dynamic` öneririm.
`dynamic` mod için örnek config:
NGINX:
pm = dynamic
pm.max_children = 35
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500`pm.start_servers`: FPM başladığında açılacak süreç sayısı. `min_spare_servers` ile aynı veya yakın tutuyorum.
`pm.min_spare_servers`: Boşta bekleyen minimum süreç. Trafiği karşılamak için hazır bekleyen askerler gibi düşünün. `max_children`'ın %10-25'i iyidir.
`pm.max_spare_servers`: Boşta bekleyen maksimum süreç. Gereksiz yere fazla sürecin RAM yememesi için `max_children`'dan önemli ölçüde düşük tutulmalı.
`pm.max_requests`: Bir sürecin kaç istekten sonra öldürülüp yeniden başlatılacağı. Hafif sızıntıları (memory leak) temizler. 500-1000 arası makuldur.
Bu ayarları genellikle /etc/php/7.4/fpm/pool.d/www.conf (PHP versiyonunuza göre değişir) veya /etc/php-fpm.d/www.conf dosyasında bulup düzenleyebilirsiniz.
Dikkat Edilmesi Gerekenler1. Test Edin! Bu ayarları canlı sunucuda yaparken, önce bir `php-fpm` pool'unda test edin. Tüm siteleri aynı anda riske atmayın.
2. Monitorize Edin: Ayarları yaptıktan sonra `htop`, `glances` veya `nmon` gibi araçlarla RAM ve süreç durumunu mutlaka izleyin.
3. OOM Killer'dan Korkun: Eğer `max_children` çok yüksekse, Linux OOM Killer en çok RAM yiyen süçleri (genelde PHP-FPM'leri) aniden öldürmeye başlar. Logları (/var/log/kern.log) kontrol edin.
4. Statik Dosyaları Nginx'e Bırakın: Resim, CSS, JS gibi dosyaların PHP'ye uğramaması için Nginx konfigürasyonunuzda `location` bloklarınızı doğru ayarlayın. Bu, PHP-FPM yükünü inanılmaz azaltır.
Sonuç ve ÖnerilerBu ayarlar sihirli değnek değildir, sunucunuzun ve uygulamanızın profilini sürekli izleyip ince ayar yapmanız gerekir. Özellikle `pm.max_children` değeri, uygulamanızın kod kalitesi, kullandığı eklentiler ve framework'e göre değişkenlik gösterecektir.
Benim genel tavsiyem, hesapladığınız değerden daha düşük bir rakamla başlayıp, yavaş yavaş artırarak test etmeniz yönünde.
Peki siz bu konfigürasyonu kendi sunucularınızda nasıl yapıyorsunuz? Farklı bir yaklaşımınız veya sorunuz varsa aşağıya yazmaktan çekinmeyin. Herkese sorunsuz sunucular dilerim!