La versione non modificata dell'articolo è stata originariamente pubblicata su e viene pubblicata qui con il permesso del suo .
In breve, ti spiegherò come ottimizzare PHP-FPM per aumentare la capacità di elaborazione, ridurre la latenza e utilizzare in modo più stabile le risorse CPU e la memoria. Di default, la linea PM (process manager, gestore dei processi) in PHP-FPM è impostata su dynamic, ma se hai poca memoria, è meglio impostare ondemand. Confrontiamo i 2 metodi di gestione basandoci sulla documentazione di php.net e vediamo cosa distingue il mio preferito static pm per un elevato volume di traffico:
pm = dynamic — il numero di processi figli è configurato 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 vengono avviati all'avvio del servizio).
pm = static — il numero di processi figli è fisso e specificato dal parametro pm.max_children.
Per dettagli, vedere il .
Somiglianze tra il gestore di processo PHP-FPM e il regolatore di frequenza della CPU
Può sembrare un argomento estraneo, ma intendo collegarlo alla configurazione di PHP-FPM. Chi non ha sperimentato il rallentamento della CPU, sia su un laptop, una macchina virtuale o un server dedicato? Ricordate la scalabilità della frequenza della CPU? Queste impostazioni, disponibili per nix e Windows, possono migliorare le prestazioni e la reattività del sistema se si modifica il parametro del regolatore della CPU da ondemand con performance*. Questa volta confrontiamo le descrizioni e osserviamo le somiglianze:
Governatore = ondemand — scalabilità dinamica della frequenza della CPU in base al carico corrente. Passa rapidamente alla frequenza massima e poi la riduce quando ci sono periodi di inattività.
Governatore = conservative = scalabilità dinamica della frequenza in base al carico corrente. Aumenta e diminuisce la frequenza in modo più uniforme rispetto a ondemand.
Governatore = performance — la frequenza è sempre massima.
Per dettagli, vedere il .
Vedi le somiglianze? Volevo mostrare questo confronto per convincerti che è meglio utilizzare pm static per PHP-FPM.
Per il regolatore della CPU, il parametro performance aiuta a incrementare in modo sicuro le prestazioni, poiché queste dipendono quasi completamente dal limite della CPU del server. Inoltre, ci sono fattori come la temperatura, la carica della batteria (nei laptop) e altri effetti collaterali del funzionamento continuo della CPU al 100%. La configurazione delle performance garantisce il funzionamento più rapido della CPU. Ad esempio, leggete di , con il quale il pannello 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 è scarsa, è meglio scegliere ondemand o dynamic. D'altra parte, se avete memoria a disposizione, potete evitare costi superflui del gestore dei processi PHP, impostando pm static alla capacità massima del server. In altre parole, se calcolato correttamente, si dovrebbe impostare pm.static al numero massimo di processi PHP-FPM che possono essere eseguiti, senza creare problemi di memoria o cache. Ma non così alto da sovraccaricare i processori e accumulare un sacco di operazioni PHP-FPM in attesa di esecuzione..
Nello screenshot sopra, il server ha impostato pm = static e pm.max_children = 100, e questo utilizza circa 10 GB dei 32 disponibili. Si noti le colonne evidenziate, qui è tutto chiaro. In questo screenshot c'erano circa 200 utenti attivi (per più di 60 secondi) in Google Analytics. A questo livello, circa il 70% dei processi figlio di PHP-FPM sono ancora inattivi. Ciò significa che PHP-FPM è sempre impostato al massimo delle risorse del server indipendentemente dal traffico attuale. Un processo inattivo attende i picchi di traffico e reagisce immediatamente. Non devi aspettare che pm crei processi figli e poi li termini 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 è statico, se sei completamente sicuro degli script PHP attuali e futuri. Ma è meglio riavviare gli script di tanto in tanto. Imposta un alto numero di richieste, dato che vogliamo evitare costi eccessivi per 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 , filtrato per u (utente) e nome utente PHP-FPM. Vengono mostrati solo i primi 50 processi circa (non li ho contati con precisione), ma, in sostanza, top mostra le statistiche che si adattano alla finestra del terminale. In questo caso è ordinato per % CPU (%CPU). Per vedere tutti i 100 processi PHP-FPM, esegui il comando:
top -bn1 | grep php-fpmQuando utilizzare pm ondemand e dynamic
Se utilizzi pm dynamic, si verificano errori simili:
WARNING: [pool xxxx] sembra occupato (potresti dover aumentare pm.start_servers, o pm.min/max_spare_servers), spawnando 32 figli, ce ne sono 4 inattivi e 59 figli totaliProva a cambiare il parametro, l'errore non scomparirà, come . In questo caso, il valore pm.min era troppo basso, e dato che il traffico web varia molto e presenta picchi alti e cali profondi, è difficile configurare pm in modo adeguato dynamic. Di solito, in questo caso si utilizza pm ondemand, . Ma questo è ancora peggio, poiché ondemand chiude i processi inattivi a zero quando c'è poco o nessun traffico, e alla fine ti ritroverai comunque a fare i conti con i costi al variare del traffico. A meno che tu non abbia impostato un tempo di attesa enorme. E allora sarebbe meglio usare pm.static + un numero elevato pm.max_requests.
PM dynamic e in particolare ondemand possono tornare utili se hai più pool PHP-FPM. Ad esempio, stai ospitando diversi account cPanel o più siti web in pool diversi. Ho un server dove, ad esempio, ci sono oltre 100 account cPanel e circa 200 domini, e pm.static o persino dynamic non mi salverebbe. Qui serve solo ondemand, poiché più di due terzi dei siti web ricevono poco traffico o nessuno affatto, e con ondemand tutti i processi figlio si fermeranno, il che ci farà risparmiare una notevole quantità di memoria! Fortunatamente, gli sviluppatori di cPanel se ne sono accorti e hanno impostato un valore predefinito ondemand. Prima, quando il valore predefinito era dynamic, PHP-FPM non era affatto adatto per server condivisi sotto carico. Molti utilizzavano suPHP, perché pm dynamic utilizza memoria anche con pool e account cPanel PHP-FPM inattivi. Probabilmente, con un buon traffico non dovresti risiedere su un server con un numero elevato di pool PHP-FPM (hosting condiviso).
Conclusione
Se utilizzi PHP-FPM e il tuo traffico è significativo, i gestori di processi ondemand e dynamic per PHP-FPM limiteranno la larghezza di banda a causa dei costi intrinseci. Analizza il tuo sistema e configura i processi PHP-FPM in base alla capacità massima del server. Inizia impostando pm.max_children in base all'utilizzo massimo di pm dynamic o ondemand, quindi aumenta questo valore fino a un livello in cui memoria e processore funzionano senza eccessivo sovraccarico. Noterai che, pm staticpoiché tutto è memorizzato in memoria, i picchi di traffico nel tempo causeranno meno picchi per il processore e le medie del carico del server e del processore si livelleranno. La dimensione media del processo PHP-FPM dipende dal server web e richiede configurazione manuale, quindi i gestori di processi più automatizzati sono dynamic e ondemand — più popolari. Spero che l'articolo sia stato utile.
UPD Aggiunto un diagramma di benchmarking . Se i processi PHP-FPM sono in memoria, le prestazioni aumentano grazie al consumo di memoria, dove rimangono in attesa. Trova l'opzione ottimale per te.
Fonte: habr.com
