Merhaba arkadaşlar, bugün sizlere özellikle yük altındaki sunucularda PHP performansını ve kaynak kullanımını doğrudan etkileyen çok önemli bir konudan bahsedeceğim: PHP-FPM pool yapılandırması. Doğru `pm` (process manager) stratejisi ve process ayarları, sunucunuzun bellek tüketimini kontrol altına almanızı, yanıt sürelerini iyileştirmenizi ve gereksiz yere swap kullanımının önüne geçmenizi sağlar. Bu rehberde, bu ayarları nasıl yapacağımızı ve neye göre seçeceğimizi adım adım anlatacağım.
PHP-FPM ve Pool Nedir?
PHP-FPM (FastCGI Process Manager), PHP'yi yüksek trafikli siteler için optimize eden bir alternatiftir. "Pool" kavramı ise, farklı web sitelerinizi veya uygulamalarınızı birbirinden izole ederek, her biri için ayrı process havuzları ve kaynak limitleri tanımlamanıza olanak tanır. Örneğin, bir pool'u yoğun bir WordPress siteniz, diğerini ise hafif bir API servisiniz için kullanabilirsiniz.
pm (Process Manager) Stratejileri
`pm` direktifi, PHP-FPM'in child process'leri nasıl yöneteceğini belirler. Üç ana stratejimiz var: `static`, `dynamic` ve `ondemand`. Hangi stratejiyi seçeceğiniz, sunucu kaynaklarınıza ve trafik yoğunluğunuza bağlı.
1. pm = static
Bu stratejide, `pm.max_children` ile belirlediğiniz sayıda PHP child processi, FPM başladığı anda oluşturulur ve sürekli çalışır durumda kalır.
Avantajı: Sürekli yük altındaki, trafiği yüksek ve stabil sunucular için idealdir. Her istek için process oluşturulup kaldırılmadığından ekstra yük yoktur, performans en yüksektir.
Dezavantajı: Boşta bile olsa tüm process'ler bellek tüketir. Eğer `pm.max_children` değerinizi çok yüksek tutarsanız, sunucunuzun RAM'ini tüketip swap'a geçmesine neden olabilirsiniz.
2. pm = dynamic
En yaygın kullanılan ve benim de genelde tercih ettiğim stratejidir. Process sayısı, trafiğe göre belirlenen minimum ve maksimum değerler arasında dinamik olarak değişir.
Ayarların Anlamı:
- `pm.max_children`: Aynı anda çalışabilecek maksimum process sayısı. Sunucu RAM'inize göre BELİRLEYİN.
- `pm.start_servers`: FPM başladığında oluşturulacak process sayısı.
- `pm.min_spare_servers`: Boşta bekleyen minimum process sayısı. Yeni gelen ani isteklere hızlı cevap vermek içindir.
- `pm.max_spare_servers`: Boşta bekleyen maksimum process sayısı. Bunun üzerindeki boş process'ler kapatılır.
- `pm.process_idle_timeout`: Boşta kalan bir process'in ne kadar sonra sonlandırılacağı (sadece bazı PHP versiyonlarında).
Bu strateji, bellek kullanımı ve performans arasında iyi bir denge sunar.
3. pm = ondemand
Bu stratejide, FPM başladığında hiçbir child process oluşturulmaz. Process'ler sadece bir istek geldiğinde oluşturulur ve işi bitince (belirli bir süre boş kaldıktan sonra) kapatılır.
Avantajı: Çok düşük trafikli, geliştirme ortamları veya çok sayıda farklı/pasif site barındıran sunucular için mükemmeldir. Bellek tüketimi minimumdadır.
Dezavantajı: Her yeni istek için process oluşturulduğundan, ani trafik patlamalarında yanıt süreleri artabilir (process oluşturma maliyeti).
Kritik Hesaplama: pm.max_children Değeri
`pm.max_children` değerini rastgele vermeyin! Sunucunuzu çökertebilirsiniz. Kabaca şu formülle hesaplayabilirsiniz:
Bir PHP process'inin ortalama ne kadar RAM yediğini öğrenmek için, sunucu normal yük altındayken aşağıdaki komutu çalıştırın:
Bu komut, ortalama bir PHP-FPM process'inin megabayt (MB) cinsinden bellek tüketimini verir. Güvenlik payını da unutmayın!
Diğer Önemli Process Ayarları
Özet ve Önerilerim
- Yüksek ve Stabil Trafikli Üretim Sunucusu: `pm = static` (RAM'iniz yeterliyse).
- Genel Amaçlı / Orta Trafikli Üretim Sunucusu: `pm = dynamic` (en güvenli ve dengeli seçim).
- Düşük Trafik / Geliştirme / Çoklu Site Barındırma: `pm = ondemand`.
- /etc/php/7.4/fpm/pool.d/www.conf (veya PHP versiyonunuza göre) dosyasını düzenleyerek bu ayarları yapabilirsiniz.
- Her değişiklik sonrası PHP-FPM'i yeniden başlatmayı unutmayın: `sudo systemctl restart php7.4-fpm`
Umarım bu detaylı rehber faydalı olmuştur. Siz bu konfigürasyonu kendi sunucularınızda nasıl yapıyorsunuz? `pm.max_children` değerini hesaplarken farklı bir yönteminiz var mı? Ya da `ondemand` ile ilgili enteresan bir tecrübeniz? Soruları olan veya eklemek isteyenler aşağıya yazsın, beraber tartışalım.
PHP-FPM ve Pool Nedir?PHP-FPM (FastCGI Process Manager), PHP'yi yüksek trafikli siteler için optimize eden bir alternatiftir. "Pool" kavramı ise, farklı web sitelerinizi veya uygulamalarınızı birbirinden izole ederek, her biri için ayrı process havuzları ve kaynak limitleri tanımlamanıza olanak tanır. Örneğin, bir pool'u yoğun bir WordPress siteniz, diğerini ise hafif bir API servisiniz için kullanabilirsiniz.
pm (Process Manager) Stratejileri`pm` direktifi, PHP-FPM'in child process'leri nasıl yöneteceğini belirler. Üç ana stratejimiz var: `static`, `dynamic` ve `ondemand`. Hangi stratejiyi seçeceğiniz, sunucu kaynaklarınıza ve trafik yoğunluğunuza bağlı.
NGINX:
pm = dynamicBu stratejide, `pm.max_children` ile belirlediğiniz sayıda PHP child processi, FPM başladığı anda oluşturulur ve sürekli çalışır durumda kalır.
NGINX:
pm = static
pm.max_children = 20Dezavantajı: Boşta bile olsa tüm process'ler bellek tüketir. Eğer `pm.max_children` değerinizi çok yüksek tutarsanız, sunucunuzun RAM'ini tüketip swap'a geçmesine neden olabilirsiniz.
2. pm = dynamicEn yaygın kullanılan ve benim de genelde tercih ettiğim stratejidir. Process sayısı, trafiğe göre belirlenen minimum ve maksimum değerler arasında dinamik olarak değişir.
NGINX:
pm = dynamic
pm.max_children = 30
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 10
pm.process_idle_timeout = 10s- `pm.max_children`: Aynı anda çalışabilecek maksimum process sayısı. Sunucu RAM'inize göre BELİRLEYİN.
- `pm.start_servers`: FPM başladığında oluşturulacak process sayısı.
- `pm.min_spare_servers`: Boşta bekleyen minimum process sayısı. Yeni gelen ani isteklere hızlı cevap vermek içindir.
- `pm.max_spare_servers`: Boşta bekleyen maksimum process sayısı. Bunun üzerindeki boş process'ler kapatılır.
- `pm.process_idle_timeout`: Boşta kalan bir process'in ne kadar sonra sonlandırılacağı (sadece bazı PHP versiyonlarında).
Bu strateji, bellek kullanımı ve performans arasında iyi bir denge sunar.
3. pm = ondemandBu stratejide, FPM başladığında hiçbir child process oluşturulmaz. Process'ler sadece bir istek geldiğinde oluşturulur ve işi bitince (belirli bir süre boş kaldıktan sonra) kapatılır.
NGINX:
pm = ondemand
pm.max_children = 30
pm.process_idle_timeout = 10s
pm.max_requests = 500Dezavantajı: Her yeni istek için process oluşturulduğundan, ani trafik patlamalarında yanıt süreleri artabilir (process oluşturma maliyeti).
Kritik Hesaplama: pm.max_children Değeri`pm.max_children` değerini rastgele vermeyin! Sunucunuzu çökertebilirsiniz. Kabaca şu formülle hesaplayabilirsiniz:
Bash:
pm.max_children ≈ (Toplam RAM - Sistem ve Diğer Servislerin RAM'i) / Bir PHP Process'in Ortalama RAM Tüketimi
Bash:
ps --no-headers -o "rss,cmd" -C php-fpm | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"M") }'
NGINX:
; Bir child process bu kadar istek işledikten sonra öldürülüp yeniden başlatılır.
; Memory leak'leri (bellek sızıntıları) önlemek için çok faydalıdır.
pm.max_requests = 500
; Process'lerin hangi kullanıcı/grup ile çalışacağını belirler.
; Güvenlik için her pool'u farklı bir sistem kullanıcısına atayabilirsiniz.
listen.owner = www-data
listen.group = www-data
user = www-data
group = www-data- Yüksek ve Stabil Trafikli Üretim Sunucusu: `pm = static` (RAM'iniz yeterliyse).
- Genel Amaçlı / Orta Trafikli Üretim Sunucusu: `pm = dynamic` (en güvenli ve dengeli seçim).
- Düşük Trafik / Geliştirme / Çoklu Site Barındırma: `pm = ondemand`.
- /etc/php/7.4/fpm/pool.d/www.conf (veya PHP versiyonunuza göre) dosyasını düzenleyerek bu ayarları yapabilirsiniz.
- Her değişiklik sonrası PHP-FPM'i yeniden başlatmayı unutmayın: `sudo systemctl restart php7.4-fpm`
Umarım bu detaylı rehber faydalı olmuştur. Siz bu konfigürasyonu kendi sunucularınızda nasıl yapıyorsunuz? `pm.max_children` değerini hesaplarken farklı bir yönteminiz var mı? Ya da `ondemand` ile ilgili enteresan bir tecrübeniz? Soruları olan veya eklemek isteyenler aşağıya yazsın, beraber tartışalım.