Configurazione PHP-FPM: utilizza pm statico per le massime prestazioni

Una versione inedita di questo articolo è stata originariamente pubblicata su haydenjames.io e pubblicato qui con il suo permesso l'autore.

Ti dirò in poche parole come configurare al meglio PHP-FPM per aumentare il throughput, ridurre la latenza e utilizzare CPU e memoria in modo più coerente. Per impostazione predefinita, la riga PM (process manager) in PHP-FPM è dinamicoe se non hai abbastanza memoria, è meglio installarlo ondemand. Confrontiamo 2 opzioni di controllo basate sulla documentazione di php.net e vediamo in che modo la mia preferita differisce da esse statico pm per traffico intenso:

pm = dinamico — 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 = su richiesta - i processi vengono creati su richiesta (a differenza della creazione dinamica, quando pm.start_servers viene avviato all'avvio del servizio).
pm = statico — il numero di processi figli è fisso ed è indicato dal parametro pm.max_bambini.

Per i dettagli, vedere elenco completo delle direttive globali php-fpm.conf.

Somiglianze tra il gestore del processo PHP-FPM e il controller di frequenza della CPU

Questo può sembrare fuori tema, ma lo collegherò all'argomento della configurazione PHP-FPM. Chi non ha riscontrato almeno una volta un rallentamento del processore, su un laptop, una macchina virtuale o un server dedicato? Ricordate il ridimensionamento della frequenza della CPU? Queste opzioni sono disponibili per nix e Windows possono migliorare le prestazioni e la reattività del sistema modificando l'impostazione della limitazione del processore da ondemand su prestazione*. Questa volta confrontiamo le descrizioni e osserviamo le somiglianze:

governatore=su richiesta — ridimensionamento dinamico della frequenza del processore in base al carico corrente. Passa rapidamente alla frequenza massima e la riduce man mano che aumentano i periodi di inattività.
governatore=conservatore= scala dinamica della frequenza in base al carico corrente. Aumenta e diminuisce la frequenza in modo più fluido rispetto a ondemand.
Governatore = prestazione — la frequenza è sempre massima.

Per i dettagli, vedere elenco completo dei parametri del regolatore di frequenza del processore.

Vedi le somiglianze? Volevo mostrare questo confronto per convincerti che è meglio usarlo pm statico per PHP-FPM.

Per il parametro del regolatore del processore performance aiuta ad aumentare in modo sicuro le prestazioni perché dipende quasi interamente dal limite della CPU del server. Oltre a questo, ovviamente, ci sono anche fattori come la temperatura, la carica della batteria (in un laptop) e altri effetti collaterali derivanti dal funzionamento costante del processore al 100%. L'impostazione delle prestazioni garantisce le prestazioni più veloci del processore. Leggi, ad esempio, su Parametro force_turbo in Raspberry Pi, con cui il pannello RPi utilizzerà il regolatore performance, dove il miglioramento delle prestazioni sarà più evidente a causa della bassa velocità di clock della CPU.

Utilizzo di pm statico per ottenere le massime prestazioni del server

Opzione PHP-FPM pm statico dipende in gran parte dalla memoria libera sul server. Se la memoria è scarsa, è meglio scegliere ondemand o dinamico. D'altra parte, se si dispone di memoria, è possibile evitare il sovraccarico del gestore processi PHP impostando pm statico alla capacità massima del server. In altre parole, se tutto è calcolato bene, bisogna stabilirlo pm.statico al volume massimo di processi PHP-FPM che possono essere eseguiti, senza creare problemi di memoria o cache insufficienti. Ma non così alto da travolgere i processori e accumulare un mucchio di operazioni PHP-FPM in attesa di essere eseguite.

Nello screenshot qui sopra, il server ha pm = statico e pm.max_children = 100, e questo occupa circa 10 GB dei 32 disponibili. Presta attenzione alle colonne evidenziate, qui è tutto chiaro. In questo screenshot c'erano circa 200 utenti attivi (più di 60 secondi) in Google Analytics. A questo livello, circa il 70% dei processi figlio PHP-FPM sono ancora inattivi. Ciò significa che PHP-FPM è sempre impostato sulla quantità massima di risorse del server indipendentemente dal traffico attuale. Un processo inattivo attende i picchi di traffico e risponde immediatamente. Non devi aspettare fino a quando pm creerà processi secondari e li terminerà allo scadere del periodo pm.process_idle_timeout. Ho impostato il valore su molto alto pm.max_requestsperché questo è un server funzionante senza perdite di memoria in PHP. Puoi installare pm.max_requests = 0 con static se sei completamente sicuro degli script PHP esistenti e futuri. Ma è meglio rieseguire gli script nel tempo. Imposta un numero elevato di richieste, perché vogliamo evitare inutili spese pm. Per esempio, almeno pm.max_requests = 1000 - a seconda della quantità pm.max_bambini e il numero di richieste al secondo.

Lo screenshot mostra il comando Linux in alto, filtrato per u (utente) e nome utente PHP-FPM. Vengono mostrati solo i primi 50 processi circa (non li ho contati esattamente), ma essenzialmente top mostra le statistiche principali 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-fpm

Quando utilizzare pm ondemand e dinamico

Se usi pm dinamico, si verificano errori come questo:

WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children

Prova a cambiare il parametro, l'errore non scomparirà, come descritto in questo post su Serverfault. In questo caso, il valore pm.min era troppo piccolo e, poiché il traffico web varia molto e presenta picchi elevati e avvallamenti profondi, è difficile regolare adeguatamente pm dinamico. Di solito viene utilizzato pm ondemand, come consigliato nello stesso post. Ma questo è ancora peggio, perché ondemand termina i processi inattivi a zero quando c'è poco o nessun traffico e ti ritroverai comunque con il sovraccarico della modifica del traffico. A meno che, ovviamente, non imposti un tempo di attesa enorme. E poi è meglio usare pm.statico + numero alto pm.max_requests.

PM dinamico e soprattutto ondemand può tornare utile se disponi di più pool PHP-FPM. Ad esempio, ospiti più account cPanel o più siti Web in pool diversi. Ho un server con, diciamo, più di 100 account cpanel e circa 200 domini, e pm.static o anche dinamico non mi salverebbero. Tutto ciò di cui hai bisogno qui è ondemand, dopo tutto, più di due terzi dei siti web ricevono poco o nessun traffico e con ondemand tutti i processi figli cadranno, il che ci farà risparmiare molta memoria! Fortunatamente, gli sviluppatori del cPanel se ne sono accorti e hanno impostato il valore su predefinito ondemand. In precedenza, quando l'impostazione predefinita era dinamico, PHP-FPM non era affatto adatto a server condivisi occupati. Molti lo hanno utilizzato suPHP, perché p.m dinamico memoria consumata anche con pool inattivi e account cPanel PHP-FPM. Molto probabilmente, se il traffico è buono, non sarai ospitato su un server con un gran numero di pool PHP-FPM (hosting condiviso).

conclusione

Se utilizzi PHP-FPM e il tuo traffico è intenso, i gestori dei processi ondemand и dinamico per PHP-FPM avrà un throughput limitato a causa del sovraccarico intrinseco. Comprendi il tuo sistema e configura i processi PHP-FPM in base alla capacità massima del server. Primo set pm.max_bambini a seconda dell'utilizzo massimo del PM dinamico o ondemand, quindi aumentare questo valore a un livello in cui la memoria e il processore funzioneranno senza essere sovraccaricati. Lo noterai con pm statico, poiché hai tutto in memoria, i picchi di traffico causeranno meno picchi di CPU nel tempo e le medie di carico del server e della CPU si stabilizzeranno. La dimensione media del processo PHP-FPM dipende dal server Web e richiede la configurazione manuale, pertanto sono necessari gestori di processi più automatizzati dinamico и ondemand - più popolare. Spero che l'articolo sia stato utile.

UPD Aggiunto grafico di riferimento ab. Se i processi PHP-FPM sono in memoria, le prestazioni aumentano a scapito del consumo di memoria dove si siedono e aspettano. Trova l'opzione migliore per te.

Fonte: habr.com