PHP-FPM Pool Ayarları ve Performans İyileştirme

Bir web sitesi "trafik biraz yükselince yavaşlıyor", "aynı anda birkaç kişi girince 502 hatası veriyor" ya da "sunucunun belleği doluyor ama CPU boşta" gibi belirtiler veriyorsa, sorunun kaynağı çoğu zaman uygulamanın kendisi değil, arka planda çalışan PHP-FPM havuzunun (pool) yanlış ayarlanmış olmasıdır. PHP-FPM, sitenizi ziyaret eden her isteği karşılamak için ayakta tuttuğu işçi süreçlerinin (worker) sayısını, ne zaman yenisini açacağını ve ne zaman kapatacağını yöneten motordur. Bu motorun kaç işçiyle çalışacağını doğru hesaplayamazsanız ya kapasite tükenip ziyaretçiler hata sayfasıyla karşılaşır, ya da gereksiz yere açık tutulan işçiler sunucunun tüm belleğini yiyip bitirir.

Bu rehberde PHP-FPM'in process pool mantığını, pm modları (ondemand, dynamic, static) arasındaki farkları, pm.max_children değerini sunucu RAM'i ile ortalama proses boyutuna göre nasıl hesaplayacağınızı ve start_servers, max_requests gibi ayarların ne işe yaradığını gerçek örneklerle ele alacağız. Ardından 502/504 hatalarının doğrudan FPM tükenmesiyle ilişkisini ve havuzun sağlığını nasıl izleyeceğinizi göstereceğiz. Amacımız, "internetten bulduğum değerleri yapıştırdım" aşamasından çıkıp, kendi sunucunuz için bilinçli sayılar üretebilmeniz.

PHP-FPM Nedir ve Process Pool Mantığı Nasıl Çalışır?#

PHP-FPM (FastCGI Process Manager), PHP kodunu çalıştıran ayrı bir servistir. Klasik mod_php yaklaşımında PHP, Apache'nin içine gömülü çalışır ve her Apache süreci PHP'yi de taşır; bu da web sunucusuyla PHP'nin kaderini birbirine bağlar. FPM ise PHP'yi web sunucusundan (Nginx ya da Apache) tamamen ayırır. Nginx bir PHP isteği aldığında bunu bir soket üzerinden FPM'e devreder, FPM boştaki bir işçiye işi verir, işçi kodu çalıştırıp sonucu geri gönderir. Bu ayrım sayesinde web sunucusu ve PHP bağımsız ölçeklenebilir; konuya daha geniş bakmak isterseniz Apache ve Nginx karşılaştırmamıza göz atabilirsiniz.

Buradaki kritik kavram worker (işçi süreç) sayısıdır. FPM, her biri tek seferde tek bir PHP isteği işleyen bir işçi havuzu tutar. Bir işçi meşgulken gelen yeni istek, ya boştaki başka bir işçiye gider ya da havuzda boş işçi kalmamışsa kuyruğa girer ve bekler. Yani sitenizin aynı anda kaç ziyaretçiye hizmet verebileceği, doğrudan havuzdaki işçi sayısıyla sınırlıdır. Bir sayfanın ortalama 200 milisaniyede çalıştığını ve havuzda 10 işçi olduğunu varsayalım; teorik olarak saniyede yaklaşık 50 istek karşılayabilirsiniz. Trafik bunun üstüne çıktığında istekler kuyrukta bekler, yanıt süresi uzar ve bir eşikten sonra web sunucusu bekleyen isteği kapatarak hata döndürür.

İşte pool yapılandırmasının tüm amacı bu dengeyi kurmaktır: yeterince işçi açarak kuyrukta bekleme yaşanmasını önlemek, ama o kadar çok işçi açmamak ki her biri belleği tüketip sunucuyu OOM (Out Of Memory) durumuna sokmasın. Her işçi, çalıştırdığı uygulamaya bağlı olarak 30 MB ile 120 MB arasında RAM tüketir; dolayısıyla işçi sayısı bir kapasite ayarı olduğu kadar aynı zamanda bir bütçe kararıdır.

Bir sunucuda birden fazla site barındırıyorsanız, her sitenin kendi FPM havuzunu (ayrı .conf dosyası, ayrı kullanıcı) kullanması en sağlıklısıdır. Böylece bir sitenin trafik patlaması diğerlerinin işçilerini tüketmez ve her havuzu kendi ihtiyacına göre ölçeklendirebilirsiniz.

pm Modları: ondemand, dynamic ve static Arasındaki Fark#

FPM havuzunun işçileri nasıl yöneteceğini pm (process manager) direktifi belirler. Üç mod vardır ve doğru modu seçmek, max_children değerini bulmaktan önce gelen ilk karardır.

static modda FPM, başlangıçta tam olarak pm.max_children kadar işçiyi açar ve onları hep açık tutar. Trafik olsa da olmasa da bu işçiler bellekte durur. Avantajı, yeni işçi açma/kapatma maliyeti hiç yaşanmadığı için en öngörülebilir ve en hızlı yanıt süresini vermesidir. Dezavantajı, boşta bile RAM'i sürekli meşgul etmesidir. Sitenin tek işi PHP servis etmek olan, RAM'i bol ve trafiği yüksek/sürekli sunucular için idealdir.

dynamic modda FPM, pm.start_servers kadar işçiyle başlar; trafik arttıkça pm.max_children sınırına kadar yeni işçi açar, trafik düştüğünde fazla işçileri kapatır ama her zaman pm.min_spare_servers ile pm.max_spare_servers arasında bir miktar boş işçi hazır bekletir. En dengeli ve en yaygın kullanılan moddur; ani trafik dalgalarına hazırlıklı olurken boş zamanlarda kaynağı serbest bırakır.

ondemand modda başlangıçta hiç işçi açılmaz; işçi yalnızca gerçek bir istek geldiğinde oluşturulur ve pm.process_idle_timeout süresince istek gelmezse kapatılır. En düşük RAM ayak izine sahip moddur, ama ilk istekte işçiyi baştan oluşturma gecikmesi yaşanır. Az ziyaret alan, çok sayıda sitenin aynı sunucuda barındırıldığı paylaşımlı hosting senaryoları veya nadiren kullanılan yönetim panelleri için biçilmiş kaftandır.

Pratik tavsiye: neyi seçeceğinizden emin değilseniz dynamic ile başlayın. Sunucuda yalnızca tek bir yüksek trafikli site varsa ve RAM'iniz bolsa static'e geçmeyi değerlendirin. Onlarca küçük siteyi tek VDS üzerinde toplamışsanız ondemand toplam bellek tüketimini ciddi biçimde düşürür.

pm.max_children Değerini Nasıl Hesaplarsınız?#

pm.max_children, havuzun açabileceği maksimum işçi sayısıdır ve tüm ayarların en kritiğidir. Çok düşük olursa trafik gelince kapasite tükenir; çok yüksek olursa bellek dolar ve sunucu takla atar. Değeri tahminle değil, iki sayıyı bilerek hesaplarsınız: PHP'ye ayırabileceğiniz RAM ve bir işçinin ortalama tükettiği RAM.

Önce bir işçinin gerçek bellek tüketimini ölçün. Sunucu trafik alırken şu komut, çalışan FPM işçilerinin proses başına bellek kullanımını (RSS) listeler:

ps --no-headers -o rss,cmd -C php-fpm8.2 | awk '{ sum += $1; n++ } END { printf "Ortalama: %d MB\n", sum/n/1024 }'

Diyelim ki çıktı ortalama 60 MB dedi. WordPress + WooCommerce gibi ağır bir kurulumda bu değer 80-120 MB'a çıkabilir; sade bir kurumsal sitede 30-40 MB'da kalabilir. Ölçmeden varsayım yapmak en sık yapılan hatadır.

Sonra PHP'ye ne kadar RAM ayırabileceğinize karar verin. Toplam RAM'in tamamını FPM'e veremezsiniz; işletim sistemi, MySQL/MariaDB veritabanı, web sunucusu ve önbellek (Redis vb.) da paylarını ister. Genel bir başlangıç kuralı, veritabanı aynı sunucudaysa RAM'in yaklaşık yarısını PHP-FPM'e ayırmaktır.

Formül basittir:

pm.max_children = PHP'ye ayrılan RAM / işçi başına ortalama RAM

4 GB RAM'li bir sunucu için pratik bir hesap:

Toplam RAM:                4096 MB
İşletim sistemi + MySQL:  -2048 MB
Web sunucusu + tampon:     -512 MB
--------------------------------------
PHP-FPM'e kalan:           1536 MB
İşçi başına ortalama:      60 MB

pm.max_children = 1536 / 60 ≈ 25

Yani bu sunucuda pm.max_children = 25 mantıklı bir tavan olur. Daha yüksek RAM'li bir sunucuda oran korunur: 8 GB'lık bir makinede aynı 60 MB'lık işçilerle rahatça 50-60 işçiye çıkabilirsiniz. Değeri belirledikten sonra bir güvenlik payı bırakmak için hesabın biraz altında kalmak, ani bir sızıntıda sunucunun tamamen kilitlenmesini önler.

Unutmayın, pm.max_children'ı büyütmek istekleri sihirli biçimde hızlandırmaz. İşçi sayısı yalnızca eşzamanlılık sınırını belirler; tek bir sayfanın ne kadar sürede çalıştığı ise PHP sürümü, OpCache ve veritabanı sorgularının hızıyla ilgilidir. RAM'iniz doluyken max_children'ı zorlamak, kapasiteyi artırmak yerine sunucuyu takas alanına (swap) iterek her şeyi yavaşlatır.

start_servers, spare_servers ve max_requests Ayarları#

dynamic modda max_children tek başına yeterli değildir; havuzun boşta kaç işçi hazır tutacağını belirleyen üç ayar daha vardır. Bunlar ilk istek geldiğinde beklemeyi azaltmak için önceden ısıtılmış işçi sayısını yönetir.

• pm.start_servers: Servis başladığında açılacak işçi sayısı. Genellikle min_spare_servers ile max_spare_servers arasında bir değer verilir.
• pm.min_spare_servers: Havuzda her an hazır bekleyecek en az boş işçi sayısı. Bunun altına düşülürse FPM yeni işçi açar.
• pm.max_spare_servers: Boşta tutulacak en fazla işçi sayısı. Bunun üstündeki boş işçiler kapatılarak RAM serbest bırakılır.

PHP resmi belgelerinin de önerdiği makul bir başlangıç dağılımı şöyledir: start_servers ve min_spare_servers toplam kapasitenin dörtte biri, max_spare_servers ise dörtte üçü civarında olsun. max_children = 25 için tipik bir set:

[www]
user = mustericilik
group = mustericilik
listen = /run/php/php8.2-fpm-mustericilik.sock
listen.owner = www-data
listen.group = www-data

pm = dynamic
pm.max_children = 25
pm.start_servers = 6
pm.min_spare_servers = 6
pm.max_spare_servers = 18
pm.max_requests = 500
pm.process_idle_timeout = 20s

Buradaki pm.max_requests ayarı özellikle önemlidir. Bir işçi, belirtilen sayıda isteği işledikten sonra kendini kapatır ve yerine taze bir işçi açılır. Bunun amacı, kötü yazılmış eklentilerin veya bazı PHP eklerinin zamanla biriktirdiği bellek sızıntılarını temizlemektir. max_requests = 0 (sınırsız) bırakırsanız, sızıntı yapan bir işçi günler içinde şişerek belleği tüketebilir. 500 ile 1000 arası bir değer, çoğu üretim ortamı için sızıntıyı temizlemekle işçi yeniden başlatma maliyeti arasında iyi bir dengedir.

ondemand modda start_servers ve spare_servers ayarları yok sayılır; onun yerine pm.process_idle_timeout işçinin ne kadar boş kaldıktan sonra kapatılacağını belirler. static modda ise sadece pm.max_children dikkate alınır, diğerleri anlamsızdır.

Senaryolara Göre Örnek Pool Yapılandırmaları#

Doğru değerler siteye ve sunucuya göre değişir. Aşağıda üç tipik durum için başlangıç noktası olabilecek yapılandırmalar var; bunları kendi ölçümlerinizle ince ayarlayın.

Tek, orta trafikli WordPress sitesi (2 GB RAM, VDS). Veritabanı aynı sunucuda. PHP'ye ~800 MB ayrılabilir, işçi başına 65 MB varsayımıyla:

pm = dynamic
pm.max_children = 12
pm.start_servers = 3
pm.min_spare_servers = 3
pm.max_spare_servers = 9
pm.max_requests = 500

Yüksek ve sürekli trafikli tek site (8 GB RAM, ayrılmış veritabanı). Veritabanı başka bir sunucuda olduğundan RAM'in çoğu PHP'ye kalıyor. Öngörülebilir yanıt için static tercih edilir:

pm = static
pm.max_children = 80
pm.max_requests = 1000

Çok sayıda küçük site (paylaşımlı hosting). Her sitenin ayrı havuzu var ama çoğu düşük trafikli. Toplam bellek ayak izini düşürmek için ondemand:

pm = ondemand
pm.max_children = 10
pm.process_idle_timeout = 10s
pm.max_requests = 500

Değişikliği yaptıktan sonra yapılandırmayı test edip servisi yeniden yükleyin. reload, açık bağlantıları kesmeden ayarları uygular:

php-fpm8.2 -t                       # sözdizimi testi
sudo systemctl reload php8.2-fpm    # kesintisiz yeniden yükle

Servisi yönetmenin ayrıntıları için systemd servis yönetimi mantığı ve genel sunucu yönetimi hizmetimiz işinize yarayabilir. Kendi sunucusunu yönetmek istemeyen ekipler için yönetilen bir VDS ya da paylaşımlı hosting paketinde bu ayarlar zaten optimize gelir.

502 ve 504 Hataları: FPM Tükenmesinin Tipik Belirtisi#

Nginx + PHP-FPM kurulumlarında en sık görülen iki hata olan 502 Bad Gateway ve 504 Gateway Timeout, çoğu zaman doğrudan havuz yapılandırmasıyla ilgilidir. İkisini karıştırmamak önemlidir çünkü çözümleri farklıdır.

502 Bad Gateway, Nginx'in FPM'e bağlanamadığı veya FPM'in bağlantıyı beklenmedik biçimde kapattığı anlamına gelir. En yaygın nedenleri: FPM servisi çökmüş/durmuş olması, işçilerden birinin bellek sınırını (memory_limit) aşıp öldürülmesi, ya da havuzun max_children'a ulaşıp yeni bağlantıyı reddetmesidir. FPM tükendiğinde error log'da net bir uyarı belirir:

WARNING: [pool www] server reached pm.max_children setting (25),
consider raising it

Bu satırı gördüyseniz mesaj açıktır: havuz dolmuş, trafiği karşılayamıyor. Çözüm, ölçüm yaparak max_children'ı (RAM izin veriyorsa) yükseltmek veya sayfa işleme süresini kısaltarak işçilerin daha hızlı serbest kalmasını sağlamaktır.

504 Gateway Timeout ise Nginx'in FPM'e ulaştığını ama yanıtın zamanında gelmediğini gösterir. Burada sorun kapasite değil, süredir: bir sayfa fastcgi_read_timeout ya da PHP'nin max_execution_time değerinden uzun sürüyordur. Ağır bir rapor sorgusu, yavaş bir dış API çağrısı ya da optimize edilmemiş veritabanı sorguları tipik suçlulardır. Nginx tarafındaki ilgili ayar şudur:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.2-fpm-mustericilik.sock;
    fastcgi_read_timeout 60s;
}

Timeout süresini kör biçimde uzatmak yerine önce yavaş sayfanın kökenine inmek gerekir; süreyi artırmak yalnızca gerçekten uzun süren meşru işlemler (dışa aktarma, toplu işlem) için doğru çözümdür. Uygulamayı yavaşlatan bir saldırı trafiği söz konusuysa, önüne bir WAF veya DDoS koruması koymak, FPM'e hiç ulaşmadan zararlı istekleri elemek açısından etkilidir.

PHP-FPM Havuzunu İzleme ve İnce Ayar#

Doğru sayıları bir kez ayarlayıp unutmak yerine, havuzun gerçek yükünü izleyip zamanla ayar yapmak gerekir. FPM'in kendi status sayfası bunun için yerleşik bir araçtır. Önce havuz yapılandırmasında etkinleştirin:

pm.status_path = /fpm-status

Ardından Nginx'te bu yolu yalnızca yerelden erişilebilir biçimde açın:

location = /fpm-status {
    access_log off;
    allow 127.0.0.1;
    deny all;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.2-fpm-mustericilik.sock;
}

Şimdi sunucudan durum bilgisini çekebilirsiniz:

curl -s http://127.0.0.1/fpm-status?full

Çıktıdaki en kritik satırlar şunlardır: active processes (o an meşgul işçi sayısı), idle processes (boş işçi), max active processes (servis başladığından beri ulaşılan zirve) ve max children reached (havuzun kaç kez tamamen dolduğu). Eğer max children reached sıfırdan büyükse ve max active processes sürekli max_children'a yaklaşıyorsa, havuzunuz yetersizdir; RAM izin veriyorsa değeri yükseltmelisiniz. Tam tersine, zirve değer hiçbir zaman max_children'ın yarısına bile ulaşmıyorsa, gereksiz yere RAM ayırıyorsunuz demektir ve değeri düşürerek belleği başka işlere (örneğin veritabanı önbelleği) verebilirsiniz.

Yavaş çalışan sayfaları yakalamak için slow log çok değerlidir. Belirli bir süreden uzun süren istekleri, o an nerede takıldıklarının PHP çağrı yığınıyla birlikte kaydeder:

slowlog = /var/log/php8.2-fpm-slow.log
request_slowlog_timeout = 5s

Bu sayede "sitem ara sıra yavaşlıyor" gibi belirsiz bir şikayeti, "şu eklentinin şu fonksiyonu her seferinde 8 saniye sürüyor" gibi somut bir bulguya çevirebilirsiniz. Havuz ayarlarını sürekli izlemek istemiyorsanız, servis erişilebilirliğini takip eden bir uptime izleme kurmak ya da yönetimini bize bırakabileceğiniz bir sunucu yönetimi paketi bu yükü üzerinizden alır. Yeni ayarları canlıya almadan önce mutlaka bir yedek alın; hatalı bir max_children değeri sunucuyu erişilemez hale getirebilir.

Sıkça Sorulan Sorular#

pm.max_children değerini yükseltmek sitemi hızlandırır mı?#

Hayır, doğrudan hızlandırmaz. pm.max_children yalnızca sitenin aynı anda kaç isteği paralel işleyebileceğini, yani eşzamanlılık kapasitesini belirler. Tek bir sayfanın ne kadar hızlı açıldığı ise PHP sürümü, OpCache, kod kalitesi ve veritabanı sorgularının hızıyla ilgilidir. Değeri yükseltmek yalnızca havuz gerçekten dolup istekler kuyrukta beklediğinde fayda sağlar; RAM sınırının üstünde zorlarsanız sunucuyu swap'a iterek her şeyi yavaşlatırsınız.

static mı dynamic mi kullanmalıyım?#

Çoğu üretim sitesi için dynamic en dengeli seçimdir; ani trafiğe hazır yedek işçiler tutarken boş zamanlarda RAM'i serbest bırakır. Sunucuda tek bir yüksek ve sürekli trafikli site varsa ve RAM'iniz bolsa, işçi açma/kapatma maliyetini sıfırlayan static daha öngörülebilir yanıt süresi verir. Aynı makinede çok sayıda düşük trafikli site barındırıyorsanız, toplam bellek tüketimini en aza indiren ondemand daha mantıklıdır.

502 Bad Gateway hatası her zaman FPM tükenmesinden mi kaynaklanır?#

Hayır, tek nedeni bu değildir ama en yaygın nedenlerden biridir. 502 hatası genel olarak Nginx'in FPM'e bağlanamaması demektir; bu FPM servisinin çökmüş olması, işçilerin memory_limit aşımıyla öldürülmesi veya havuzun max_children sınırına dayanması nedeniyle olabilir. Kesin nedeni bulmak için FPM ve Nginx error log'larına bakın; log'da "server reached pm.max_children setting" satırını görüyorsanız, sorun net biçimde havuz kapasitesidir.

İşçi başına ne kadar RAM ayırmalıyım?#

Sabit bir sayı yerine kendi sunucunuzda ölçüm yapmalısınız çünkü değer tamamen uygulamaya bağlıdır. Sade bir kurumsal sitede işçi başına 30-40 MB yeterli olabilirken, WordPress artı WooCommerce gibi ağır bir kurulumda bu 80-120 MB'a çıkar. Sunucu trafik alırken ps komutuyla çalışan FPM süreçlerinin ortalama bellek kullanımını ölçün ve max_children hesabında bu gerçek değeri kullanın; varsayımla ilerlemek kapasiteyi ya boşa harcar ya da eksik bırakır.

max_requests ayarını neden kullanmalıyım?#

Bu ayar, bir işçinin belirli sayıda istek işledikten sonra kapanıp yerine taze bir işçi açılmasını sağlar ve temel amacı bellek sızıntılarını temizlemektir. Bazı eklentiler veya PHP eklentileri zamanla bellekte artık biriktirir; sınırsız (max_requests = 0) çalışan bir işçi bu birikimle şişerek RAM'i tüketebilir. 500 ile 1000 arası bir değer, sızıntıyı düzenli temizlemekle işçiyi çok sık yeniden başlatmanın maliyeti arasında iyi bir dengedir.

Ayarları değiştirdikten sonra siteyi yeniden başlatmam gerekir mi?#

Sitenin kendisini değil, yalnızca PHP-FPM servisini yeniden yüklemeniz yeterlidir ve bunu kesintisiz yapabilirsiniz. Önce php-fpm8.2 -t ile yapılandırmanın sözdizimini doğrulayın, sonra systemctl reload php8.2-fpm komutuyla ayarları uygulayın; reload, restart'tan farklı olarak açık istekleri kesmeden yeni ayarları devreye alır. Kritik bir değişiklik yapıyorsanız, hatalı bir değerin siteyi erişilemez bırakması ihtimaline karşı önceden yedek almayı unutmayın.

Kapanış#

PHP-FPM havuz ayarları, tek bir "her zaman doğru" değer setinden ibaret değildir; sunucunuzun belleği, sitenizin gerçek işçi başına RAM tüketimi ve trafik profili üzerine kurulu bir dengedir. Doğru pm modunu seçmek, max_children'ı tahminle değil ölçümle hesaplamak, max_requests ile sızıntıları temizlemek ve FPM status sayfasıyla havuzu düzenli izlemek; sitenizi hem ani trafik dalgalarına dayanıklı hem de bellek açısından verimli hale getirir. 502/504 hatalarını rastgele denemeler yerine log'lardaki somut ipuçlarına bakarak çözdüğünüzde, kaynağı da kalıcı olarak ortadan kaldırırsınız.

Bu ince ayarlarla tek tek uğraşmak istemiyor, altyapının sizin için optimize edilmesini tercih ediyorsanız Clou.TR paketleri yardımcı olabilir. Yüksek trafikli projeler için kaynak garantili bir VDS sunucu ya da tam kontrol istediğiniz bir sanal sunucu, günlük yükünüz için ise FPM ayarları hazır gelen WordPress hosting ve web hosting paketlerimizi inceleyebilir; kurulumu bize bırakmak isterseniz sunucu yönetimi hizmetimizle tüm bu optimizasyonu uzman ekibimize devredebilirsiniz. Uygun PHP sürümünü seçmek için de PHP sürüm yönetimi rehberimiz iyi bir başlangıç noktasıdır.