PHP-FPM Tuning: come ottimizzare pool, processi e memoria

PHP-FPM è spesso il collo di bottiglia nascosto di un sito WordPress, di un e-commerce o di un portale con traffico variabile. Quando è configurato bene, riduce i tempi di risposta, evita i timeout e sfrutta meglio CPU e RAM. Quando è configurato male, genera il classico effetto domino: code di richieste, processi bloccati, memoria esaurita e siti che sembrano “lenti” anche se il web server è sano.

Il punto non è “mettere più processi”. Il punto è dimensionare correttamente i pool, capire quanta memoria consuma ogni worker, scegliere il metodo di gestione più adatto e verificare i risultati con dati reali. In questa guida trovi un approccio pratico, pensato per ambienti Linux, VPS, server hosting e pannelli come cPanel, Plesk e FastPanel.

Prima di toccare la configurazione

Prima di modificare PHP-FPM, conviene raccogliere tre informazioni semplici: quanta RAM libera ha il server, quanta memoria consuma in media un processo PHP e quale traffico reale gestisce il sito. Senza questi dati si rischia di aumentare i processi fino a saturare la RAM, peggiorando le prestazioni invece di migliorarle.

Controlli utili:

• RAM disponibile: deve restare margine per sistema operativo, web server, database e cache.
• Consumo medio per processo PHP: va misurato sui siti reali, non stimato a occhio.
• Picchi di concorrenza: conta quante richieste contemporanee arrivano nei momenti di carico.

Se hai accesso SSH, un controllo rapido può essere questo:

free -h
ps -ylC php-fpm --sort:rss

Il primo comando mostra quanta memoria è disponibile. Il secondo aiuta a vedere i processi PHP-FPM ordinati per RSS, utile per stimare il peso medio di un worker. Su server con più versioni di PHP, il nome del processo può cambiare leggermente, ad esempio php-fpm8.1 o php-fpm8.2.

Come funziona PHP-FPM in pratica

PHP-FPM lavora con uno o più pool, cioè gruppi di processi PHP dedicati a uno o più siti. Ogni pool può avere utenti, socket, limiti di processi e regole diverse. Questa separazione è una delle sue forze principali: permette di isolare siti diversi e di assegnare risorse in modo più preciso.

I parametri più importanti sono:

• pm: definisce la strategia di gestione dei processi.
• pm.max_children: numero massimo di processi simultanei nel pool.
• pm.start_servers, pm.min_spare_servers, pm.max_spare_servers: contano i processi iniziali e quelli tenuti in attesa.
• pm.max_requests: numero di richieste dopo cui un processo viene riciclato.
• request_terminate_timeout: tempo massimo prima di terminare una richiesta troppo lunga.
• php_admin_value[memory_limit]: limite di memoria lato PHP, utile per evitare esplosioni incontrollate.

La vera metrica da capire è pm.max_children. Se è troppo basso, le richieste restano in coda. Se è troppo alto, la RAM finisce e il server inizia a swappare o a uccidere processi. In entrambi i casi, il sito rallenta.

Metodo corretto per calcolare i processi

Il calcolo più solido parte dalla memoria disponibile per PHP e dal consumo medio di un processo. La formula pratica è semplice:

pm.max_children = RAM assegnabile a PHP / memoria media per processo

Esempio realistico: se puoi destinare 2 GB a PHP-FPM e un processo medio consuma 70 MB, il pool può sostenere circa 28 processi. In pratica conviene stare un po’ più bassi per lasciare margine a picchi, frammentazione e servizi collaterali. Quindi potresti partire da 20-24.

Attenzione a non usare la RAM totale del server. Va sottratto tutto ciò che non è PHP: sistema operativo, MySQL/MariaDB, Nginx o Apache, Redis, cache, agent di monitoraggio e spazio di sicurezza. Su un server da 4 GB, non è raro che PHP abbia davvero disponibile solo 1-1,5 GB.

Un modo semplice per stimare il consumo medio di un processo è osservare il valore RSS di più worker durante il carico reale. Se i processi stanno quasi sempre tra 50 e 90 MB, usa una media prudente, non il minimo assoluto. Il minimo inganna: in produzione conta il consumo sotto carico, con plugin, template e richieste reali.

Scelta del metodo pm

PHP-FPM offre tre modalità principali:

• static: numero fisso di processi sempre attivi.
• dynamic: numero variabile con minimo e massimo controllati.
• ondemand: i processi nascono solo quando arrivano richieste.

La scelta giusta dipende dal tipo di sito e dal profilo del server.

Static

È utile quando il carico è costante e prevedibile, ad esempio su applicazioni con traffico stabile e hosting dedicato. Ha tempi di risposta molto regolari, ma consuma memoria in modo continuo. Su server piccoli o con molti siti, può essere troppo costoso.

Dynamic

È spesso la scelta migliore in hosting e VPS. Mantiene un numero minimo di processi pronti, ma scala verso l’alto in caso di picco. È un buon compromesso tra reattività e uso della RAM.

Ondemand

È interessante per siti poco visitati o pool secondari, perché riduce il consumo a riposo. Però introduce un piccolo ritardo al primo avvio del processo e può essere meno adatto a carichi intensi o molto intermittenti.

Nella maggior parte dei casi reali, dynamic è la base più sicura da cui partire.

Valori iniziali consigliati

Non esiste una configurazione universale, ma ci sono valori di partenza ragionevoli. L’obiettivo è partire conservativi, osservare i log e poi rifinire.

Per un pool medio su server VPS con carico moderato:

• pm = dynamic
• pm.max_children: calcolato in base alla RAM disponibile, spesso tra 10 e 40 su VPS piccole e medie
• pm.start_servers: 2 o 4
• pm.min_spare_servers: 2 o 4
• pm.max_spare_servers: 4 o 8
• pm.max_requests: 300 o 500

Per un sito WordPress con plugin pesanti o WooCommerce, conviene partire con cautela. Meglio meno processi, ma stabili, che saturare la memoria con troppi worker. Se il server regge bene, si aumenta gradualmente.

Per un sito con pochissimo traffico ma che deve restare economico, ondemand può essere una buona opzione. In quel caso, però, bisogna accettare che il primo accesso possa essere leggermente più lento.

Configurazione del pool: esempio pratico

Su sistemi Linux classici, i file del pool si trovano spesso in percorsi simili a:

• /etc/php/8.2/fpm/pool.d/www.conf
• /etc/php-fpm.d/www.conf
• /etc/opt/remi/php82/php-fpm.d/www.conf

Prima di cambiare qualcosa, crea sempre un backup del file:

cp /etc/php/8.2/fpm/pool.d/www.conf /etc/php/8.2/fpm/pool.d/www.conf.bak

Esempio di configurazione di partenza per un pool dinamico:

[www]
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 8
pm.max_requests = 500
request_terminate_timeout = 120s

Questi valori non sono “magici”, ma sensati come baseline. Se il server ha molta RAM libera e il consumo medio per worker è basso, pm.max_children può essere aumentato. Se invece la RAM è stretta, va ridotto. Il vero obiettivo è evitare la saturazione, non inseguire numeri alti.

In alcuni casi è utile aggiungere limiti per la memoria PHP direttamente nel pool:

php_admin_value[memory_limit] = 256M

Questo non sostituisce il tuning del sistema, ma aiuta a contenere gli script difettosi o i plugin troppo pesanti. Attenzione: se il sito richiede davvero più memoria, un limite troppo stretto può causare errori fatali. Va quindi bilanciato con i requisiti dell’applicazione.

Come scegliere pm.max_children senza andare a tentoni

Il numero di processi massimi è il parametro più delicato. Un metodo pratico è questo:

1. Misura il consumo medio RSS di almeno 10 processi PHP durante il traffico normale.
2. Calcola quanta RAM vuoi riservare a PHP-FPM, lasciando margine per il resto.
3. Dividi la RAM riservata per il consumo medio.
4. Riduci il risultato di un 10-20% per sicurezza.

Esempio: 1,5 GB disponibili per PHP, consumo medio 75 MB. Il calcolo teorico porta a 20 processi. Un valore prudente iniziale potrebbe essere 16-18. Se i log mostrano attese in coda e la RAM resta stabile, puoi salire.

Se il server usa più pool, non dimenticare che ogni pool ha il suo pm.max_children. La somma totale dei processi di tutti i pool deve essere compatibile con la RAM reale del server. È qui che molti ambienti vanno fuori equilibrio: ogni singolo pool sembra corretto, ma l’insieme supera la capacità del nodo.

Segnali che il tuning è sbagliato

Ci sono sintomi molto chiari che indicano una configurazione da correggere:

• timeout intermittenti con codice 504 o 502
• pagine lente solo nelle ore di punta
• processi PHP in coda
• RAM al limite e swap in uso
• riavvii frequenti di PHP-FPM
• errori tipo “server reached pm.max_children setting”

Se compare il messaggio di raggiungimento di pm.max_children, il problema non è quasi mai “aggiungere processi a caso”. Prima va verificato se il server ha davvero RAM sufficiente. Se la memoria è già satura, aumentare il limite peggiora solo il collasso.

Se invece la CPU è alta ma la RAM è stabile, il collo di bottiglia può essere altrove: query lente, plugin pesanti, I/O disco, mancanza di cache o web server configurato male. PHP-FPM va ottimizzato dentro un quadro più ampio.

Verifiche da fare dopo ogni modifica

Dopo aver cambiato i parametri, non fermarti al riavvio del servizio. Verifica che il comportamento sia migliorato davvero.

• Controlla che PHP-FPM parta senza errori di sintassi.
• Osserva i log del pool per eventuali saturazioni.
• Monitora RAM, swap e load average durante il traffico.
• Verifica tempi di risposta del sito e TTFB.
• Controlla eventuali errori 502/504 nel web server.

Comandi utili di verifica:

php-fpm -t
systemctl status php8.2-fpm
journalctl -u php8.2-fpm -n 50 --no-pager

Il primo comando deve restituire una configurazione valida. Il secondo deve mostrare il servizio attivo. Il terzo aiuta a intercettare warning, errori di avvio o saturazione dei processi. Il nome del servizio va adattato alla versione installata.

Tuning su cPanel, Plesk e FastPanel

Nei pannelli hosting, il principio resta lo stesso: prima diagnosi, poi modifica. Spesso il pannello semplifica la gestione dei pool, ma non elimina il bisogno di misurare.

cPanel

Su cPanel, la gestione di PHP-FPM dipende dalla combinazione tra MultiPHP e EasyApache. In genere conviene controllare la versione PHP del dominio, poi verificare se PHP-FPM è attivo per quel virtual host. Se il sito è lento, controlla anche l’uso di Apache, eventuali cache e il limite di processi del pool.

Plesk

Su Plesk, la sezione di PHP per dominio permette spesso di selezionare il gestore FastCGI o PHP-FPM e di regolare alcune direttive. È una buona strada per hosting multi-sito, perché consente di differenziare i profili per dominio. Per siti pesanti, è utile associare il tuning PHP-FPM a cache e ottimizzazione del database.

FastPanel

Su FastPanel, la gestione dei siti e delle versioni PHP è abbastanza diretta. Anche qui è importante non limitarsi alla UI: il valore dei processi va scelto in base alla RAM reale del nodo e alla pressione del traffico. Se il pannello offre i log del servizio, usali prima di aumentare i processi.

Ottimizzazioni complementari

PHP-FPM da solo non risolve tutto. Se vuoi un risultato concreto, devi guardare anche il resto della catena.

• Opcode cache: OPcache deve essere attivo e dimensionato correttamente.
• Cache applicativa: Redis o Memcached riducono il lavoro di PHP.
• Database: query lente annullano il vantaggio di un FPM veloce.
• Web server: Nginx o Apache devono essere coerenti con il backend PHP.
• Disco: I/O lento allunga i tempi di risposta anche con CPU libera.

Se il sito è WordPress, spesso il miglior guadagno arriva da una combinazione di cache pagina, OPcache, Redis e pool PHP ben dimensionato. Aumentare solo i processi senza migliorare il resto è come allargare una strada che poi si restringe subito dopo.

Strategia di tuning consigliata

La strategia più sicura è iterativa:

1. Misura lo stato attuale del server e del pool.
2. Imposta valori prudenziali per pm.max_children e i parametri di spare.
3. Riavvia il servizio e monitora il traffico reale.
4. Se restano code e la RAM è stabile, aumenta in piccoli passi.
5. Se compare swap o instabilità, riduci subito i processi.

Questo approccio evita il classico errore di “ottimizzare” al buio. Ogni cambiamento deve essere piccolo, verificabile e reversibile.

Rollback semplice e sicuro

Il rollback deve essere sempre pronto prima della modifica. Se qualcosa va storto, torna alla configurazione precedente invece di improvvisare.

Procedura di ritorno:

1. Ripristina il file di backup del pool.
2. Verifica la sintassi della configurazione.
3. Riavvia PHP-FPM.
4. Controlla i log e il comportamento del sito.

cp /etc/php/8.2/fpm/pool.d/www.conf.bak /etc/php/8.2/fpm/pool.d/www.conf
php-fpm -t
systemctl restart php8.2-fpm

Se dopo il rollback il sito torna stabile, hai confermato che il problema era nel tuning e non altrove. A quel punto puoi ripartire con una modifica più prudente.

Conclusione operativa

Il tuning di PHP-FPM non consiste nel “mettere più potenza”, ma nel distribuire bene le risorse. I parametri giusti dipendono dal consumo reale dei processi, dalla RAM disponibile, dal tipo di traffico e dal resto dello stack. Un pool ben dimensionato migliora la reattività, riduce gli errori e rende il server più prevedibile sotto carico.

Se vuoi un principio semplice da seguire, è questo: misura prima, modifica poco, verifica sempre. È il modo più solido per ottenere prestazioni senza sacrificare stabilità.

Un buon tuning PHP-FPM non cerca il massimo teorico dei processi: cerca il punto in cui il server resta veloce, stabile e con margine di sicurezza.