Vai al contenuto 
Bambini PHP-FPM decidono in WordPress se le richieste vengono eseguite senza problemi o se rimangono bloccate in coda. Vi mostrerò come le richieste non corrette pm.max_children-I valori bloccano le pagine, consumano RAM e il modo in cui calcolo i valori puliti.
Punti centrali
Prima di approfondire, riassumo brevemente i messaggi chiave:
- pm.max_children determina il numero di richieste PHP simultanee in esecuzione.
- Troppo poco I bambini generano code, 502/504 e TTFB elevato.
- Troppo porta a colli di bottiglia nella RAM, swap e OOM.
- FormulaRAM PHP disponibile / dimensione del processo × 0,7-0,8.
- Iterativo La messa a punto con il monitoraggio offre le migliori prestazioni a lungo termine.
Perché le pagine dei bambini di PHP-FPM si bloccano in modo errato
Ogni richiesta dinamica di WordPress richiede il proprio Lavoratore, e sono proprio questi processi che il pool controlla tramite pm.max_children. Se si imposta un valore troppo basso, le richieste si accumulano in una coda e il pool TTFB aumenta sensibilmente. Se imposto un valore troppo alto, ogni processo figlio utilizza ulteriore RAM e il server passa allo swap. Tutto rallenta nello swap finché Apache o Nginx non segnalano 502/504 o il killer OOM termina i processi. Un throughput sano si ottiene solo quando il numero di figli corrisponde al budget reale di RAM e al carico del progetto.
La formula per pm.max_children nella pratica
Inizio con una semplice formula: la RAM disponibile per PHP divisa per la dimensione media di un processo figlio, moltiplicata per uno. Fattore di sicurezza Determino la RAM per processo con ps e la colonna RSS; per i tipici stack di WordPress, 50-250 MB sono spesso corretti. Su un server da 4 GB, riservo la memoria per Linux, per il database e per i servizi di cache, lasciando circa 1,5-2 GB per i processi di WordPress. PHP rimangono. Ad esempio, se la media del processo è di 100 MB, 2.000 / 100 × 0,75 = 15 bambini. Questa cifra serve come punto di partenza, che poi perfeziono in base al profilo di carico, alla cache e al mix di plugin.
Valori iniziali per le configurazioni tipiche di WordPress
Per i piccoli blog con 2 GB di RAM, 8 bambini, pm = dynamic e pm.max_requests di circa. 800. Per i progetti di medie dimensioni con 4 GB di RAM, imposto 12 figli, start_servers 4, min_spare_servers 4. I grandi negozi con 8 GB di RAM o più beneficiano di 21-40 figli; se il carico è costantemente elevato, pm = static può garantire un throughput costante. Successivamente, verifico il rapporto tra utilizzo della CPU, della RAM e dei tempi di risposta per apportare le dovute modifiche. Se volete approfondire, potete trovare informazioni di base su impostazioni ottimali di PHP-FPM.
Misurare i processi: come determinare i requisiti RAM
Prima di impostare i valori, determino le dimensioni reali dei processi, perché le sfere di cristallo non servono e costano. Prestazioni. Il comando ps -ylC php-fpm -sort:rss restituisce le dimensioni degli RSS, che monitoro per alcuni minuti. I processi spesso crescono durante gli aggiornamenti o i cron job, per questo motivo includo i picchi nel calcolo. Uso anche htop e free -h per controllare le riserve di RAM e la quantità di swap. Uso questi dati per determinare una media affidabile e selezionare un fattore di sicurezza conservativo.
Parametri importanti in sintesi
Oltre a pm.max_children, altre opzioni del pool determinano la pulizia con cui WordPress elabora le richieste e la capacità di liberare la memoria, riducendo sensibilmente i tempi di attesa. Stabilità pm regola la modalità: dynamic adatta il numero di processi al carico, static ne mantiene un numero fisso. pm.max_requests previene il gonfiore della memoria riavviando i processi dopo X richieste. request_terminate_timeout protegge dai blocchi causati da script difettosi o lenti. Con questo set, copro il 90% dei casi pratici.
| Parametri | Funzione | Raccomandazione WordPress |
|---|---|---|
| pm | Modalità di controllo del processo | dinamico per un carico variabile; statico per un traffico costantemente elevato |
| pm.max_children | Numero massimo di lavoratori simultanei | RAM PHP disponibile / dimensione del processo × 0,75 |
| pm.max_requests | Riciclaggio dei processi | 300-1.000; piuttosto inferiore con WooCommerce |
| timeout_richiesta_termine | Cancellazione delle richieste in corso da tempo | 60-120 secondi contro le grucce |
Dinamica, ondemand o statica: qual è la modalità giusta per voi?
Seleziono la modalità in base al profilo di carico: dinamico è il mio predefinito, perché regola in modo flessibile il numero di processi attivi e quindi risparmia RAM quando c'è poco da fare. statico Lo uso quando il carico è costante e ho bisogno di impegni stringenti in termini di latenza e throughput, ad esempio durante le campagne o le vendite. a richiesta è adatto a server con lunghe fasi di inattività: I processi vengono creati solo quando necessario e terminati di nuovo dopo l'inattività. Il compromesso è l'avvio a freddo: la prima richiesta per un nuovo processo è più lenta. Per ondemand ho impostato pm.process_idle_timeout in modo pulito (ad esempio 10-20s), con la dinamica tengo avviare_server, min_spare_servers e max_spare_servers stretta, in modo che il pool si espanda rapidamente ma non si „gonfi“.
Esempio di configurazione per il vostro pool
Su Debian/Ubuntu, il file del pool si trova solitamente sotto /etc/php/8.x/fpm/pool.d/www.conf, il che mi dà un chiaro Struttura per le personalizzazioni. Imposto pm su dinamico, ancoro un valore realistico per pm.max_children e tengo stretto il server di riserva. Imposto il riciclo a 500 per limitare le perdite e gli aumenti di RAM all'inizio. Dopo ogni modifica, verifico il carico e rimuovo i colli di bottiglia prima di aumentare ulteriormente i valori. Per informazioni di base sui valori limite, l'approfondimento in Ottimizzare pm.max_children.
pm = dinamico
pm.max_children = 15
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 8
pm.max_requests = 500
request_terminate_timeout = 90s
Piscine multiple, prese e isolamento pulito
Per i progetti multipli o per i ruoli chiaramente separati (frontend vs. admin/REST), ho impostato piscine separate con il proprio utente e il proprio socket. In questo modo, ogni pool limita i propri figli e un'eccezione non blocca gli altri. Su un host preferisco socket Unix rispetto a TCP (listen = /run/php/site.sock) - latenza inferiore, meno overhead. Uso TCP tra Nginx/Apache e PHP-FPM su host/container diversi. Utilizzo listen.owner, listen.group e listen.mode coerente e, se necessario, aumentare listen.backlog in modo che brevi picchi di carico non provochino errori di connessione. Con un pool di amministratori dedicato, è possibile ottenere un timeout_richiesta_termine guida e pm.max_requests senza rallentare il pool di frontend con cache.
Riconoscere i sintomi e reagire correttamente
Se il log degli errori riporta regolarmente „il server ha raggiunto pm.max_children“, il pool sta limitando il numero di Parallelismo e lo aumento moderatamente. Se si verificano 502/504 e contemporaneamente un elevato utilizzo dello swap, azzero pm.max_children e abbasso pm.max_requests. Se la CPU aumenta con un basso utilizzo della RAM, di solito le query o la logica PHP si bloccano; ottimizzo il database e la cache. Se le richieste si bloccano, un request_terminate_timeout più severo e l'analisi dei log con i timestamp aiutano. Verifico i picchi più evidenti rispetto ai cronjob, agli indici di ricerca e alle azioni dell'amministratore.
Stato FPM e slowlog: diagnosi precisa
Attivo il Stato per pool (pm.status_path) e leggere i dati principali come processi attivi, bambini massimi raggiunti, coda di ascolto e coda di ascolto massima off. Una coda di liste in continua crescita mostra chiaramente: troppo pochi bambini o backend bloccati. Ho anche impostato timeout_richiesta_slowlog (ad es. 3-5s) e un slowlog-percorso. In questo modo vedo le tracce dello stack delle richieste che si attardano, spesso chiamate HTTP esterne, query complesse di WooCommerce o manipolazioni di immagini. Con catch_workers_output Gli avvisi dei lavoratori vengono raccolti nei log. Sulla base di questi dati, decido se un maggiore parallelismo è utile o se è necessario risolvere i colli di bottiglia nel codice/DB.
Monitoraggio: 3-5 giorni di valutazione pulita
Dopo la messa a punto, osservo dei picchi di carico nell'arco di diversi giorni, perché il breve termine fluttuazioni ingannare. Registro RAM, swap, 502/504, TTFB e il numero di processi attivi nello stato FPM. Al di sotto dell'80% di utilizzo della RAM senza swap e senza code, sono corretto. Se si verificano colli di bottiglia durante azioni come il checkout, la ricerca o l'importazione, regolo specificamente pm.max_children e pm.max_requests. Ogni fase viene eseguita con piccoli aggiustamenti e con una nuova misurazione.
Calcolo della memoria in dettaglio: RSS, PSS e memoria condivisa
La variabile di processo è complicata: RSS (Resident Set Size) contiene anche segmenti condivisi come OPcache e librerie. Pertanto, il consumo di RAM viene rapidamente sovrastimato se si calcola semplicemente „RSS × Bambini“. Meglio è il PSS-(Proportional Set Size), che distribuisce la memoria condivisa in modo equo tra i processi - strumenti come smem aiutano in questo senso. Il calcolo include OPcache (ad esempio, 256 MB + stringhe), APCu (ad esempio 64-128 MB) e il processo master. Il processo PHP limite_di_memoria non è una media, ma il limite massimo per richiesta; possono verificarsi singoli picchi, ma conta il valore medio. Pianifico un buffer in modo che i picchi, le distribuzioni e i cronjob non inneschino immediatamente gli swap e lascio pm.max_requests per limitare l'ingombro di memoria.
Ridurre il carico specifico di WordPress
Riduco il carico di PHP prima di aumentare ulteriormente i bambini, perché un tasso di risposta alla cache più veloce fa risparmiare tempo reale. RAM. Le cache a pagina intera riducono drasticamente le richieste PHP, creando capacità per il checkout, la ricerca e l'amministrazione. OPcache con un consumo di memoria di 256 MB accelera il bytecode e alleggerisce il pool. In pratica, mantengo il limite di memoria PHP a 256M, in modo che i singoli plugin non rallentino il server. Per ulteriori informazioni sui colli di bottiglia, consultare la guida PHP Worker come collo di bottiglia.
Database e backend della cache in equilibrio
Ogni lavoratore PHP genera potenzialmente un file Connessione al database. Se aumento pm.max_children, aumenta anche il carico simultaneo del DB. Pertanto, controllo MySQL/MariaDB: max_connessioni, buffer (innodb_buffer_pool_size) e il pianificatore di query. Redis/Memcached devono tenere il passo in parallelo - maxclients, limite di memoria e latenze. Un'istanza di WordPress con 20 bambini attivi può facilmente saturare il DB se diverse query costose vengono eseguite in parallelo. Per questo motivo, metto a punto il DB (indici, query lente) e imposto a Cache di oggetti persistenti, prima di rilasciare altri bambini. Questo aumenta il throughput senza sovraccaricare il backend.
WooCommerce, Cron e Admin: casi particolari
I negozi generano un maggior numero di richieste dinamiche simultanee, ed è per questo che utilizzo qualcosa di aria con pm.max_children. Allo stesso tempo, tendo ad abbassare pm.max_requests per ridurre continuamente il gonfiore della memoria. Per le importazioni e i cronjob, pianifico un budget aggiuntivo o eseguo i compiti al di fuori delle ore di punta. L'area di amministrazione ha spesso picchi di traffico con breve preavviso; la cache offre meno protezione in questo caso, quindi è importante un controllo efficiente del pool. Se ci sono segni di code, aumento a piccoli passi e monitoro le metriche subito dopo.
Contenitori, quote vCPU e trappole OOM
Nei contenitori e nelle macchine virtuali, l'attenzione si concentra sul efficace limite di RAM (cgroups), non sull'host. Pertanto calcolo pm.max_children dal limite allocato e non da „free -h“. Gli OOM dei contenitori sono spietati: il kernel termina duramente i processi. Anche le quote di CPU contano: Un maggior numero di figli non è utile se 1-2 vCPU limitano il tempo di calcolo. Come regola empirica, scalerei i carichi di lavoro WordPress pesanti dal punto di vista dell'IO a circa 2-4 volte il numero di vCPU; al di sopra di questo valore, aumentano i context switch, ma non il throughput reale. Negli ambienti orchestrati, eseguo il roll-out delle modifiche in modo conservativo, osservo i riavvii dei pod e mantengo le sonde di readiness/liveness in modo che le brevi fasi di riscaldamento di FPM non vengano considerate come guasti.
Fonti di errore spesso trascurate
Molti problemi non derivano dalla piscina, ma da Plugins, che moltiplicano le richieste o generano processi lunghi. Le ricerche indicizzate, le regole del crawler non rispettate e gli intervalli di heartbeat eccessivi aumentano il carico. Per questo motivo controllo sempre prima i log, il monitor delle query e le intestazioni della cache. Se il carico si verifica solo con determinati URL, lo interpreto come un'indicazione di colli di bottiglia dei plugin o dei template. Solo quando questi problemi sono stati risolti, scalerò ulteriormente i bambini.
Comprendere le sessioni, l'amministrazione AJAX e i blocchi
WordPress/plugins funzionano in parte con Sessioni. I blocchi di sessione basati su file possono serializzare le richieste: una singola richiesta lenta blocca il resto dello stesso ID di sessione. Mantengo l'uso delle sessioni in modo snello e controllo se i burst AJAX dell'amministratore (wp-admin/admin-ajax.php) si attivano inutilmente di frequente. L'heartbeat dovrebbe essere limitato in modo ragionevole, altrimenti genera carico senza valore aggiunto. Se si verificano blocchi o lunghi accessi ai file, un maggiore parallelismo non sarà d'aiuto; la cache, un I/O più veloce o un diverso gestore di sessione saranno d'aiuto in questo caso. Nei log, riconosco questi schemi da molte richieste simili che iniziano nello stesso momento con tempi di esecuzione insolitamente lunghi.
I timeout di Nginx, Apache e FastCGI in sintesi
Il server web imposta anche dei limiti che devo armonizzare con i valori di FPM, altrimenti si spengono. Sintonizzazione. Con Nginx, faccio attenzione a fastcgi_read_timeout e a un numero sufficiente di processi worker. Con Apache, controllo mpm_event, le impostazioni keepalive e i timeout del proxy. Se questi limiti non sono corretti, gli utenti segnalano timeout anche se FPM ha ancora capacità. I budget di tempo standardizzati mantengono coerente il percorso dal client a PHP.
Strategia di rollout, test e operazioni
Eseguo le modifiche a pm.max_children passo dopo passo e le verifico sotto carico reale. Un ricaricamento di FPM (graceful) riprende le configurazioni senza interrompere la connessione. Prima di salti più consistenti, simulo dei picchi (ad esempio, l'avvio della vendita) e osservo coda di ascolto, CPU, RAM, 95°-99° percentile dei tassi di latenza e di errore. Documento le ipotesi fatte in modo che i membri successivi del team capiscano perché un valore è stato scelto in questo modo. Ho impostato allarmi per: swap > 0, „bambini massimi raggiunti“ nello stato, aumento di 502/504 e latenza del DB. Questo assicura che la piattaforma rimanga stabile anche a distanza di mesi, quando il traffico e il mix di plugin cambiano.
Riassumendo brevemente
Impostazione errata PHP-FPM-I figli rallentano WordPress, sia nelle code che nel limite della RAM. Determino la dimensione del processo, riservo la memoria per i servizi di sistema e imposto pm.max_children con buffer. Controllo poi pm.max_requests, request_terminate_timeout e la modalità pm = dynamic o static in base al profilo di carico. La cache, OPcache e i plugin puliti riducono sensibilmente il numero di richieste PHP. Se si attuano questi passaggi in modo coerente, si manterranno le pagine reattive e il server affidabile.
