PHP-FPM, web sunucusundan gelen PHP işlerini çalışan süreçlere dağıtır. PHP sayfaları yavaşken statik görseller hızlı açılıyorsa FPM kuyruğu, uygulama veya veritabanı araştırılmalıdır. Bu rehber systemd kullanan bir Linux sunucusunda teşhis içindir.
1. Doğru servisi bulun
systemctl list-units --type=service --all | grep -i fpm
ps -eo pid,user,rss,args | grep '[p]hp-fpm'
Plesk PHP sürümleri ayrı servisler kullanabilir. Listede olmayan bir servis adını tahmin ederek yeniden başlatmayın. RSS sütunu KiB cinsinden anlık bellek kullanımını gösterir; birkaç farklı yük anında ölçün.
2. Kapasite mi, uzun istek mi?
sudo journalctl -u php-fpm --since '30 minutes ago' --no-pager
php-fpm yerine ilk adımda bulduğunuz birim adını yazın. “server reached pm.max_children” kapasite sınırına işaret eder. Veritabanı beklemesi de çalışanları meşgul ederek aynı hatayı üretebilir; yalnızca çalışan sayısını artırmak kök nedeni çözmez.
3. Havuz ayarını hesaplayın
Örnek: PHP için ayırdığınız 1 GiB ve ölçülen yaklaşık 100 MiB çalışan kullanımı, diğer paylar hariç yaklaşık 10 çalışan üst sınırı verir. Bu bir başlangıç tahminidir, tüm sunucunun RAM'ini PHP'ye ayırmayın. Panel yönetimindeki ayarları panelden değiştirin; üretilen dosyalar yeniden yazılabilir.
; Havuz dosyası için açıklayıcı örnek
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
4. Güvenli uygulama ve kontrol
Dosyanın yedeğini alın; o servisin kullandığı FPM binary'si ile -t yapılandırma testini çalıştırın. Test başarılıysa yalnızca ilgili servisi reload edin. Yoğun saatte hata oranını, yanıt süresini ve RAM kullanımını karşılaştırın. Daha fazla swap veya OOM görürseniz eski havuz ayarına dönün. FPM durum sayfasını açarsanız dış erişime kapatın; süreç ve istek bilgileri içerir.
Test komutunun gerçek binary ile kullanımı
Panel dışı standart kurulumda binary gerçekten /usr/sbin/php-fpm ise:
sudo /usr/sbin/php-fpm -t
Plesk PHP 8.3 örneğinde mevcut binary yolunu kontrol edip:
sudo /opt/plesk/php/8.3/sbin/php-fpm -t
Servis özel -y config yolu kullanıyorsa aynı config'i test edin; farklı dosyayı başarılı test etmek çalışan havuzu doğrulamaz. systemctl cat ile ilgili birimin ExecStart satırını inceleyebilirsiniz. Test başarısızsa reload yapmayın. Başarılı test sonrası doğru servis birimini reload edip yeni logları kontrol edin.
Bilgiyi uygulanabilir projeye dönüştürelim.
İhtiyacınızı teknik, operasyonel ve ticari açıdan değerlendirip doğru çözüm yol haritasını birlikte oluşturalım.
Projenizi Anlatın



