PHP-FPM (FastCGI Process Manager): Eksiksiz Kurulum, Yapılandırma ve Optimizasyon Kılavuzu

PHP-FPM (PHP FastCGI Process Manager), FastCGI protokolünü uygulayarak PHP yürütmesini web sunucusu sürecinden ayıran yüksek performanslı bir alternatif PHP süreç yöneticisidir. Geleneksel CGI’nin yaptığı gibi her gelen HTTP isteği için yeni bir PHP yorumlayıcısı başlatmak yerine, PHP-FPM istekleri kabul eden, yürüten ve PHP yanıtlarını çok daha düşük ek yükle döndüren kalıcı bir çalışan süreç havuzu tutar.

WordPress, Laravel, Symfony veya özel PHP uygulamaları çalıştıran herhangi bir üretim web sunucusu için PHP-FPM, standart uygulama işleyicisidir. Süreç yaşam döngüsü, bellek sınırları, istek kuyruğu ve uygulama başına izolasyon üzerinde ayrıntılı kontrol sağlar — bunlar mod_php veya düz CGI ile mümkün olmayan yeteneklerdir.

PHP-FPM’in CGI ve mod_php’den Farkı

PHP-FPM’in neden önemli olduğunu anlamak için, neyin yerini aldığını ve bu alternatiflerin ölçekte neden yetersiz kaldığını tam olarak görmek yardımcı olur.

CGI, her istek için yeni bir işletim sistemi süreci çatallar. Orta düzey trafikte bu, dakikada binlerce çatal/yürüt/çıkış döngüsü oluşturarak CPU ve belleği doyurur. mod_php, PHP yorumlayıcısını doğrudan her Apache çalışanına gömer; bu, statik bir görüntü sunan bir Apache süreci bile olsa her Apache sürecinin tam PHP çalışma zamanını bellekte taşıdığı anlamına gelir. PHP-FPM her iki sorunu da çözer: çalışanlar kalıcıdır ve web sunucusundan tamamen ayrıdır; böylece NGINX veya Apache statik varlıkları yerel olarak işlerken PHP-FPM yalnızca PHP yürütmesini üstlenir.

PHP-FPM Mimarisi: Ayrıntılı İstek Akışı

İç istek yolunu anlamak, ayarlama ve hata ayıklama için gereklidir.

1. Bir tarayıcı .php kaynağı için HTTP isteği gönderir.
2. Web sunucusu (NGINX veya Apache) isteği alır ve bir konum bloğu veya FilesMatch yönergesine göre eşleştirir.
3. Web sunucusu isteği FastCGI protokolü aracılığıyla PHP-FPM’e iletir — ya bir Unix alan soketi (/run/php/php8.2-fpm.sock) ya da bir TCP soketi (127.0.0.1:9000) üzerinden.
4. PHP-FPM’in ana süreci, isteği yapılandırılmış havuzdan uygun bir çalışana yönlendirir.
5. Çalışan PHP betiğini yürütür, stdout‘a yazar ve yanıtı web sunucusuna döndürür.
6. Web sunucusu işlenmiş HTML’yi istemciye iletir.
7. Çalışan süreç sonlanmaz — bir sonraki istek için hazır olarak boşta havuzuna geri döner.

Unix soketleri, yerel iletişim için TCP’ye tercih edilir; çünkü TCP/IP yığınını tamamen atlayarak kıyaslamalarda gecikmeyi %10–20 azaltır ve port bağlama ile geri döngü yönlendirme ek yükünü ortadan kaldırır.

Süreç Yönetimi Modları

PHP-FPM üç pm (süreç yöneticisi) modunu destekler ve yanlış birini seçmek en yaygın yanlış yapılandırma hatalarından biridir.

pm = static

Trafikten bağımsız olarak her zaman sabit sayıda çalışan çalışır. Bunu, öngörülebilir, önceden ayrılmış bellek istediğiniz ve boşta kalma ek yükünü karşılayabileceğiniz özel sunucularda kullanın.

pm = static
pm.max_children = 20

pm = dynamic

PHP-FPM temel sayıda çalışanla başlar ve tanımlı sınırlar içinde yukarı veya aşağı ölçeklenir. Bu en yaygın kullanılan moddur ve çoğu VPS Hosting ortamı için doğru varsayılandır.

pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500

pm = ondemand

Çalışanlar yalnızca bir istek geldiğinde oluşturulur ve pm.process_idle_timeout saniyelik hareketsizlikten sonra sonlandırılır. Bu, boşta bellek tüketimini en aza indirir ve düzinelerce havuzun bir arada bulunduğu düşük trafikli siteler veya paylaşımlı ortamlar için idealdir.

pm = ondemand
pm.max_children = 20
pm.process_idle_timeout = 10s

Kritik tuzak: ondemand, boşta kalma süresinden sonraki ilk istekte soğuk başlatma gecikmesi yaratır. Gecikmeye duyarlı uygulamalar için dynamic her zaman daha iyi bir seçimdir.

pm.max_children’ı Doğru Hesaplama

Çoğu yöneticinin maliyetli hatalar yaptığı yer burasıdır. pm.max_children‘ı çok yüksek ayarlamak bellek tükenmesine ve OOM sonlandırmalarına yol açar; çok düşük ayarlamak ise yük altında istek kuyruğuna ve 502 hatalarına neden olur.

Doğru formül:

pm.max_children = (Available RAM for PHP) / (Average PHP worker memory usage)

Ortalama PHP çalışan belleğini bulmak için:

ps --no-headers -o "rss,cmd" -C php-fpm8.2 | awk '{ sum+=$1 } END { printf "Average: %d MBn", sum/NR/1024 }'

NGINX, MySQL ve işletim sisteminin ~600 MB tükettiği 2 GB RAM’li bir VPS’de PHP için yaklaşık 1.400 MB’ınız vardır. Her çalışan ~70 MB kullanıyorsa, güvenli pm.max_children değeriniz 20’dir. Bunu asla tahmine dayalı olarak ayarlamayın.

PHP-FPM Kurulumu

Debian / Ubuntu

sudo apt update
sudo apt install php8.2-fpm
sudo systemctl enable php8.2-fpm
sudo systemctl start php8.2-fpm

CentOS / AlmaLinux / RHEL (Remi deposuyla)

sudo dnf install epel-release
sudo dnf install https://rpms.remirepo.net/enterprise/remi-release-9.rpm
sudo dnf module enable php:remi-8.2
sudo dnf install php-fpm
sudo systemctl enable php-fpm
sudo systemctl start php-fpm

Servisin çalıştığını doğrulayın ve soket yolunu onaylayın:

sudo systemctl status php8.2-fpm
ls -la /run/php/

PHP-FPM Havuzlarını Yapılandırma

Ana PHP-FPM yapılandırması /etc/php/8.2/fpm/php-fpm.conf‘da bulunur, ancak bireysel havuz tanımları /etc/php/8.2/fpm/pool.d/‘a aittir. RHEL tabanlı sistemlerde havuz dosyaları /etc/php-fpm.d/‘da bulunur.

Her havuz izole bir yürütme ortamıdır. Aynı sunucuda birden fazla PHP uygulaması çalıştırmak — örneğin bir WordPress sitesi ve bir Laravel API — ayrı kullanıcılar, soket yolları ve kaynak sınırlarıyla ayrı havuz dosyaları oluşturmak anlamına gelir. Bu, çok kiracılı kurulumlar için doğru mimaridir ve tek bir havuzu paylaşmaktan çok daha güvenlidir.

Örnek: Üretim Havuzu Yapılandırması

[myapp]
user = myapp
group = myapp

; Unix socket — always prefer this over TCP for local communication
listen = /run/php/myapp-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

; Process manager
pm = dynamic
pm.max_children = 30
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 10
pm.max_requests = 1000

; Slow log — log requests taking longer than 2 seconds
slowlog = /var/log/php-fpm/myapp-slow.log
request_slowlog_timeout = 2s

; Status and ping endpoints
pm.status_path = /fpm-status
ping.path = /fpm-ping

; Environment isolation
clear_env = yes
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin

; PHP value overrides per pool
php_admin_value[error_log] = /var/log/php-fpm/myapp-error.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 256M
php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M

clear_env = yes yönergesi, sıklıkla göz ardı edilen güvenlik açısından kritik bir ayardır. Bu ayar olmadan, PHP çalışanları ana süreçten tüm ortam değişkenlerini devralır ve potansiyel olarak hassas sistem düzeyindeki verileri uygulamanızın $_ENV‘una sızdırabilir.

PHP-FPM’i NGINX ile Entegre Etme

NGINX’in yerel PHP yürütme yeteneği yoktur — PHP isteklerini devretmek için tamamen FastCGI’ye dayanır. Bu aslında mimari bir avantajdır: NGINX statik dosyaları neredeyse sıfır maliyetle işlerken PHP-FPM yalnızca yürütme gerektirenleri işler.

server {
    listen 80;
    server_name example.com;
    root /var/www/myapp/public;
    index index.php index.html;

    # Serve static files directly, no PHP involvement
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # Delegate PHP to PHP-FPM
    location ~ .php$ {
        # Security: prevent executing uploaded files as PHP
        try_files $uri =404;
        fastcgi_split_path_info ^(.+.php)(/.+)$;

        fastcgi_pass unix:/run/php/myapp-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;

        # Performance tuning
        fastcgi_buffers 16 16k;
        fastcgi_buffer_size 32k;
        fastcgi_read_timeout 300;
    }

    # Block access to the FPM status page from public
    location ~ ^/(fpm-status|fpm-ping)$ {
        allow 127.0.0.1;
        deny all;
        fastcgi_pass unix:/run/php/myapp-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

Güvenlik notu: fastcgi_pass‘dan önce gelen try_files $uri =404; satırı isteğe bağlı değildir. Bu olmadan NGINX, var olmayan dosyalar için istekleri PHP-FPM’e iletir; bu da bir saldırganın PHP kodu içeren bir görüntü yükleyip sunucuyu bunu yürütmesi için kandırdığı yol geçiş saldırılarına olanak tanır.

PHP-FPM’i Apache ile Entegre Etme

Apache, PHP-FPM ile iletişim kurmak için mod_proxy_fcgi‘a ihtiyaç duyar. mod_php‘dan farklı olarak bu yaklaşım, Apache’nin PHP-FPM’i ayrı bir kullanıcı olarak çalıştırmasına olanak tanıyarak izolasyonu iyileştirir.

sudo a2enmod proxy_fcgi setenvif
sudo systemctl restart apache2

Sanal ana bilgisayar yapılandırması:

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/myapp/public

    <Directory /var/www/myapp/public>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    <FilesMatch ".php$">
        SetHandler "proxy:unix:/run/php/myapp-fpm.sock|fcgi://localhost/"
    </FilesMatch>

    ErrorLog ${APACHE_LOG_DIR}/myapp-error.log
    CustomLog ${APACHE_LOG_DIR}/myapp-access.log combined
</VirtualHost>

PHP-FPM Durum Sayfasını Etkinleştirme ve Kullanma

Yerleşik durum sayfası, PHP-FPM’in en az kullanılan tanılama araçlarından biridir. Havuz dosyasında pm.status_path yapılandırıldıktan sonra doğrudan sorgulayın:

sudo -u www-data SCRIPT_NAME=/fpm-status SCRIPT_FILENAME=/fpm-status REQUEST_METHOD=GET cgi-fcgi -bind -connect /run/php/myapp-fpm.sock

Ya da kısıtlı bir dahili uç noktada açığa çıkardıktan sonra curl aracılığıyla daha pratik biçimde:

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

İzlenecek temel metrikler:

• listen queue: Boş bir çalışan bekleyen istekler. Sürekli yük altında 0’ın üzerindeki herhangi bir değer, pm.max_children‘ın çok düşük olduğu anlamına gelir.
• active processes: Şu anda PHP yürüten çalışanlar. Bu sürekli olarak pm.max_children‘a eşitse kapasiteye ulaşmışsınızdır.
• slow requests: request_slowlog_timeout‘ı aşan isteklerin kümülatif sayısı. Artan bir sayı, uygulama düzeyinde darboğazlara işaret eder.

Performans Hata Ayıklaması için Yavaş Günlük Kullanımı

Yavaş günlük, yapılandırılan eşiği aşan herhangi bir istek için tam PHP yığın izini yakalar. Bu, tam bir profil oluşturucuya ihtiyaç duymadan N+1 sorgu sorunlarını, engelleyici G/Ç çağrılarını veya verimsiz döngüleri tespit etmek için paha biçilmezdir.

slowlog = /var/log/php-fpm/myapp-slow.log
request_slowlog_timeout = 2s

Yavaş günlük girişi şöyle görünür:

[21-Jun-2025 14:32:11]  [pool myapp] pid 18432
script_filename = /var/www/myapp/public/index.php
[0x00007f3b4c001e80] PDOStatement->execute() /var/www/myapp/vendor/laravel/framework/src/Illuminate/Database/Connection.php:338
[0x00007f3b4c001d40] runQueryCallback() /var/www/myapp/vendor/laravel/framework/src/Illuminate/Database/Connection.php:295

Bu, darboğazın PHP mantığı değil bir veritabanı sorgusu olduğunu hemen söyler — optimizasyon çabanızı tam olarak yönlendirir.

OPcache ile PHP-FPM: Temel İkili

PHP-FPM tek başına süreç yönetimini üstlenir; OPcache ise her istekte PHP kaynak dosyalarını ayrıştırma ve derleme maliyetini ortadan kaldırır. Birlikte, Linux üzerinde PHP için eksiksiz performans yığınını oluştururlar.

OPcache’i /etc/php/8.2/fpm/php.ini‘da veya özel bir /etc/php/8.2/fpm/conf.d/10-opcache.ini‘da etkinleştirin ve ayarlayın:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=0
opcache.validate_timestamps=0
opcache.jit_buffer_size=128M
opcache.jit=tracing

validate_timestamps=0 ayarı, her istekte dosya değişikliği kontrollerini devre dışı bırakır — üretimde önemli bir performans kazancı. Yeni kod dağıttığınızda önbellek sıfırlamayı açıkça tetikleyin:

sudo systemctl reload php8.2-fpm

cPanel’li bir VPS’de, OPcache ayarları genellikle PHP yapılandırma arayüzünde sunulur, ancak .ini dosyaları aracılığıyla manuel ayarlama her zaman daha ince kontrol sağlar.

PHP-FPM için Güvenlik Sertleştirmesi

Her Havuzu Özel Bir Sistem Kullanıcısı Olarak Çalıştırın

PHP-FPM havuzlarını asla root olarak veya birden fazla uygulama genelinde paylaşılan bir www-data kullanıcısı olarak çalıştırmayın. Uygulama başına özel bir sistem kullanıcısı oluşturun:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp

Ardından havuz yapılandırmasında user = myapp ve group = myapp‘ı ayarlayın. Bu, güvenliği ihlal edilmiş bir PHP uygulamasının aynı sunucudaki diğer uygulamalara ait dosyaları okuyamamasını sağlar.

PHP Fonksiyonlarını Kısıtlayın

Havuzun php_admin_value bloğunda, web uygulamalarında meşru kullanımı olmayan fonksiyonları devre dışı bırakın:

php_admin_value[disable_functions] = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

Open Basedir’i Sınırlandırın

PHP’nin dosya erişimini uygulama diziniyle sınırlayın:

php_admin_value[open_basedir] = /var/www/myapp:/tmp

Katı İzinlerle Unix Soketleri Kullanın

TCP soketleri (127.0.0.1:9000) sunucudaki herhangi bir süreç tarafından erişilebilirdir. listen.mode = 0660 ile Unix soketleri, erişimi yalnızca sahip olan kullanıcı ve grupla kısıtlar.

Tam Yığını Doğrulama

PHP-FPM ve web sunucunuzu yapılandırdıktan sonra, yayına geçmeden önce tüm zinciri doğrulayın.

Tüm servisleri yeniden yükleyin:

sudo systemctl reload php8.2-fpm
sudo systemctl reload nginx
# or
sudo systemctl reload apache2

Yeniden yüklemeden önce NGINX yapılandırma sözdizimini test edin:

sudo nginx -t

Geçici bir bilgi dosyası oluşturun (doğrulamadan sonra kaldırın — hassas sunucu verilerini açığa çıkarır):

echo "<?php phpinfo();" | sudo tee /var/www/myapp/public/phpinfo.php

Bir tarayıcıda http://example.com/phpinfo.php‘ı açın ve şunları onaylayın:

• Server API FPM/FastCGI gösteriyor
• PHP Version kurulu sürümle eşleşiyor
• OPcache bölümü mevcut ve etkin

Ardından dosyayı hemen kaldırın:

sudo rm /var/www/myapp/public/phpinfo.php

Çok Uygulamalı ve Yüksek Trafikli Ortamlarda PHP-FPM

Düzinelerce PHP uygulaması barındıran bir Dedicated Server‘da çok havuzlu mimari zorunlu hale gelir. Her uygulama, bağımsız olarak ayarlanmış pm.max_children, bellek sınırları ve yavaş günlük yollarıyla kendi havuzunu alır. Çalışan havuzunu tüketen hatalı davranan bir uygulama, diğer uygulamaları etkilemez.

Yüksek trafikli senaryolar için PHP-FPM’i şunlarla birleştirin:

• Tekrarlanan istekler için PHP-FPM’i tamamen atlayarak önbelleğe alınmış PHP yanıtlarını statik dosyalar olarak sunmak için NGINX FastCGI önbellekleme (fastcgi_cache)
• Yük altında G/Ç çekişmesi yaratan varsayılan dosya tabanlı oturumların yerini alan PHP oturum depolama için Redis veya Memcached
• Ayrı bir ön uç düğümünde NGINX ile bir yük dengeleyicinin arkasındaki uygulama sunucularında PHP-FPM çalıştırarak yatay ölçekleme

Yığınınız SSL sonlandırma içeriyorsa, NGINX katmanında düzgün yapılandırılmış SSL Sertifikaları ile PHP-FPM’i eşleştirmek, TLS el sıkışmalarının istekler PHP-FPM’e ulaşmadan önce işlenmesini sağlar; böylece PHP çalışanları yalnızca uygulama mantığına odaklanır.

Hesaplama yoğun PHP iş yükleri için — PHP bağlamaları aracılığıyla makine öğrenmesi çıkarımı, görüntü işleme veya video dönüştürme — PHP-FPM’in web katmanı için standart istek işlemeyi sürdürürken ağır hesaplamayı GPU hızlandırmalı kütüphanelere devredebildiği GPU Hosting‘i düşünün.

Temel Karar Matrisi ve Teknik Kontrol Listesi

PHP-FPM’i üretimde dağıtmadan önce bu kontrol listesindeki her öğeyi doğrulayın:

Süreç Yöneticisi Seçimi

• Genel amaçlı VPS iş yükleri için pm = dynamic kullanın
• pm = static‘ı yalnızca öngörülebilir, sürekli trafiğe sahip özel sunucularda kullanın
• pm = ondemand‘ı yalnızca düşük trafikli veya geliştirme havuzları için kullanın

Kapasite Planlaması

• pm.max_children‘ı ayarlamadan önce ps ile gerçek çalışan belleğini ölçün
• İşletim sistemi, web sunucusu ve veritabanı için toplam RAM’in en az %20’sini ayırın
• Bellek sızıntısı birikimini önlemek için pm.max_requests‘ı 500–1000 arasında ayarlayın

Güvenlik

• Her uygulama havuzu kendi sistem kullanıcısı olarak çalışır
• clear_env = yes her havuzda ayarlanmıştır
• open_basedir dosya erişimini uygulama diziniyle kısıtlar
• disable_functions kabuk yürütme fonksiyonlarını engeller
• TCP soketleri yerine Unix soketleri kullanılır

Gözlemlenebilirlik

• pm.status_path yapılandırılmış ve yalnızca localhost’tan erişilebilir
• slowlog 2–5 saniyelik request_slowlog_timeout ile etkin
• Tüm PHP-FPM günlük dosyaları için günlük rotasyonu yapılandırılmış

Performans

• OPcache, üretimde validate_timestamps=0 ile etkin
• Önbelleğe alınabilir uç noktalar için NGINX FastCGI önbellekleme yapılandırılmış
• PHP oturum işleyicisi dosyalar değil Redis veya Memcached olarak ayarlanmış

Operasyonel

• Sıfır kesinti süreli yapılandırma değişiklikleri için restart yerine sudo systemctl reload php8.2-fpm kullanılır
• phpinfo.php doğrulamadan hemen sonra belge kökünden kaldırılır
• Havuz yapılandırması uygulama koduyla birlikte sürüm kontrolünde tutulur

SSS

PHP-FPM ile mod_php arasındaki fark nedir?

mod_php, PHP yorumlayıcısını her Apache çalışan sürecine gömer; statik dosyalar sunarken bile bellek tüketir ve PHP’yi Apache’ye sıkıca bağlar. PHP-FPM tamamen ayrı bir servis olarak çalışır, FastCGI aracılığıyla iletişim kurar, NGINX dahil herhangi bir web sunucusuyla çalışır ve bağımsız kaynak sınırlarıyla uygulama başına süreç izolasyonuna olanak tanır.

PHP-FPM için Unix soketi ile TCP soketi arasında nasıl seçim yaparım?

PHP-FPM ve web sunucusu aynı fiziksel veya sanal makinede çalıştığında Unix soketi (listen = /run/php/app-fpm.sock) kullanın. Unix soketleri TCP/IP yığınını atlayarak gecikmeyi azaltır ve port çakışmalarını ortadan kaldırır. TCP soketi (listen = 127.0.0.1:9000) yalnızca PHP-FPM web sunucusundan farklı bir ana bilgisayarda çalıştığında kullanın.

Yük altında neden 502 Bad Gateway hataları alıyorum?

NGINX’ten PHP-FPM’e işaret eden bir 502, neredeyse her zaman dinleme kuyruğunun dolu olduğu anlamına gelir — tüm çalışanlar meşgul ve yeni bağlantılar reddediliyor. Sıfır olmayan bir listen queue değeri için pm.status_path‘ı kontrol edin. Çözüm, pm.max_children‘ı artırmak (RAM izin veriyorsa) veya yavaş günlük aracılığıyla tespit edilen yavaş PHP betiklerini optimize etmektir.

Aktif bağlantıları kesmeden PHP-FPM’i nasıl yeniden yüklerim?

restart yerine sudo systemctl reload php8.2-fpm kullanın. reload sinyali (SIGUSR2), ana sürecin çalışanları sorunsuz biçimde yeniden başlatmasına neden olur: mevcut istekler normal şekilde tamamlanırken yeni çalışanlar güncellenmiş yapılandırmayı devralır. Sert bir restart tüm çalışanları anında sonlandırarak uçuştaki istekleri düşürür.

PHP-FPM bir sunucuda birden fazla PHP sürümünü aynı anda çalıştırabilir mi?

Evet. Birden fazla PHP sürümü (örn. php7.4-fpm ve php8.2-fpm) yükleyin ve her uygulama havuzunu uygun soket yolunu kullanacak şekilde yapılandırın. NGINX’te, sunucu bloğu başına doğru sokete fastcgi_pass ile işaret edin. Bu, VPS Control Panels aracılığıyla yönetilen paylaşımlı altyapıda standart bir kalıptır ve root erişimiyle VPS Hosting‘de tam olarak desteklenir.