Vai al contenuto 
Frammentazione della memoria Nel web hosting, PHP-FPM e MySQL rallentano nonostante sembri esserci RAM a sufficienza, perché la memoria si frammenta in tanti piccoli blocchi e le allocazioni più grandi falliscono. Mostrerò in modo pratico come la frammentazione renda più costose le richieste, attivi lo swap e perché una messa a punto mirata di PHP e MySQL migliori visibilmente i tempi di caricamento, l'affidabilità e la scalabilità.
Punti centrali
- PHP-FPM riciclare: riavviare regolarmente i processi tramite pm.max_requests
- Buffer dosare: mantenere conservativo il buffer MySQL per connessione
- Scambio Da evitare: ridurre lo swappiness, prestare attenzione al NUMA
- Tabelle Manutenzione: controllare Data_free, ottimizzare in modo mirato
- Monitoraggio Sfruttare: individuare tempestivamente le tendenze e agire
Cosa significa frammentazione della memoria nell'hosting quotidiano?
Nell'hosting incontra Frammentazione su processi di lunga durata che richiedono e liberano costantemente memoria, creando lacune nello spazio di indirizzamento. Sebbene la quantità totale di RAM libera sembri elevata, mancano blocchi contigui per allocazioni più grandi, il che rallenta i tentativi di allocazione. Lo vedo nei worker PHP-FPM e in mysqld, che dopo ore sembrano sempre più „gonfi“. L'effetto rende ogni richiesta leggermente più costosa e aumenta notevolmente i tempi di risposta sotto carico. Di conseguenza, i picchi come le promozioni di vendita o i backup diventano un freno, anche se la CPU e la rete rimangono invariate.
Perché PHP-FPM genera frammentazione
Ogni worker PHP-FPM carica codice, plugin e dati in un proprio Spazio indirizzi, gestisce le richieste più disparate e lascia spazi vuoti sparsi durante il rilascio. Nel corso del tempo, i processi crescono e liberano memoria internamente, ma non necessariamente al sistema operativo, aumentando così la frammentazione. Script diversi, lavori di importazione ed elaborazione delle immagini amplificano questo mix e portano a modelli di allocazione mutevoli. Lo osservo come un aumento graduale della RAM, anche se il carico e il traffico sembrano costanti. Senza riciclaggio, questa frammentazione interna rallenta l'allocazione e rende difficile la pianificazione in caso di elevato numero di visitatori.
Conseguenze tangibili sui tempi di caricamento e sull'affidabilità
I processi frammentati generano più Spese generali nella gestione della memoria, che si traduce in backend amministrativi più lenti e checkout esitanti. Soprattutto i negozi WordPress o le grandi istanze CMS reagiscono in modo lento quando molte richieste simultanee incontrano worker frammentati. Ciò comporta timeout, errori 502/504 e un aumento dei tentativi di riprova da parte di NGINX o Apache. Leggo tali situazioni in metriche quali picchi di tempo di risposta, aumento della linea di base della RAM e improvviso aumento dell'utilizzo dello swap. Chi ignora questo aspetto compromette le prestazioni, peggiora l'esperienza dell'utente e aumenta il tasso di abbandono nei funnel critici.
Configurare correttamente PHP-FPM: limiti, pool, riciclaggio
Punto su obiettivi realistici Limiti, pool separati e riciclaggio coerente per contenere la frammentazione. Termino pm.max_requests in modo che i worker si riavviino regolarmente senza disturbare i visitatori attivi. Per i profili di traffico con picchi di carico, pm = dynamic è spesso più adatto, mentre pm = ondemand consente di risparmiare RAM nei siti poco trafficati. Mantengo il memory_limit per sito volutamente moderato e lo adatto in base agli script reali; un punto di partenza è fornito dall'argomento Limite di memoria PHP. Inoltre, separo i progetti molto gravosi in pool separati, in modo che un elemento che occupa molto spazio di memoria non comprometta tutti i siti.
OPcache, preloading e PHP-Allocator in primo piano
Per ridurre la frammentazione nel processo PHP, mi affido a un sistema ben dimensionato. OPcache. Un opcache.memory_consumption generoso ma non eccessivo e stringhe interned sufficienti riducono le allocazioni ripetute per ogni richiesta. Osservo il tasso di successo, lo spreco e la capacità residua; se lo spreco aumenta nel tempo, è meglio pianificare un ricaricamento piuttosto che lasciare che i worker crescano in modo incontrollato. Il precaricamento può mantenere il codice caldo stabile nella memoria e quindi uniformare i modelli di allocazione, a condizione che la base di codice sia preparata in modo adeguato. Inoltre, presto attenzione al Selezione dell'allocatore: A seconda della distribuzione, PHP‑FPM e le estensioni funzionano con diverse implementazioni Malloc. Allocatori alternativi come jemalloc riducono notevolmente la frammentazione in alcune configurazioni. Tuttavia, implemento tali modifiche solo dopo averle testate, poiché il debug, il profiling DTrace/eBPF e i dump di memoria reagiscono in modo diverso a seconda dell'allocatore.
Per attività che richiedono molta memoria, come l'elaborazione delle immagini o le esportazioni, preferisco pool separati con limiti più stretti. In questo modo il pool principale non cresce in modo incontrollato e la frammentazione rimane isolata. Inoltre, limito le estensioni che richiedono molta memoria (ad esempio tramite variabili di ambiente) e utilizzo la contropressione: le richieste che richiedono buffer di grandi dimensioni vengono limitate o trasferite in code asincrone, invece di sovraccaricare tutti i worker contemporaneamente.
Comprendere la memoria MySQL: buffer, connessioni, tabelle
In MySQL distinguo tra globale Buffer come il buffer pool InnoDB, il buffer per connessione e le strutture temporanee, che possono crescere ad ogni operazione. Valori troppo elevati comportano un aumento esponenziale del fabbisogno di RAM in caso di carico di connessioni elevato e una maggiore frammentazione a livello di sistema operativo. Inoltre, le tabelle vengono frammentate dagli aggiornamenti/cancellazioni e lasciano parti di Data_free che compromettono l'utilizzo del buffer pool. Pertanto, controllo regolarmente le dimensioni, i rapporti di hit e il numero di tabelle temporanee su disco. La seguente panoramica mi aiuta a identificare con precisione i sintomi tipici e a valutare le misure da adottare.
| Sintomo | Causa probabile | Misura |
|---|---|---|
| La RAM aumenta costantemente, lo swap inizia | Buffer pool troppo grande o troppi buffer per connessione | Limitare la dimensione della pool, ridurre tramite buffer di connessione |
| Molte varietà/unioni lente | Indici mancanti, buffer sort/join eccessivi | Controllare gli indici, mantenere sort/join conservativo |
| Grande Data_free nelle tabelle | Aggiornamenti/cancellazioni significativi, pagine frammentate | OPTIMIZE mirato, archiviazione, semplificazione dello schema |
| Picchi nelle tabelle temporanee del disco | tmp_table_size troppo piccolo o query inadeguate | Aumentare moderatamente i valori, modificare le query |
Ottimizzazione della memoria MySQL: scegliere le dimensioni giuste invece di esagerare
Scelgo il buffer pool InnoDB in modo tale che il Sistema operativo mantiene una capacità sufficiente per la cache del file system e i servizi, in particolare nei server combinati con web e DB. Scalo in modo conservativo i buffer per connessione come sort_buffer_size, join_buffer_size e read-Buffer, in modo che molte connessioni simultanee non causino sovraccarichi della RAM. Impostiamo tmp_table_size e max_heap_table_size in modo che le operazioni non importanti non richiedano tabelle in memoria di grandi dimensioni. Per ulteriori regolazioni, consultiamo Prestazioni MySQL Suggerimenti utili. La cosa fondamentale rimane: preferisco impostare un valore leggermente più basso e misurare, piuttosto che aumentare alla cieca e rischiare frammentazione e swap.
InnoDB in dettaglio: strategie di ricostruzione e istanze pool
Per mantenere MySQL più „compatto“ internamente, ho in programma di effettuare regolarmente Ricostruzioni per tabelle con un'elevata percentuale di scrittura. Un OPTIMIZE TABLE mirato (o una ricostruzione online tramite ALTER) riunisce dati e indici e riduce Data_free. A tal fine, seleziono fasce orarie con carico ridotto, poiché le ricostruzioni sono intensive in termini di I/O. L'opzione innodb_file_per_table Lo mantengo attivo perché consente ricostruzioni controllate per tabella e riduce il rischio che singoli „elementi problematici“ frammentino l'intero file dello spazio tabella.
Ne uso diversi Istanze buffer pool (innodb_buffer_pool_instances) in relazione alle dimensioni del pool e ai core della CPU, per alleggerire i latch interni e distribuire gli accessi. Ciò non solo migliora la parallelità, ma appiana anche i modelli di allocazione nel pool. Inoltre, controllo la dimensione dei log di redo e l'attività dei thread di purge, poiché la cronologia accumulata può occupare memoria e I/O, aumentando la frammentazione a livello di sistema operativo. È importante modificare le impostazioni gradualmente, misurarle e mantenerle solo se le latenze e i tassi di errore diminuiscono effettivamente.
Evitare lo swap: impostazioni del kernel e NUMA
Non appena Linux attiva lo swap, i tempi di risposta aumentano di ordini di grandezza, perché gli accessi alla RAM diventano I/O lenti. Abbasso notevolmente vm.swappiness in modo che il kernel utilizzi più a lungo la RAM fisica. Sugli host multi-CPU controllo la topologia NUMA e, se necessario, attivo l'interleaving per ridurre l'utilizzo non uniforme della memoria. Per quanto riguarda il contesto e l'influenza dell'hardware, mi aiuta la prospettiva di Architettura NUMA. Inoltre, pianifico riserve di sicurezza per la cache delle pagine, poiché una cache esaurita accelera la frammentazione dell'intera macchina.
Pagine enormi trasparenti, overcommit e scelta dell'allocatore
Pagine trasparenti di grandi dimensioni (THP) possono causare picchi di latenza nei database, perché l'unione/divisione di pagine di grandi dimensioni avviene in momenti inopportuni. Impostiamo THP su „madvise“ o lo disattiviamo se MySQL reagisce in modo troppo lento sotto carico. Allo stesso tempo, teniamo presente che Impegno eccessivo: Con una configurazione vm.overcommit_memory troppo generosa, si rischia di incorrere in OOM kill proprio quando la frammentazione rende rari i blocchi contigui di grandi dimensioni. Preferisco impostazioni di overcommit conservative e controllo regolarmente i log del kernel alla ricerca di segni di pressione sulla memoria.
Il Selezione dell'allocatore A livello di sistema vale la pena dare un'occhiata. glibc‑malloc, jemalloc o tcmalloc si comportano in modo diverso in termini di frammentazione. Testo sempre le alternative in modo isolato, misuro l'andamento RSS e le latenze e implemento le modifiche solo se le metriche rimangono stabili nel traffico reale. I vantaggi variano notevolmente a seconda del carico di lavoro, del mix di estensioni e della versione del sistema operativo.
Riconoscere la frammentazione: metriche e indicazioni
Presto attenzione ai rialzi graduali Linee di base per la RAM, più risposte 5xx sotto carico e ritardi nelle azioni amministrative. Uno sguardo alle statistiche PM di PHP-FPM mostra se i figli raggiungono i limiti o vivono troppo a lungo. In MySQL controllo i rapporti di hit, le tabelle temporanee su disco e Data_free per tabella. Parallelamente, le metriche del sistema operativo come gli errori di pagina, lo swap-in/out e gli indicatori di frammentazione della memoria aiutano a seconda della versione del kernel. Chi riunisce questi segnali riconosce tempestivamente i modelli e può pianificare le misure da adottare.
Approfondire il monitoraggio: come riunisco i segnali
Correlazione Metriche di applicazione (latenze p95/p99, tassi di errore) con metriche di processo (RSS per ogni worker FPM, memoria mysqld) e Valori OS (Pagecache, Slab, Major Faults). In PHP‑FPM utilizzo l'interfaccia di stato per le lunghezze delle code, i figli attivi/spawned e la durata dei worker. In MySQL osservo Created_tmp_disk_tables, Handler_write/Handler_tmp_write e Buffer‑Pool‑Misses. Inoltre, controllo le mappe di processo (pmap/smaps) per scoprire se sono state create molte piccole arene. Per me è importante la orientamento alle tendenze: non è il singolo picco, ma lo spostamento graduale nel corso di ore/giorni a determinare se la frammentazione diventa un pericolo reale.
Routine pratica: manutenzione e gestione dei dati
Riordino regolarmente Dati su: sessioni scadute, vecchi log, revisioni inutili e cache orfane. Per le tabelle soggette a forti variazioni, pianifico finestre OPTIMIZE mirate per unire le pagine frammentate. Distribuisco nel tempo i lavori di importazione di grandi dimensioni o le ondate cron, in modo che non tutti i processi richiedano contemporaneamente buffer massimi. Nei progetti in crescita, separo tempestivamente il web e il DB per isolare i modelli che richiedono molta memoria. Questa disciplina mantiene la memoria più coerente e riduce il rischio di latenze di burst.
Calcolare correttamente le dimensioni: dimensionare limiti e pool
Determino pm.max_children in base alla RAM effettivamente disponibile per PHP. A tal fine misuro il RSS medio di un worker sotto carico reale (comprese estensioni e OPcache) e aggiungo margini di sicurezza per i picchi. Esempio: su un host da 16 GB riservo 4-6 GB per OS, Pagecache e MySQL. Rimangono 10 GB per PHP; con 150 MB per worker, teoricamente si ottengono 66 child. In pratica, imposto pm.max_children a ~80-90% di questo valore per lasciare margine per i picchi, ovvero circa 52-58. pm.max_requests Scelgo in modo tale che i worker vengano riciclati prima di una frammentazione significativa (spesso nell'intervallo 500-2.000, a seconda del mix di codice).
Per MySQL calcolo il Pool di buffer dalla dimensione dei dati attivi, non dalla dimensione totale del database. Le tabelle e gli indici importanti dovrebbero rientrare, ma la cache del sistema operativo ha bisogno di spazio per i binlog, i socket e le risorse statiche. Per il buffer di connessione calcolo il parallelismo massimo realistico. Se sono possibili 200 connessioni, non dimensiono in modo tale che il totale esploda a diversi gigabyte per connessione, ma imposto limiti rigidi che non comportano il rischio di swap anche nei momenti di picco.
Disaccoppiare code, elaborazione delle immagini e lavori secondari
Molti problemi di frammentazione sorgono quando lavori secondari gli stessi pool delle richieste frontend. Per esportazioni, crawl, conversioni di immagini o aggiornamenti dell'indice di ricerca utilizzo pool FPM separati o CLI job con chiari ulimitLimiti. Limito ulteriormente le operazioni sulle immagini con GD/Imagick tramite limiti di risorse adeguati, in modo che singole conversioni di grandi dimensioni non „frammentino“ l'intero spazio di indirizzamento. Pianifico i lavori in modo sfalsato nel tempo e assegno loro limiti di concorrenza specifici, in modo che non sovraccarichino il percorso front-end.
Container e virtualizzazione: cgroup, OOM ed effetti balloon
Nei container osservo Limiti di memoria e l'OOM killer in modo particolarmente accurato. La frammentazione fa sì che i processi vengano eseguiti prima dei limiti del cgroup, anche se nell'host sarebbe ancora disponibile della RAM. Impostiamo pm.max_children rigorosamente in base al limite del container e manteniamo una riserva sufficiente per attenuare i picchi. Evitiamo lo swapping all'interno dei container (o sull'host), perché l'indirezione aggiuntiva aumenta i picchi di latenza. Nelle VM controllo il ballooning e KSM/UKSM; la deduplicazione aggressiva consente di risparmiare RAM, ma può causare ulteriore latenza e falsare il quadro della frammentazione.
Breve lista di controllo senza punti elenco
Per prima cosa stabilisco un obiettivo realistico. limite_di_memoria per sito e osservo come si comporta il picco di utilizzo nel corso dei giorni. Successivamente ottimizzo PHP-FPM con valori pm adeguati e un pm.max_requests ragionevole, in modo che i worker frammentati funzionino come previsto. Per MySQL mi concentro su una dimensione adeguata del buffer pool e su buffer conservativi per connessione invece che su aumenti generici. A livello di kernel, riduco lo swappiness, controllo le impostazioni NUMA e mantengo libere le riserve per la cache di pagina. Infine, valuto le tabelle con anomalie Data_free e pianifico ottimizzazioni al di fuori dell'attività quotidiana.
In breve: cosa conta nell'azienda
Il massimo effetto contro la frammentazione della memoria lo ottengo con un costante riciclaggio il worker PHP‑FPM, limiti moderati e pool puliti. MySQL beneficia di dimensioni ragionevoli per il buffer pool e il buffer per connessione, nonché di tabelle ordinate. Evito lo swap in modo proattivo prestando attenzione allo swappiness e al NUMA e riservando RAM libera per la cache dei file. Il monitoraggio rivela modelli insidiosi prima che gli utenti se ne accorgano e consente interventi tranquilli e pianificati. Chi utilizza questi strumenti in modo disciplinato mantiene PHP e MySQL più veloci, affidabili ed economici senza aggiornamenti hardware immediati.
