Se hai acquistato un template LAMP o configurato uno stack, LAMP/LEMP, stai probabilmente usando PHP-FPM (un acronimo di FastCGI Process Manager): un’ottima alternativa più perfomante rispetto all’utilizzo di PHP come modulo Apache o PHP FastCGI.
Noi, ormai da alcuni anni, utilizziamo PHP-FPM su tutti i nuovi piani hosting condivisi e template LAMP, con ottimi risultati rispetto a mod_php, un modulo di Apache.
Come ottimizzare il consumo di RAM di PHP-FPM in ambienti Linux? Per ottenere performance ottimali e risparmiare fino al 50% di RAM, una delle possibili tecniche attuabili è la modifica di alcuni aspetti nella configurazione nel pool di PHP-FPM.
Il pool di default è www ed è situato in /etc/php-fpm.d/www.conf (in CentOS/RHEL/Fedora) o /etc/php/7.4/fpm/pool.d/www.conf (in Ubuntu/Debian/Mint). Il percorso può variare in base alla versione di php utilizzata.
$ nano /etc/php-fpm.d/www.conf [On CentOS/RHEL/Fedora] $ nano /etc/php/7.4/fpm/pool.d/www.conf [On Ubuntu/Debian/Mint]
Indice dei contenuti:
Come procedere?
Basterà cercare le seguenti direttive all’interno del file di configurazione e impostare un valore appropriato secondo il tuo use-case. In caso di direttive già commentate, sarà sufficiente togliere il commento.
pm = ondemand pm.max_children = 80 pm.process_idle_timeout = 10s pm.max_requests = 200
Cosa indicano le direttive?
La direttiva pm determina come il process manager controlla il numero di processi child. Il metodo di default è dynamic: significa che il numero di children (processi child) è impostato dinamicamente e dipendentemente da altre direttive nella configurazione, come pm.max_children, la direttiva che definisce il massimo numero di children che possono essere utilizzati nello stesso momento.
Per un consumo di memoria ottimale consigliamo il process manager ondemand: nessun child viene creato all’avvio del servizio ma vengono generati solo se necessario. I processi child sono creati solo nel caso di nuove richieste, rispettando le direttive pm.max_children e pm.process_idle_timeout. Quest’ultima definisce il numero di secondi dopo cui un processo inattivo viene terminato.
Il parametro pm.max_request definisce il numero di richieste che ogni processo child dovrebbe eseguire prima di essere ricreato. Questo parametro può essere utilizzato come workaround per memory leaks causati da librerie di terze parti.
