{"id":21199,"date":"2026-08-31T11:49:34","date_gmt":"2026-08-31T09:49:34","guid":{"rendered":"https:\/\/webhosting.de\/linux-cgroup-v2-memory-controller-erklaerung-hosting-resourcen-focus\/"},"modified":"2026-08-31T11:49:34","modified_gmt":"2026-08-31T09:49:34","slug":"spiegazione-del-controller-di-memoria-cgroup-v2-di-linux-risorse-di-hosting-focus","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/linux-cgroup-v2-memory-controller-erklaerung-hosting-resourcen-focus\/","title":{"rendered":"Spiegazione del controller di memoria cgroup v2 di Linux: limitare le risorse in modo preciso"},"content":{"rendered":"<p>Spiego come <strong>cgroup v2<\/strong> che, grazie al suo controller di memoria, gestisce correttamente i limiti di memoria, protegge i servizi e isola gli eventi OOM locali. In questo modo gli amministratori definiscono chiaramente <strong>Risorse<\/strong>-Stabiliscono regole, limitano in modo controllato i picchi di carico e proteggono i processi critici dal rischio di esaurimento della memoria.<\/p>\n\n<h2>Punti centrali<\/h2>\n<p>Il seguente elenco riassume gli aspetti fondamentali che approfondisco nel mio articolo.<\/p>\n<ul>\n  <li><strong>Standardizzato<\/strong> Architettura: cgroup v2 semplifica il controllo e il monitoraggio.<\/li>\n  <li><strong>Duro<\/strong> Limite: memory.max impedisce allocazioni incontrollate.<\/li>\n  <li><strong>Delicato<\/strong> Freno: memory.high riduce la pressione senza causare eliminazioni immediate.<\/li>\n  <li><strong>Pi\u00f9 mirato<\/strong> Protezione: memory.low e memory.min assegnano priorit\u00e0 ai servizi.<\/li>\n  <li><strong>Trasparente<\/strong> Controllo: memory.current fornisce i valori di misurazione per la messa a punto.<\/li>\n<\/ul>\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\/2026\/08\/serverraum-ressourcen-6912.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>In che modo cgroup v2 gestisce la memoria in modo diverso<\/h2>\n\n<p>Riassumo i processi in <strong>Controllo<\/strong> Raggruppo i gruppi e ne gestisco il fabbisogno di memoria come un\u2019unica entit\u00e0. Con la versione v2, il kernel unifica le interfacce, consentendomi di applicare in modo coerente limiti, soglie di protezione e telemetria. La logica di memoria separa l'isolamento rigido dai freni morbidi, il che non blocca immediatamente le allocazioni, ma le rallenta in modo ordinato. In questo modo reagisco ai picchi di attivit\u00e0 senza compromettere l\u2019intero sistema, poich\u00e9 le interruzioni avvengono localmente all\u2019interno del gruppo interessato. Per l\u2019hosting e i container, ci\u00f2 garantisce una <strong>Risorse<\/strong>-Distribuzione e reazioni prevedibili alle variazioni improvvise del carico.<\/p>\n\n<p>Sfrutto queste caratteristiche per raggruppare servizi con un profilo simile e stabilire regole chiare. Separo nettamente i container, i PHP worker e i processi del database, in modo che ogni insieme di carichi di lavoro abbia i propri confini. In questo modo evito interferenze incrociate come la pressione globale sulla memoria, che pu\u00f2 influire su processi innocui. Questo isolamento pu\u00f2 essere perfezionato gradualmente, fino a quando la distribuzione del carico non reagisce in modo prevedibile. In questo modo ottengo <strong>Prevedibilit\u00e0<\/strong> durante il funzionamento e mantengo la qualit\u00e0 del servizio a livelli ottimali anche nei momenti di picco.<\/p>\n\n<h2>Panoramica dei file fiscali<\/h2>\n\n<p>La gestione della memoria ruota attorno a pochi elementi <strong>Parametri<\/strong>, che imposto nel filesystem del cgroup. Ogni cgroup riceve i propri valori per i limiti rigidi, i punti di frenata morbidi e le linee di protezione. In questo modo posso regolare il livello di intervento, passando da un recupero leggero a un isolamento senza compromessi, a seconda dell\u2019importanza del servizio. Il monitoraggio rileva parallelamente l\u2019utilizzo attuale e genera un allarme quando vengono raggiunte le soglie di protezione. Si crea cos\u00ec un ciclo di regolazione chiuso composto da valori predefiniti e valori misurati, che <strong>Risorse<\/strong>- rende possibile il controllo dei consumi.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametri<\/th>\n      <th>Gentile<\/th>\n      <th>Effetto<\/th>\n      <th>Utilizzo tipico<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>memoria.max<\/td>\n      <td>Duro <strong>Confine<\/strong><\/td>\n      <td>Blocca nuove allocazioni al di sopra del limite; terminazione locale per OOM<\/td>\n      <td>Banche dati, JVM, pool PHP-FPM con limiti ben definiti<\/td>\n    <\/tr>\n    <tr>\n      <td>memoria.alta<\/td>\n      <td>Morbido <strong>freno<\/strong><\/td>\n      <td>Aumenta il Reclaim e la latenza nelle allocazioni; nessuna eliminazione immediata<\/td>\n      <td>Un moderato rallentamento prima dell'escalation<\/td>\n    <\/tr>\n    <tr>\n      <td>memoria.bassa<\/td>\n      <td>Morbido<strong>Protezione<\/strong><\/td>\n      <td>La migliore protezione possibile contro il \u201creclaim\u201d al di sotto della soglia<\/td>\n      <td>Middleware importanti, cache, servizi centralizzati<\/td>\n    <\/tr>\n    <tr>\n      <td>memoria.min<\/td>\n      <td>Harter <strong>Protezione<\/strong><\/td>\n      <td>Nessun \"Reclaim\" al di sotto della soglia; l'OOM colpisce piuttosto altri gruppi<\/td>\n      <td>Componenti critici fondamentali<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.current<\/td>\n      <td>In diretta-<strong>Valore<\/strong><\/td>\n      <td>Mostra l'utilizzo attuale; base per gli allarmi e la messa a punto<\/td>\n      <td>Dashboard, analisi delle tendenze<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.oom.group<\/td>\n      <td>Kill-<strong>Ambito<\/strong><\/td>\n      <td>Raggruppa le uccisioni OOM a livello di gruppo<\/td>\n      <td>Terminazione coerente dei processi correlati<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linuxcgroup-memory-2321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comprendere le gerarchie e l'ereditariet\u00e0<\/h2>\n\n<p>Organizzo i cgroups <strong>gerarchico<\/strong>: I gruppi di livello superiore definiscono il quadro di riferimento, i figli ereditano i limiti e si dividono la memoria disponibile. Questa struttura rende prevedibili i parametri, ma richiede regole chiare. Il valore memory.max dei genitori limita la somma dei figli; memory.low e memory.min agiscono in caso di competizione a livello di fratelli come <strong>Priorit\u00e0<\/strong>: Un gruppo con un livello di protezione pi\u00f9 elevato tende a mantenere la propria memoria di base, mentre i gruppi meno importanti vengono sottoposti a un recupero pi\u00f9 intenso. Questo mi aiuta a proteggere i percorsi principali senza indebolire i limiti massimi globali.<\/p>\n\n<p>Faccio notare che i valori di protezione <strong>additivo<\/strong> Sono pensati cos\u00ec: valori troppo elevati per memory.min su tutti i figli bloccano il Reclaim nella gerarchia e spostano la pressione verso l\u2019alto, fino all\u2019host. Per questo motivo calibro i budget di protezione per ogni livello e lascio sempre libero un margine di sicurezza. Nei modelli a livelli definisco delle classi (critica, importante, best effort) e applico larghezze di banda e soglie di protezione coerenti per ciascuna classe. In questo modo la distribuzione del carico rimane equa e trasparente, anche quando i team gestiscono autonomamente i sottogruppi.<\/p>\n\n<h2>Limite rigido: impostare correttamente memory.max<\/h2>\n\n<p>Ho impostato <strong>memoria.max<\/strong> in modo tale che il processo abbia spazio sufficiente per i picchi, senza per\u00f2 dominare il server. A tal fine, misuro i picchi realistici, aggiungo una riserva e poi applico un limite rigoroso. Se un servizio raggiunge questo limite massimo, le allocazioni vengono sospese e il kernel termina i processi locali all\u2019interno del gruppo. Questo isolamento impedisce effetti a catena su altri carichi di lavoro. Per i servizi che richiedono molta memoria, ci\u00f2 comporta un chiaro <strong>Sicurezza<\/strong> senza danni trasversali.<\/p>\n\n<p>Per heap o cache di grandi dimensioni, prevedo consapevolmente dei margini di sicurezza, poich\u00e9 la garbage collection e le attivit\u00e0 in background generano sbalzi. Verifico il limite con test di carico, in modo che non si verifichino eventi OOM durante il normale funzionamento. Se l'utilizzo rimane costantemente vicino al limite, aumento prima la riserva oppure riduco il carico di lavoro effettivo. In questo modo mantengo ridotta la margine di errore e alta l'efficienza. Questa disciplina ripaga in <strong>Disponibilit\u00e0<\/strong> da.<\/p>\n\n<h2>Freno morbido: memory.high nella vita quotidiana<\/h2>\n\n<p>Con <strong>memoria.alta<\/strong> Imposto un punto di avviso e uno di frenata prima del limite critico. Se il gruppo supera il valore, il kernel attiva il Reclaim e rallenta le allocazioni senza procedere immediatamente alla liberazione della memoria. Sfrutto questo tempo per svuotare le cache, scaglionare il carico in batch o ridurre i limiti delle richieste. In questo modo smusso i picchi prima ancora che sia necessario ricorrere a operazioni di kill. Ci\u00f2 migliora la <strong>Qualit\u00e0 del servizio<\/strong> in caso di picchi di carico improvvisi.<\/p>\n\n<p>Scelgo un margine significativo tra memory.high e memory.max, in modo che il sistema abbia un margine di manovra reale. Se il margine \u00e8 troppo piccolo, finisco troppo in fretta in OOM. Se \u00e8 troppo grande, perdo il controllo sulle latenze. Testo entrambe le opzioni con i profili di produzione e calibro il punto ottimale. In questo modo ottengo un risultato affidabile <strong>Acceleratore<\/strong>, che entri in vigore tempestivamente.<\/p>\n\n<h2>Politica di swap: impostare con attenzione il valore di memory.swap.max<\/h2>\n\n<p>Sono io a decidere se e in che misura un gruppo <strong>Scambio<\/strong> posso utilizzare. Con memory.swap.max limito lo swap indipendentemente dal limite della RAM. Impostando il valore su 0, disabilito lo swap per il gruppo \u2013 utile per i servizi sensibili alla latenza che non devono bloccarsi. Se consento uno swap moderato, ottengo maggiore elasticit\u00e0 per le cache e le pagine utilizzate raramente. \u00c8 importante che io <strong>urgenza<\/strong> a seconda dei carichi di lavoro: i database e le JVM traggono spesso vantaggio da una politica di swap rigorosa o molto restrittiva, mentre i processi batch o di reporting gestiscono lo swap in modo pi\u00f9 flessibile.<\/p>\n\n<p>Metto in relazione la strategia di swap con la configurazione dell\u2019host (ad es. swappiness, zram\/zswap), in modo che le misure adottate non si contraddicano a vicenda. Uno swap eccessivo maschera la carenza di memoria solo a breve termine e sposta il carico sull\u2019I\/O: lo utilizzo in modo mirato come <strong>Buffer<\/strong>, non come condizione permanente. Parametri come i \"Major Page Faults\" e le latenze indicano rapidamente se lo swap \u00e8 d'aiuto o se rallenta il sistema. In questo modo mantengo il controllo sui ritardi e sulle latenze di coda.<\/p>\n\n<h2>Linee di protezione: memory.low e memory.min<\/h2>\n\n<p>Uso <strong>memoria.bassa<\/strong>, per garantire la memoria di base ai servizi importanti. Finch\u00e9 l\u2019utilizzo rimane al di sotto di tale soglia, il kernel preserva questa quota e preferisce recuperare memoria altrove. Per i componenti ad alta priorit\u00e0 utilizzo inoltre memory.min. Questa linea di protezione rigida indica chiaramente al kernel che non permetto alcun recupero in quest\u2019area. In questo modo, il cuore di un\u2019applicazione rimane operativo anche sotto carico estremo e <strong>reattivo<\/strong>.<\/p>\n\n<p>Stabilisco consapevolmente questa ponderazione: ai database centrali assegno memory.min, al middleware critico memory.low, mentre ai processi batch non critici non viene assegnata alcuna protezione aggiuntiva. Questa gerarchia facilita le decisioni in caso di colli di bottiglia. Se si verifica un OOM, questa classificazione protegge i miei percorsi chiave. Mantengo il controllo su chi cede per primo la memoria. Questo mi offre una chiara <strong>Priorit\u00e0<\/strong> in caso di colli di bottiglia.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-memory-control-explained-2984.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Trasparenza: memory.current nel monitoraggio<\/h2>\n\n<p>Ho letto <strong>memory.current<\/strong> Lo analizzo costantemente e lo metto in relazione con le metriche delle applicazioni. In questo modo individuo le tendenze, l\u2019accumulo di backlog e i picchi. Se il sistema rileva un aumento dei superamenti del valore memory.high o degli eventi OOM, adeguo i limiti o il carico di lavoro. I dashboard e gli allarmi mi consentono di anticipare i malfunzionamenti. Da questi dati ricavo <strong>Sintonizzazione<\/strong>-adotta decisioni volte a evitare perdite a lungo termine.<\/p>\n\n<p>Oltre al valore in s\u00e9, monitoro i tassi di page fault, la percentuale di hit della cache e le latenze. Questa panoramica mi permette di capire se il processo di reclaim rallenta troppo il sistema o se intervengono le linee di protezione. Regolo gli intervalli e i valori di soglia finch\u00e9 gli allarmi non diventano utili anzich\u00e9 fastidiosi. Successivamente automatizzo le contromisure, come il cache trim o la limitazione delle code. In questo modo la reazione rimane rapida e <strong>mirato<\/strong>.<\/p>\n\n<h2>Approfondimento sulla telemetria: memory.stat, memory.events e PSI<\/h2>\n\n<p>Aggiungo a `memory.current` <strong>memory.stat<\/strong> e <strong>memory.events<\/strong>, per individuare le cause anzich\u00e9 limitarsi ai sintomi. memory.stat suddivide l\u2019utilizzo in Anon, File-Cache, Slab e altre categorie. Da queste percentuali deduco se stanno aumentando le allocazioni di un\u2019applicazione o della cache delle pagine \u2013 e intervengo di conseguenza (ad es. dimensioni della cache rispetto al numero di worker). memory.events e memory.events.local contano gli eventi come il superamento dei limiti low\/high\/max, nonch\u00e9 <strong>oom<\/strong> e <strong>oom_kill<\/strong>. Ci\u00f2 fornisce trigger affidabili per gli allarmi e la correzione automatica.<\/p>\n\n<p>Uso anche <strong>PSI<\/strong> (Pressure Stall Information), per quantificare la pressione anzich\u00e9 fare supposizioni. Se i valori PSI della memoria aumentano in modo persistente, i thread subiscono tempi di attesa; in tal caso, riduco il carico di lavoro, aumento il valore di memory.high o alleggerisco la larghezza di banda nella pipeline. Nel complesso, si ottiene una telemetria che mi fornisce informazioni graduali <strong>Avvisi tempestivi<\/strong> fornisce \u2013 prima che i limiti rigidi diventino vincolanti.<\/p>\n\n<h2>Container e orchestrazione<\/h2>\n\n<p>Se imposto dei limiti di memoria in Kubernetes, questi vengono salvati come <strong>cgroup<\/strong>Valori come `memory.max` e, facoltativamente, `memory.high` nel runtime. L\u2019orchestrazione applica le policy a livello di pod, mentre io definisco le impostazioni dettagliate per ogni namespace o deployment. Per garantire SLO affidabili, associo i limiti alle strategie HPA e ai pod budget. Questo approccio olistico impedisce che singoli pod monopolizzino la memoria. Una buona introduzione a <a href=\"https:\/\/webhosting.de\/it\/cgroups-hosting-isolamento-delle-risorse-linux-containerlimits-serverboost\/\">Isolamento delle risorse con i cgroup<\/a> facilita la progettazione di container con confini ben definiti e vie di accesso.<\/p>\n\n<p>Verifico inoltre che ai sidecar e agli init-container vengano assegnati limiti propri, in modo che i processi ausiliari non limitino i carichi di lavoro principali. Per i carichi di lavoro con stato, imposto memory.low o memory.min, affinch\u00e9 le cache e i buffer non si riducano immediatamente. Documento queste decisioni nella distribuzione, in modo che il team possa comprenderle facilmente. In questo modo garantisco <strong>Coerenza<\/strong> tra infrastruttura e applicazione. Il risultato sono profili di carico prevedibili.<\/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\/2026\/08\/Tech_Office_Linux_cgroup_7458.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Integrazione con Systemd e automazione<\/h2>\n\n<p>Utilizzo systemd per impostare in modo dichiarativo i parametri di cgroup v2: <strong>MemoryMax<\/strong> corrisponde a memory.max, <strong>MemoriaAlta<\/strong> memory.high, <strong>MemoryLow<\/strong> e <strong>MemoryMin<\/strong> tracciano linee di protezione, <strong>MemorySwapMax<\/strong> \u00e8 gestito da Swap. Questa rappresentazione rende le policy tracciabili nel repository del codice e facilita i rollback. In ambienti di grandi dimensioni, la utilizzo per orchestrare in modo coerente <strong>Standard<\/strong> per ogni classe di servizio e separare il funzionamento dagli interventi manuali.<\/p>\n\n<p>Per gli interventi automatici, combino gli eventi di memory.events\/PSI con i motori delle policy. Se un gruppo supera ripetutamente il valore di `memory.high`, riduco il numero di worker in parallelo, limito i tassi di picco o attivo <strong>mirati<\/strong> Cache-Trim. Se questi livelli non funzionano, lascio che i meccanismi OOM integrati nel sistema agiscano in modo controllato: grazie a `memory.oom.group`, l'effetto rimane locale e prevedibile. Si ottiene cos\u00ec un comportamento graduale e autorigenerante, senza sorprese.<\/p>\n\n<h2>Hosting multi-tenant con CloudLinux<\/h2>\n\n<p>Incapsulo gli ambienti dei clienti in file separati <strong>cgroups<\/strong> e assegno limiti chiari a ciascun tenant. CloudLinux integra questa funzionalit\u00e0 con strumenti che delimitano RAM, CPU e I\/O per ogni account. In questo modo gli effetti di vicinato rimangono gestibili e i singoli casi anomali non compromettono tutti gli account. Chi desidera approfondire l\u2019argomento trover\u00e0 una panoramica pratica su <a href=\"https:\/\/webhosting.de\/it\/cgroup-v2-cloudlinux-hosting-condiviso-stabile\/\">CloudLinux e cgroup v2<\/a> nel contesto dell'hosting condiviso. In questo modo mantengo condizioni eque <strong>Risorse<\/strong>-Distribuzione su un ampio numero di clienti.<\/p>\n\n<p>Imposto `memory.max` per ogni cliente in base al profilo giornaliero rilevato, assegno un valore `memory.low` alle cache e proteggo i processi fondamentali con `memory.min`. In caso di superamento dei limiti, vengono attivati innanzitutto i meccanismi di throttling, anzich\u00e9 limitare drasticamente gli account. Se si verifica un errore OOM, questo interessa solo localmente il gruppo interessato. In questo modo la piattaforma rimane utilizzabile per gli altri tenant. Questo approccio rafforza <strong>Pianificabilit\u00e0<\/strong> rispetto ai picchi di traffico.<\/p>\n\n<h2>Casi particolari: cache delle pagine, THP e pagine di grandi dimensioni<\/h2>\n\n<p>Faccio una distinzione tra <strong>Anonimo<\/strong>-Memorie (heap, stack) e <strong>Cache dei file<\/strong> (Cache delle pagine). In condizioni di carico elevato, \u00e8 pi\u00f9 facile liberare la cache dei file, mentre le pagine anonime richiedono lo swap o causano errori OOM. I parametri `memory.high` e le linee di protezione mi aiutano a ridurre la cache dei file senza intaccare gli heap critici. Per quanto riguarda le Transparent Huge Pages (THP), verifico se apportano benefici all\u2019applicazione o se aumentano la frammentazione e le latenze; a seconda del profilo, adeguo la politica relativa alle THP affinch\u00e9 l\u2019interazione con il controller di memoria rimanga armoniosa.<\/p>\n\n<p>Utilizza un'applicazione <strong>Hugepages<\/strong> In modo esplicito, isolo il loro fabbisogno tramite i relativi controller, separandolo dal controllo della RAM. In questo modo impedisco che pagine di grandi dimensioni occupino spazio a scapito della memoria di lavoro regolare. Mantengo queste riserve speciali a livelli ridotti e le integro con i restanti limiti, in modo da evitare colli di bottiglia imprevisti. Nel complesso, si creano cos\u00ec chiari limiti di riferimento per l\u2019utilizzo della memoria sia regolare che speciale.<\/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\/2026\/08\/linux_cgroup_me_script_1283.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Migliori pratiche per i limiti<\/h2>\n\n<p>Parto da profili di consumo reali e definisco <strong>memoria.max<\/strong> con un margine di riserva, in modo che i picchi non attivino immediatamente l\u2019OOM. Impostiamo memory.high a un valore notevolmente inferiore, per smussare le onde di carico e rallentare le allocazioni. \u00c8 importante stabilire delle priorit\u00e0: al database viene assegnato `memory.min`, al middleware `memory.low`, mentre al carico batch non viene attribuito alcun ruolo speciale. Il monitoraggio accompagna il funzionamento e indica se le soglie sono efficaci o se sono state impostate in modo troppo rigido. Sulla base di questi segnali, adeguo i limiti e contemporaneamente aumento il <strong>Efficienza<\/strong> dell'applicazione.<\/p>\n\n<p>Documento i valori per ogni servizio, ne descrivo le motivazioni e registro le modifiche in modo tracciabile. In questo modo consolido le decisioni all\u2019interno del team ed evito che, dopo settimane, si finisca per tirare a indovinare. Prima di effettuare aggiornamenti o modifiche all\u2019architettura, esamino i grafici di andamento per evitare di inasprire o allentare le impostazioni alla cieca. Una piccola fase di test evita in seguito molti problemi in produzione. Questo ritmo garantisce <strong>Costanza<\/strong> nel lavoro quotidiano.<\/p>\n\n<h2>Esercitazione pratica: come organizzare i server di web hosting<\/h2>\n\n<p>Per ogni cliente creo una propria <strong>cgroup<\/strong> e vi sposto PHP-FPM, il database e la cache. A ogni set assegno memory.max pi\u00f9 un buffer, mentre memory.high interviene prima e smussa i picchi. I servizi critici del cliente ricevono linee di protezione affinch\u00e9 la loro memoria di base non cali. Log e dashboard mostrano chi rallenta, chi accelera e dove c'\u00e8 il rischio di OOM. Inoltre, sono utili indicazioni su <a href=\"https:\/\/webhosting.de\/it\/contesto-server-isolamento-spazi-dei-nomi-cgroups-hosting-sicurezza\/\">Spazi dei nomi e concetti di isolamento<\/a>, in modo che i clienti rimangano ben separati e <strong>Sicurezza<\/strong> aumenti.<\/p>\n\n<p>Regolo inoltre il numero di worker PHP, le dimensioni dell\u2019OPcache e delle cache delle query per ridurre l\u2019impronta di memoria. Spesso basta ridurre i picchi tramite memory.high per abbreviare i tempi. Per i test utilizzo modelli di carico reali, non valori sintetici ideali. Successivamente documento i nuovi limiti e li collego agli SLA. In questo modo cresce la <strong>Trasparenza<\/strong> nei confronti dei clienti e del supporto interno.<\/p>\n\n<h2>Risoluzione dei problemi relativi alla stampa della memoria<\/h2>\n\n<p>Aumenta <strong>memory.current<\/strong> In caso di picchi improvvisi, verifico innanzitutto eventuali modifiche al traffico, alle implementazioni o alle configurazioni. Confronto i grafici relativi ai superamenti dei limiti massimi, ai page fault e alle latenze. Se si verificano OOM in serie, identifico i processi interessati tramite il log del kernel e adeguo i limiti o il carico di lavoro. Se la causa \u00e8 da ricercarsi in cache difettose, intervengo in modo mirato, anzich\u00e9 applicare una soluzione globale. Questa sequenza diagnostica mi porta rapidamente alla <strong>Causa<\/strong>, non solo un sintomo.<\/p>\n\n<p>Se il carico rimane elevato, distribuisco il lavoro: limito i burst per Ingress, riduco la lunghezza delle code, rimando i lavori in batch. Contemporaneamente, aumento temporaneamente il valore di `memory.high` per guadagnare tempo senza aumentare `memory.max`. Se rilevo delle perdite di memoria, restringo i limiti di sicurezza fino a quando non viene applicata una correzione. Nei casi pi\u00f9 ostinati, riduco l'ambito del servizio o replico l'istanza. In questo modo mantengo il <strong>Operazione<\/strong> funziona in modo affidabile, anche sotto pressione.<\/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\/2026\/08\/linux-cgroup-memory-4297.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Automazione: contromisure basate sugli eventi<\/h2>\n\n<p>Faccio i nodi <strong>Azioni<\/strong> Per quanto riguarda gli eventi: memory.events fornisce dei contatori che elaboro tramite watcher o pipeline di metriche. In caso di ripetuti picchi elevati, svuoto in modo mirato le cache, riduco la concorrenza o avvio tentativi di reclaim prima che gli utenti se ne accorgano. Se gli interventi lievi falliscono, passo a misure drastiche: blocco delle richieste, svuotamento delle code, modifica delle priorit\u00e0. \u00c8 importante che le decisioni <strong>deterministico<\/strong> sono \u2013 stessi fattori scatenanti, stessa reazione \u2013 affinch\u00e9 i team possano comprendere e riprodurre determinati comportamenti.<\/p>\n\n<p>Inoltre, mi riservo il diritto di <strong>Ambito<\/strong> tenendo d\u2019occhio l\u2019OOM. Con memory.oom.group evito le chiusure parziali che portano le applicazioni in stati incoerenti. Se \u00e8 necessario terminare un'applicazione, ci\u00f2 deve avvenire in modo coordinato e rapido, in modo che le capacit\u00e0 residue tornino rapidamente disponibili. In combinazione con la telemetria e i playbook documentati, si crea un solido ciclo di feedback che regge nelle reali condizioni di produzione.<\/p>\n\n<h2>Prospettive e sintesi<\/h2>\n\n<p>Il controller di memoria di <strong>cgroup<\/strong> La versione v2 mi offre una serie di strumenti graduali: limiti rigidi, freni morbidi e linee di protezione con priorit\u00e0 ben definite. Se utilizzo in modo mirato memory.max, memory.high, memory.low e memory.min, reagisco in modo ordinato ai picchi di carico e mantengo i servizi operativi. Il monitoraggio tramite memory.current rivela tempestivamente dove i limiti stanno per essere superati o dove mancano riserve. Nelle configurazioni containerizzate e multi-tenant, questi meccanismi garantiscono un\u2019allocazione equa delle risorse senza ripercussioni negative. Con disciplina, valori di misurazione e piccoli aggiustamenti riesco a ottenere risultati affidabili <strong>Prestazioni<\/strong> \u2013 dalla singola macchina virtuale all\u2019host con un carico elevato.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scopri come funziona il controller di memoria cgroup v2 di Linux e come creare ambienti di hosting e container stabili utilizzando limiti mirati delle risorse Linux.<\/p>","protected":false},"author":1,"featured_media":21192,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21199","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"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":"220","_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":"1","_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":"cgroup v2","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":"21192","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21199","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=21199"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21199\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21192"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21199"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21199"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21199"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}