{"id":16053,"date":"2025-12-20T11:51:36","date_gmt":"2025-12-20T10:51:36","guid":{"rendered":"https:\/\/webhosting.de\/php-fpm-prozess-management-pm-max-children-optimieren-core\/"},"modified":"2025-12-20T11:51:36","modified_gmt":"2025-12-20T10:51:36","slug":"php-fpm-gestione-dei-processi-pm-max-children-ottimizzare-core","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/php-fpm-prozess-management-pm-max-children-optimieren-core\/","title":{"rendered":"Configurare correttamente la gestione dei processi PHP-FPM: spiegazione di pm.max_children &amp; Co."},"content":{"rendered":"<p><strong>Ottimizzazione php-fpm<\/strong> decide quanti processi PHP-FPM possono essere eseguiti contemporaneamente, la velocit\u00e0 con cui vengono avviati i nuovi processi e per quanto tempo questi ultimi gestiscono le richieste. Ti mostrer\u00f2 come <strong>pm.max_children<\/strong>, pm, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers e pm.max_requests in modo tale che la tua applicazione risponda rapidamente sotto carico e il server non entri in swapping.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>modalit\u00e0 pm<\/strong>: scegli correttamente tra static, dynamic o ondemand, in modo che i processi siano adeguati al tuo traffico.<\/li>\n  <li><strong>pm.max_children<\/strong>: Allineare il numero di processi PHP simultanei alla RAM e al consumo effettivo di risorse.<\/li>\n  <li><strong>Valori di avvio\/riserva<\/strong>: bilanciare in modo ragionevole pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.<\/li>\n  <li><strong>riciclaggio<\/strong>: Con pm.max_requests \u00e8 possibile attenuare le perdite di memoria senza generare un sovraccarico inutile.<\/li>\n  <li><strong>Monitoraggio<\/strong>: Tenere sotto controllo log, stato e RAM, quindi regolare gradualmente.<\/li>\n<\/ul>\n\n<h2>Perch\u00e9 la gestione dei processi \u00e8 importante<\/h2>\n\n<p>Contribuisco con <strong>PHP-FPM<\/strong> l'esecuzione di ogni script PHP come processo separato e ogni richiesta parallela richiede un proprio worker. Senza limiti adeguati, le richieste in coda si bloccano, causando <strong>Timeout<\/strong> e errori. Se imposto limiti troppo alti, il pool di processi consuma la memoria di lavoro e il kernel inizia a <strong>scambiare<\/strong>. Questo equilibrio non \u00e8 un gioco d'ipotesi: mi baso su valori di misurazione reali e mantengo un margine di sicurezza. In questo modo la latenza rimane bassa e il throughput stabile, anche quando il carico aumenta.<\/p>\n\n<p>Per me \u00e8 importante una chiara <strong>valore obiettivo<\/strong>: Quante esecuzioni PHP simultanee voglio consentire senza esaurire la RAM? Allo stesso tempo, verifico se i colli di bottiglia si verificano pi\u00f9 spesso nella <strong>Banca dati<\/strong>, nelle API esterne o nel server web. Solo se conosco il collo di bottiglia, posso scegliere i valori corretti per pm, pm.max_children e simili. Inizio in modo conservativo, misuro e poi aumento gradualmente. In questo modo evito riavvii difficili e guasti imprevisti.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/php-fpm-serveradmin-4912.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Le tre modalit\u00e0 pm: static, dynamic, ondemand<\/h2>\n\n<p>La modalit\u00e0 <strong>statico<\/strong> mantiene sempre esattamente pm.max_children processi disponibili. Ci\u00f2 garantisce latenze molto prevedibili, poich\u00e9 non \u00e8 necessario alcun processo di avvio. Utilizzo static quando il carico \u00e8 molto uniforme e la RAM disponibile \u00e8 sufficiente. Tuttavia, in caso di domanda variabile, con static spreco facilmente <strong>Memoria<\/strong>. Per questo motivo utilizzo static in modo mirato laddove necessito di un'esecuzione costante.<\/p>\n\n<p>Con <strong>dinamico<\/strong> Avvio una quantit\u00e0 iniziale e lascio che la dimensione del pool oscilli tra min_spare e max_spare. Questa modalit\u00e0 \u00e8 adatta al traffico con picchi, perch\u00e9 i worker vengono creati e chiusi in base alle necessit\u00e0. Mantengo sempre un numero sufficiente di processi inattivi per far fronte ai picchi senza tempi di attesa. Tuttavia, un numero eccessivo di worker inattivi occupa inutilmente risorse. <strong>RAM<\/strong>, motivo per cui mantengo il margine di risparmio ridotto. In questo modo la piscina rimane mobile senza gonfiarsi.<\/p>\n\n<p>In modalit\u00e0 <strong>a richiesta<\/strong> Inizialmente non esistono worker, PHP-FPM li avvia solo in caso di richieste. Ci\u00f2 consente di risparmiare memoria nelle fasi di inattivit\u00e0, ma il primo accesso comporta una certa latenza. Scelgo ondemand per pool utilizzati raramente, strumenti di amministrazione o endpoint cron. Per i siti web molto frequentati, ondemand offre solitamente tempi di risposta peggiori. In questi casi preferisco chiaramente dynamic con valori di riserva impostati in modo corretto.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/phpfpm_konfiguration_9542.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dimensionare correttamente pm.max_children<\/h2>\n\n<p>Credo che <strong>pm.max_children<\/strong> dalla RAM disponibile per PHP e dalla memoria media per worker. A tal fine, riservo innanzitutto memoria per il sistema, il server web, il database e le cache, in modo che il sistema non entri in <strong>Outsourcing<\/strong> funziona. Divido la RAM rimanente per il consumo effettivo misurato del processo. Dalla teoria sottraggo un margine di sicurezza di 20-30 % per compensare i valori anomali e i picchi di carico. Utilizzo il risultato come valore iniziale e poi osservo l'effetto.<\/p>\n\n<p>Calcolo il consumo medio di processo con strumenti quali <strong>ps<\/strong>, top o htop e controllo RSS\/RES. Importante: misuro sotto carico tipico, non al minimo. Se carico molti plugin, framework o librerie di grandi dimensioni, il consumo per worker aumenta notevolmente. Inoltre, la CPU limita la curva: pi\u00f9 processi non aiutano se una <strong>A filo singolo<\/strong>-Prestazioni della CPU limitate per ogni richiesta. Chi desidera approfondire le caratteristiche della CPU trover\u00e0 informazioni di base su <a href=\"https:\/\/webhosting.de\/it\/php-single-thread-performance-wordpress-hosting-velocity\/\">Prestazioni single-thread<\/a>.<\/p>\n\n<p>Mantengo trasparenti le mie ipotesi: quanta RAM \u00e8 realmente disponibile per PHP? Quanto \u00e8 grande un worker nelle richieste tipiche? Quali picchi si verificano? Se le risposte sono corrette, imposto pm.max_children, eseguo un reload graduale e controllo la RAM, i tempi di risposta e i tassi di errore. Solo dopo procedo con piccoli passi verso l'alto o verso il basso.<\/p>\n\n<h2>Valori indicativi in base alle dimensioni del server<\/h2>\n\n<p>La tabella seguente mi fornisce <strong>valori iniziali<\/strong> alla mano. Non sostituisce la misurazione, ma fornisce un orientamento solido per le prime impostazioni. Adatto i valori a ciascuna applicazione e li controllo con il monitoraggio. Se le riserve rimangono inutilizzate, aumento cautamente. Se il server raggiunge il limite della RAM, riduco i valori.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>RAM del server<\/strong><\/th>\n      <th><strong>RAM per PHP<\/strong><\/th>\n      <th><strong>\u00d8 MB\/lavoratore<\/strong><\/th>\n      <th><strong>pm.max_children<\/strong> (Inizio)<\/th>\n      <th><strong>Utilizzo<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>1-2 GB<\/td>\n      <td>~1 GB<\/td>\n      <td>50\u201360<\/td>\n      <td>15\u201320<\/td>\n      <td>Piccoli siti, blog<\/td>\n    <\/tr>\n    <tr>\n      <td>4\u20138 GB<\/td>\n      <td>~4\u20136 GB<\/td>\n      <td>60\u201380<\/td>\n      <td>30\u201380<\/td>\n      <td>Affari, piccoli negozi<\/td>\n    <\/tr>\n    <tr>\n      <td>16+ GB<\/td>\n      <td>~10\u201312 GB<\/td>\n      <td>70\u201390<\/td>\n      <td>100\u2013160<\/td>\n      <td>Carichi elevati, API, negozi<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Leggo la tabella da destra a sinistra: Il <strong>Utilizzo<\/strong> Per quanto riguarda il progetto, verifico che la RAM sia riservata in modo realistico per PHP. Quindi seleziono una dimensione del worker adeguata al codice base e alle estensioni. Successivamente imposto pm.max_children e osservo l'effetto durante il funzionamento live. Il tasso di successo e la stabilit\u00e0 aumentano se documento accuratamente questi passaggi.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/php-fpm-prozessmanagement-5124.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Impostare i valori di avvio, di riserva e di richiesta<\/h2>\n\n<p>Con <strong>pm.avvia_server<\/strong> Stabilisco quanti processi devono essere immediatamente disponibili. Un valore troppo basso genera avvii a freddo sotto carico, mentre uno troppo alto occupa inutilmente RAM. Mi baso spesso su 15-30 % di pm.max_children e arrotondo se il carico inizia in modo piuttosto tranquillo. In caso di picchi di traffico, scelgo una quantit\u00e0 iniziale leggermente superiore, in modo che le richieste non arrivino prima che ci siano abbastanza worker in attesa. Questa regolazione fine riduce significativamente il tempo di risposta iniziale.<\/p>\n\n<p>I valori <strong>pm.min_spare_servers<\/strong> e pm.max_spare_servers definiscono l'intervallo di inattivit\u00e0. Mantengo un numero di worker liberi tale da consentire l'accesso immediato alle nuove richieste, ma non cos\u00ec tanti da sprecare memoria con i processi inattivi. Per i negozi online preferisco impostare una finestra pi\u00f9 ristretta per appianare i picchi. Con <strong>pm.max_requests<\/strong> Riciclo i processi dopo alcune centinaia di richieste per limitare la deriva della memoria. Per applicazioni poco appariscenti scelgo 500-800, mentre in caso di sospette perdite scelgo volutamente valori inferiori.<\/p>\n\n<h2>Monitoraggio e risoluzione dei problemi<\/h2>\n\n<p>Controllo regolarmente <strong>Registri<\/strong>, pagine di stato e RAM. Gli avvisi relativi al raggiungimento dei limiti pm.max_children sono per me un chiaro segnale che \u00e8 necessario aumentare il limite massimo o ottimizzare il codice\/DB. Se si verificano errori 502\/504 frequenti, controllo i log del server web e le code. Fluttuazioni significative della latenza indicano un numero insufficiente di processi, I\/O bloccanti o costi di processo troppo elevati. Prima guardo i fatti concreti e poi reagisco con piccoli passi, mai con salti XXL.<\/p>\n\n<p>Riconosco pi\u00f9 rapidamente i colli di bottiglia se utilizzo il <strong>Tempi di attesa<\/strong> Misuro lungo l'intera catena: server web, PHP-FPM, database, servizi esterni. Se il tempo di backend aumenta solo per determinati percorsi, isolo le cause tramite profiling. Se i tempi di attesa si verificano ovunque, intervengo sulla dimensione del server e del pool. \u00c8 utile anche dare un'occhiata alle code dei worker e ai processi in stato D. Solo quando ho compreso la situazione modifico i limiti e documento accuratamente ogni modifica.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/phpfpm_nachtarbeit_tech5982.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interazione tra server web e PHP-FPM<\/h2>\n\n<p>Mi assicuro che <strong>Server web<\/strong>-Limiti e PHP-FPM sono in armonia. Troppe connessioni simultanee nel server web con troppo pochi worker causano code e timeout. Se i worker sono impostati al massimo, ma il server web limita l'accettazione, le prestazioni rimangono basse. Parametri come worker_connections, event-Loop e Keep-Alive hanno un effetto diretto sul carico PHP. Un'introduzione pratica alla messa a punto \u00e8 fornita dai suggerimenti su <a href=\"https:\/\/webhosting.de\/it\/threadpool-webserver-apache-nginx-litespeed-ottimizzazione-configurazione\/\">Thread pool nel server web<\/a>.<\/p>\n\n<p>Conservo <strong>Mantenere in vita<\/strong>-Finestra temporale in vista, in modo che le connessioni inattive non blocchino inutilmente i worker. Per le risorse statiche, imposto un caching aggressivo prima del PHP, per tenere il carico di lavoro lontano dal pool. Le cache reverse proxy aiutano ulteriormente quando vengono richiamate spesso risposte identiche. In questo modo posso mantenere pm.max_children pi\u00f9 basso e comunque fornire risultati pi\u00f9 rapidi. Meno lavoro per ogni richiesta \u00e8 spesso la leva pi\u00f9 efficace.<\/p>\n\n<h2>Viti di regolazione di precisione in php-fpm.conf<\/h2>\n\n<p>Vado oltre i valori fondamentali e adeguo il <strong>Parametri della piscina<\/strong> bene. Con <strong>pm.max_spawn_rate<\/strong> limito la velocit\u00e0 con cui possono essere creati nuovi worker, in modo che il server non avvii processi in modo troppo aggressivo durante i picchi di carico e non finisca in CPU thrashing. Per ondemand imposto con <strong>pm.process_idle_timeout<\/strong> fisso, quanto velocemente scompaiono i worker inutilizzati: troppo breve genera overhead di avvio, troppo lungo occupa RAM. Nel caso di <strong>ascoltare<\/strong>-Socket, posso scegliere tra Unix-Socket e TCP. Un Unix-Socket riduce il sovraccarico e offre un'assegnazione chiara dei diritti tramite <em>listen.owner<\/em>, <em>listen.group<\/em> e <em>listen.mode<\/em>. Per entrambe le varianti imposto <strong>listen.backlog<\/strong> sufficientemente alto affinch\u00e9 i burst in arrivo finiscano nel buffer del kernel invece di essere immediatamente respinti. Con <strong>rlimit_files<\/strong> Se necessario, aumento il numero di file aperti per ogni worker, il che garantisce stabilit\u00e0 in caso di numerosi upload e download simultanei. E se servono delle priorit\u00e0, utilizzo <strong>process.priority<\/strong>, per trattare in modo leggermente subordinato i pool poco critici dal punto di vista della CPU.<\/p>\n\n<h2>Slowlog e protezione dai blocchi<\/h2>\n\n<p>Per rendere visibili le richieste complesse, attivo il <strong>Slowlog<\/strong>. Con <strong>timeout_richiesta_slowlog<\/strong> definisco la soglia (ad es. 2-3 s) a partire dalla quale uno stack trace viene inserito nel <strong>slowlog<\/strong> . In questo modo trovo I\/O bloccanti, loop costosi o blocchi imprevisti. Contro i veri blocchi utilizzo <strong>timeout_richiesta_termine<\/strong>, che si interrompe bruscamente quando una richiesta dura troppo a lungo. Ritengo che questi intervalli di tempo siano coerenti con <em>tempo_di_esecuzione_max<\/em> da PHP e dai timeout del server web, in modo che un livello non si interrompa prima dell'altro. In pratica, inizio in modo conservativo, analizzo gli slowlog sotto carico e adeguo gradualmente le soglie fino a quando i segnali sono significativi, senza sovraccaricare il log.<\/p>\n\n<h2>Opcache, memory_limit e la loro influenza sulle dimensioni dei worker<\/h2>\n\n<p>Mi riferisco al <strong>Opcache<\/strong> nella mia pianificazione della RAM. La sua area di memoria condivisa non viene conteggiata per ogni worker, ma viene utilizzata in comune da tutti i processi. Dimensione e frammentazione (<em>opcache.memory_consumption<\/em>, <em>interned_strings_buffer<\/em>) influenzano notevolmente il tempo di riscaldamento e la percentuale di successo. Un Opcache ben dimensionato riduce la pressione sulla CPU e sulla RAM per ogni richiesta, poich\u00e9 viene ricompilato meno codice. Allo stesso tempo, noto che <strong>limite_di_memoria<\/strong>: un valore elevato protegge dall'esaurimento della memoria in singoli casi, ma aumenta il budget teorico peggiore per ogni worker. Per questo motivo pianifico con una media misurata pi\u00f9 un buffer, non con il semplice memory_limit. Funzionalit\u00e0 come il precaricamento o JIT aumentano il fabbisogno di memoria: le testiamo in modo mirato e calcoliamo il consumo aggiuntivo nel calcolo pm.max_children.<\/p>\n\n<h2>Separare e dare priorit\u00e0 ai pool<\/h2>\n\n<p>Divido le applicazioni in <strong>pi\u00f9 piscine<\/strong> quando i profili di carico differiscono notevolmente. Un pool per il traffico frontend, uno per l'amministrazione\/backend, un terzo per cron\/upload: in questo modo isolo i picchi e assegno limiti differenziati. Per gli endpoint poco frequentati imposto <em>a richiesta<\/em> con un breve timeout di inattivit\u00e0, per il frontend <em>dinamico<\/em> con un margine di risparmio ridotto. Informazioni su <strong>utente\/gruppo<\/strong> e, se necessario,. <em>chroot<\/em> mi occupo di garantire un isolamento pulito, mentre i diritti socket regolano quale processo del server web pu\u00f2 accedere. Quando sono richieste delle priorit\u00e0, il frontend riceve pi\u00f9 <em>pm.max_children<\/em> e, se necessario, una neutrale <em>process.priority<\/em>, mentre Cron\/Reports funzionano con un budget inferiore e una priorit\u00e0 minore. In questo modo l'interfaccia utente rimane reattiva anche quando in background sono in esecuzione lavori pesanti.<\/p>\n\n<h2>Utilizzare correttamente gli endpoint di stato<\/h2>\n\n<p>Per la diagnosi della durata attivo <strong>pm.status_path<\/strong> e opzionale <strong>ping.path<\/strong> per pool. Nello stato vedo Active\/Idle-Worker che <em>Coda delle liste<\/em>, contatori basati sulla velocit\u00e0 effettiva e metriche delle richieste lente. Una coda di lista in costante crescita o lavoratori inattivi costantemente pari a 0 sono per me segnali di allarme. Proteggo questi endpoint dietro Auth e una rete interna, in modo che nessun dettaglio operativo venga divulgato all'esterno. Inoltre, attivo <strong>catch_workers_output<\/strong>, quando voglio raccogliere rapidamente stdout\/stderr dai worker, ad esempio in caso di errori difficili da riprodurre. Combino questi segnali con le metriche di sistema (RAM, CPU, I\/O) per decidere se aumentare pm.max_children, aggiornare i valori di riserva o intervenire sull'applicazione.<\/p>\n\n<h2>Caratteristiche speciali nei container e nelle VM<\/h2>\n\n<p>All'indirizzo <strong>contenitori<\/strong> e piccole VM, faccio attenzione ai limiti cgroup e al rischio dell'OOM killer. Impostato pm.max_children rigorosamente in base al <em>Limite di memoria del contenitore<\/em> e testare i picchi di carico, in modo che nessun worker venga chiuso. Senza swap nei container, il margine di sicurezza \u00e8 particolarmente importante. Per le quote CPU, scalizzo il numero di worker in base al numero di vCPU disponibili: se l'applicazione \u00e8 CPU-bound, una maggiore parallelit\u00e0 porta pi\u00f9 code che throughput. I carichi di lavoro IO-bound tollerano pi\u00f9 processi, purch\u00e9 il budget RAM lo consenta. Inoltre, imposto <strong>soglia_riavvio_emergenza<\/strong> e <strong>intervallo_riavvio_emergenza<\/strong> per il processo master, al fine di evitare una spirale di crash nel caso in cui un bug raro causi il blocco di pi\u00f9 processi figli in breve tempo. In questo modo il servizio rimane disponibile mentre analizzo la causa.<\/p>\n\n<h2>Implementazioni e ricaricamenti senza intoppi e senza interruzioni<\/h2>\n\n<p>Sto progettando <strong>Ricariche<\/strong> in modo tale che le richieste in corso vengano portate a termine correttamente. Un <em>ricaricamento graduale<\/em> (ad es. tramite systemd reload) applica le nuove configurazioni senza interrompere bruscamente le connessioni aperte. Mantengo stabile il percorso del socket in modo che il server web non rilevi alcuna interruzione della connessione. In caso di cambi di versione che invalidano gran parte dell'Opcache, preriscaldo la cache (preloading\/warmup-requests) per limitare i picchi di latenza subito dopo il deployment. Prima di implementare i valori su larga scala, testo le modifiche pi\u00f9 significative su un pool pi\u00f9 piccolo o in un'istanza Canary con configurazione identica. Ogni modifica viene registrata nel mio log delle modifiche con timestamp e screenshot delle metriche, il che riduce il tempo necessario per individuare eventuali errori in caso di effetti collaterali imprevisti.<\/p>\n\n<h2>Comportamento burst e code di attesa<\/h2>\n\n<p>Affronto i picchi di carico con un sistema coordinato <strong>Progettazione delle code<\/strong> . Io metto <strong>listen.backlog<\/strong> cos\u00ec alto che il kernel pu\u00f2 temporaneamente bufferizzare pi\u00f9 tentativi di connessione. Sul lato server web, limito il numero massimo di connessioni FastCGI simultanee per pool in modo che siano <em>pm.max_children<\/em> adatto. In questo modo, i burst si accumulano preferibilmente nel server web (economico) piuttosto che in profondit\u00e0 nel PHP (costoso). Misuro il <em>Coda delle liste<\/em> nello stato FPM: se aumenta regolarmente, aumento il numero di worker, ottimizzo i tassi di cache hit o riduco i valori keep-alive aggressivi. L'obiettivo \u00e8 quello di mantenere il <em>Tempo al primo byte<\/em> mantenere stabile, invece di lasciare che le richieste finiscano in code infinite.<\/p>\n\n<h2>Flusso di lavoro pratico per le regolazioni<\/h2>\n\n<p>Inizio con un <strong>Audit<\/strong>: budget RAM, dimensione del processo, profili I\/O. Successivamente, imposto valori iniziali conservativi per pm.max_children e la modalit\u00e0 pm. Quindi eseguo test di carico o osservo i picchi di traffico reali. Registro tutte le modifiche, comprese le metriche e le finestre temporali. Dopo ogni regolazione, controllo la RAM, la latenza P50\/P95 e i tassi di errore: solo allora passo alla fase successiva.<\/p>\n\n<p>Quando mi trovo ripetutamente al limite, non reagisco immediatamente in modo esagerato. <strong>Lavoratore<\/strong>-Numero. Per prima cosa ottimizzo le query, i tassi di cache e le funzioni costose. Sposta i lavori IO-heavy nelle code e accorcia i percorsi di risposta. Solo quando l'applicazione funziona in modo efficiente, aumento la dimensione del pool. Questo processo consente di risparmiare risorse ed evitare danni consequenziali in altri punti.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/phpfpm_schreibtisch_7321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Scenari tipici: valori esemplificativi<\/h2>\n\n<p>Su un vServer da 2 GB riserviamo circa <strong>1 GB<\/strong> per PHP-FPM e imposto un consumo worker di circa 50-60 MB. In questo modo inizio con pm.max_children a 15-20 e utilizzo dynamic con una quantit\u00e0 iniziale ridotta. Mantengo min_spare a 2-3 e max_spare a 5-6. Impostato pm.max_requests a 500, in modo che i processi vengano scambiati regolarmente. Queste impostazioni garantiscono tempi di risposta stabili per i progetti di piccole dimensioni.<\/p>\n\n<p>Con 8 GB di RAM, di solito pianifico 4-6 GB per <strong>PHP<\/strong> e imposto dimensioni dei worker comprese tra 60 e 80 MB. Ne risultano 30-80 processi figli come area di avvio. pm.start_servers \u00e8 compreso tra 15 e 20, min_spare tra 10 e 15, max_spare tra 25 e 30. Per pm.max_requests scelgo un valore compreso tra 500 e 800. Sotto carico, verifico se il picco di RAM lascia margine e poi aumento con cautela.<\/p>\n\n<p>In configurazioni ad alto carico con 16+ GB di RAM, riservo 10-12 GB per <strong>FPM<\/strong>. Con 70-90 MB per worker, arrivo rapidamente a 100-160 processi. Che sia pi\u00f9 opportuno utilizzare static o dynamic dipende dal tipo di carico. Per un carico elevato costante \u00e8 preferibile static, mentre per una domanda altalenante \u00e8 meglio dynamic. In entrambi i casi \u00e8 necessario un monitoraggio costante.<\/p>\n\n<h2>Evitare gli ostacoli e stabilire le priorit\u00e0<\/h2>\n\n<p>Non confondo il numero dei <strong>Visitatori<\/strong> con il numero di script PHP simultanei. Molte visualizzazioni di pagine colpiscono le cache, forniscono file statici o bloccano al di fuori di PHP. Per questo motivo dimensiono pm.max_children in base al tempo PHP misurato, non alle sessioni. Se i processi sono impostati in modo troppo parsimonioso, vedo richieste in attesa e tassi di errore in aumento. Se i valori sono troppo alti, la memoria si riversa nello swap e tutto rallenta.<\/p>\n\n<p>Un errore comune: pi\u00f9 processi equivalgono a pi\u00f9 <strong>Velocit\u00e0<\/strong>. In realt\u00e0, ci\u00f2 che conta \u00e8 l'equilibrio tra CPU, IO e RAM. Se la CPU raggiunge il 100% % e la latenza aumenta rapidamente, l'aggiunta di ulteriori worker non \u00e8 di grande aiuto. \u00c8 meglio eliminare il vero collo di bottiglia o ridurre il carico tramite la cache. Il motivo per cui i worker sono spesso il collo di bottiglia \u00e8 spiegato nella guida su <a href=\"https:\/\/webhosting.de\/it\/php-workers-hosting-collo-di-bottiglia-guida-allequilibrio\/\">PHP Worker come collo di bottiglia<\/a>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/phpfpm-serverkonfig-7342.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Riassumendo brevemente<\/h2>\n\n<p>Prima calcolo il valore reale <strong>RAM<\/strong>-Consumo per worker e imposto pm.max_children con buffer. Quindi seleziono la modalit\u00e0 pm adatta al tipo di carico e bilanccio i valori di avvio e di riserva. Con pm.max_requests mantengo i processi aggiornati, senza overhead inutili. Invio log, stati e metriche a un sistema di monitoraggio pulito, in modo che ogni modifica rimanga misurabile. In questo modo ottengo tempi di risposta brevi, pool stabili e un carico del server che ha riserve per i picchi.<\/p>","protected":false},"excerpt":{"rendered":"<p>Guida completa alla messa a punto di php-fpm: scopri come impostare in modo ottimale pm.max_children e altri parametri di processo per massimizzare le prestazioni del tuo hosting php.<\/p>","protected":false},"author":1,"featured_media":16046,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-16053","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"2654","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":null,"_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"php-fpm tuning","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"16046","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/16053","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=16053"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/16053\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/16046"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=16053"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=16053"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=16053"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}