🥇Configurazione di PHP-FPM: utilizziamo pm static per massime prestazioni

La versione non modificata dell'articolo è stata originariamente pubblicata su haydenjames.io ed è pubblicata qui con il permesso di autore.

In poche parole, spiegherò come configurare al meglio PHP-FPM per aumentare la capacità di elaborazione, ridurre la latenza e utilizzare in modo più stabile le risorse della CPU e della memoria. Per impostazione predefinita, la stringa PM (process manager, gestore dei processi) in PHP-FPM è impostata su dynamic, se però hai poca memoria, è meglio impostare ondemand. Confrontiamo le 2 opzioni di gestione basandoci sulla documentazione di php.net e vediamo in cosa differisce il mio preferito static pm per un alto volume di traffico:

pm = dynamic — il numero di processi figlio è regolato dinamicamente in base alle seguenti direttive: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ondemand — i processi vengono creati su richiesta (a differenza della creazione dinamica, dove pm.start_servers viene avviato all'avvio del servizio).
pm = static — il numero di processi figlio è fisso e specificato dal parametro pm.max_children.

Per ulteriori dettagli, vedere nell'elenco completo delle direttive globali php-fpm.conf.

Somiglianze tra il gestore dei processi PHP-FPM e il regolatore della frequenza della CPU

Questo potrebbe sembrare off-topic, ma intendo collegarlo al tema della configurazione di PHP-FPM. Chi non ha mai avuto rallentamenti della CPU su un laptop, macchina virtuale o server dedicato? Ricordate la scalabilità della frequenza della CPU? Questi parametri disponibili per nix e Windows possono aumentare le prestazioni e la reattività del sistema se si modifica il parametro del regolatore della CPU a ondemand in performance*. Questa volta confrontiamo le descrizioni e osserviamo le somiglianze:

Governor = ondemand — scalabilità dinamica della frequenza della CPU in base al carico attuale. Passa bruscamente alla frequenza massima e poi la riduce quando aumenta il tempo di inattività.
Governor = conservative = scalabilità dinamica della frequenza in base al carico attuale. Aumenta e riduce la frequenza più dolcemente rispetto a ondemand.
Governor = performance — la frequenza è sempre massima.

Per ulteriori dettagli, vedere nell'elenco completo dei parametri del regolatore di frequenza della CPU.

Vedi la somiglianza? Volevo mostrare questo confronto per convincerti che la scelta migliore è utilizzare pm static per PHP-FPM.

Per il regolatore della CPU il parametro performance aiuta a incrementare in sicurezza le prestazioni, poiché dipende quasi interamente dal limite della CPU del server. Inoltre, ci sono fattori come la temperatura, la carica della batteria (nel portatile) e altri effetti collaterali di un uso continuativo della CPU al 100%. La configurazione delle prestazioni garantisce il funzionamento più rapido della CPU. Leggi, ad esempio, di parametro force_turbo nel Raspberry Pi, con cui la console RPi utilizzerà il regolatore performance, dove il miglioramento delle prestazioni sarà più evidente a causa della bassa frequenza di clock della CPU.

L'uso di pm static per raggiungere le massime prestazioni del server

Il parametro PHP-FPM pm static dipende molto dalla memoria disponibile sul server. Se la memoria è poca, è meglio scegliere ondemand o dynamic. D'altra parte, se hai memoria sufficiente, puoi evitare costi aggiuntivi del gestore di processi PHP impostando pm static alla massima capacità del server. In altre parole, se si calcola tutto correttamente, è necessario impostare pm.static alla massima quantità di processi PHP-FPM che possono essere eseguiti, senza creare problemi di mancanza di memoria o cache. Ma non così in alto da sovraccaricare le CPU e accumulare un sacco di operazioni PHP-FPM in attesa di esecuzione..

Nello screenshot sopra, il server è impostato su pm = static e pm.max_children = 100, che occupa circa 10 GB dei 32 disponibili. Nota le colonne evidenziate, qui è tutto chiaro. In questo screenshot c'erano circa 200 utenti attivi (per oltre 60 secondi) in Google Analytics. A questo livello, circa il 70% dei processi figli PHP-FPM è ancora inattivo. Questo significa che PHP-FPM è sempre impostato sulla massima quantità di risorse server, indipendentemente dal traffico attuale. Il processo inattivo attende i picchi di traffico e reagisce immediatamente. Non devi aspettare che pm crei processi figli, per poi terminarli quando scade il periodo pm.process_idle_timeout. Ho impostato un valore molto alto per pm.max_requests, perché questo è un server di lavoro senza perdite di memoria in PHP. Puoi impostare pm.max_requests = 0 con static, se sei completamente sicuro degli attuali e dei futuri script PHP. Ma è meglio riavviare gli script nel tempo. Imposta un numero alto di richieste, poiché vogliamo evitare costi aggiuntivi di pm. Ad esempio, almeno pm.max_requests = 1000 — a seconda del numero pm.max_children e del numero di richieste al secondo.

Nello screenshot è mostrato il comando Linux top, filtrata per u (user) e nome utente PHP-FPM. Mostra solo i primi 50 o giù di lì processi (non ho contato esattamente), ma in sostanza, top mostra le statistiche principali che vengono visualizzate nella finestra del terminale. In questo caso con ordinamento per % CPU (%CPU). Per vedere tutti i 100 processi PHP-FPM, esegui il comando:

top -bn1 | grep php-fpm

Quando usare pm ondemand e dynamic

Se si utilizza pm dynamic, si verificano errori simili:

WARNING: [pool xxxx] sembra occupato (potrebbe essere necessario aumentare pm.start_servers, o pm.min/max_spare_servers), generando 32 processi figli, ce ne sono 4 inattivi e 59 processi figli totali

Prova a modificare il parametro, l'errore non scomparirà, come descritto in questo post su Serverfault. In questo caso il valore di pm.min era troppo piccolo, e poiché il traffico web cambia notevolmente e ha picchi elevati e profondi cali, è difficile configurare adeguatamente pm dynamic. Di solito in questi casi si utilizza pm ondemand, come consigliato nello stesso post. Ma è anche peggio, poiché ondemand termina i processi inattivi fino a zero quando il traffico è basso o addirittura inesistente, e alla fine ci si troverà comunque a fare i conti con i costi derivanti dai cambiamenti di traffico. A meno che tu non abbia impostato un enorme tempo di attesa. E allora è meglio usare pm.static + un numero elevato pm.max_requests.

PM dynamic e in particolare ondemand possono essere utili se hai più pool PHP-FPM. Ad esempio, stai ospitando diversi account cPanel o diversi siti web in vari pool. Ho un server in cui, ad esempio, ci sono 100+ account cPanel e circa 200 domini, e pm.static o addirittura dynamic non mi salverebbero. Qui c'è bisogno solo di ondemand, poiché più di due terzi dei siti web ricevono poco traffico o addirittura nessuno, e con ondemand tutti i processi figli si arrestano, il che ci farà risparmiare un sacco di memoria! Fortunatamente, gli sviluppatori di cPanel se ne sono accorti e hanno impostato il valore predefinito ondemand. Prima, quando il valore di default era dynamic, PHP-FPM non era affatto adatto per server condivisi molto carichi. Molti usavano suPHP, perché pm dynamic consumava memoria anche quando i pool e gli account cPanel erano inattivi. Con ogni probabilità, con un buon traffico, non ti troverai a ospitare su un server con un numero elevato di pool PHP-FPM (hosting condiviso).

Conclusione

Se stai usando PHP-FPM e il traffico è serio, i gestori di processi ondemand e dynamic per PHP-FPM limiteranno la capacità a causa dei costi intrinseci. Analizza il tuo sistema e configura i processi PHP-FPM in base alla massima capacità del server. Inizia impostando pm.max_children a seconda dell'utilizzo massimo di pm dynamic o ondemand, quindi aumenta questo valore fino a un livello in cui memoria e processore funzionano senza sovraccarichi eccessivi. Noterai che pm static, dal momento che tutto è memorizzato in memoria, i picchi di traffico col tempo causeranno meno picchi per il processore e i valori medi di carico del server e del processore si livelleranno. La dimensione media del processo PHP-FPM dipende dal server web e richiede una configurazione manuale, quindi i gestori di processo più automatizzati sono dynamic e ondemand — più popolari. Spero che l'articolo sia stato utile.

UPD Aggiunto il diagramma delle performance ab. Se i processi PHP-FPM sono in memoria, le prestazioni aumentano grazie all'utilizzo della memoria, dove aspettano. Trova la soluzione ottimale per te.