{"id":20212,"date":"2026-08-01T08:32:36","date_gmt":"2026-08-01T06:32:36","guid":{"rendered":"https:\/\/webhosting.de\/memory-pressure-linux-kernel-hosting-systeme-optimierung-ram\/"},"modified":"2026-08-01T08:32:36","modified_gmt":"2026-08-01T06:32:36","slug":"pressione-di-memoria-kernel-linux-sistemi-di-hosting-ottimizzazione-ram","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/memory-pressure-linux-kernel-hosting-systeme-optimierung-ram\/","title":{"rendered":"Pressione sulla memoria nel kernel Linux: ripercussioni sui sistemi di hosting"},"content":{"rendered":"<p>La \u201cmemory pressure\u201d nel kernel di Linux ha un impatto diretto sui sistemi di hosting: se la pressione aumenta, il tempo di CPU e l\u2019I\/O si spostano verso operazioni pi\u00f9 onerose <strong>Reclaim<\/strong>, i tempi di risposta aumentano e i rischi di OOM crescono. Spiego chiaramente come individuare, misurare e mitigare la pressione sulla memoria, in modo che <strong>Ospitare<\/strong>-Rispondere in modo costante ai carichi di lavoro.<\/p>\n\n<h2>Punti centrali<\/h2>\n<p>Mi concentro sui fattori chiave che, negli ambienti di hosting, determinano le prestazioni e i guasti. I punti seguenti costituiscono il filo conduttore su cui baso la diagnosi e l\u2019ottimizzazione. Grazie a questa panoramica, evito interpretazioni errate del messaggio \u201eRAM piena\u201c e individuo i veri <strong>Pressione<\/strong> per tempo.<\/p>\n<ul>\n  <li><strong>Metriche PSI<\/strong> Mostrano i tempi di attesa anzich\u00e9 la semplice occupazione e individuano tempestivamente eventuali ritardi.<\/li>\n  <li><strong>Carico di swap<\/strong> segnala problemi di reclaim che aggravano gli I\/O e le latenze.<\/li>\n  <li><strong>Limiti dei cgroup<\/strong> Gestire la limitazione, la protezione e il comportamento in caso di OOM per ogni servizio.<\/li>\n  <li><strong>Sostituzione della cache<\/strong> influisce direttamente sulle prestazioni del sito web e del database.<\/li>\n  <li><strong>Pianificazione della capacit\u00e0<\/strong> e il tuning mantengono l'headroom ed evitano il thrashing.<\/li>\n<\/ul>\n<p>In questo modo strutturo le mie analisi, dal kernel all\u2019applicazione, e attuo le misure adeguate secondo un ordine di priorit\u00e0. L\u2019attenzione rimane concentrata su aspetti misurabili <strong>Effetti<\/strong>, non al lavoro a cottimo.<\/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\/2026\/08\/serverraum-memorydruck-4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cosa significa \"memory pressure\" nel kernel di Linux?<\/h2>\n\n<p>La \u201ememory pressure\u201c significa che il kernel dedica una quantit\u00e0 di tempo percepibile a liberare memoria, invece di proseguire l'elaborazione dei processi utente; la CPU si dedica quindi maggiormente alle operazioni di scansione, scrittura ed espulsione, mentre le richieste rimangono in attesa. Distinguo chiaramente tra \u201eRAM piena\" e \"mancanza di memoria utilizzabile\" <strong>spazio libero<\/strong>\u201c: Una cache \u201epiena\u201c \u00e8 un fenomeno normale; i colli di bottiglia si verificano solo quando gli investimenti in Reclaim aumentano. Il kernel esegue una scansione delle liste inattive, scrive <strong>sporco<\/strong>-elimina le pagine, svuota la cache dei file e sposta le pagine anonime non appena si scende al di sotto delle soglie di watermark. Il fattore determinante \u00e8 il tempo impiegato per queste attivit\u00e0, che si riflette nei tempi di attesa delle attivit\u00e0 e nei tempi di risposta prolungati. Un host pu\u00f2 funzionare in modo silenzioso con un utilizzo del 95% %, purch\u00e9 la cache sia facilmente recuperabile, ma pu\u00f2 bloccarsi pesantemente a basso carico di lavoro se le pagine anonime attive devono essere sostituite.<\/p>\n\n<h2>Comprendere e misurare il PSI<\/h2>\n\n<p>Pressure Stall Information (PSI) rende tangibile la pressione sulla memoria, poich\u00e9 non misuro l'occupazione, ma i ritardi. In <strong>\/proc\/pressione\/memoria<\/strong> Vedo \u201esome\u201c e \u201efull\u201c: \u201esome\u201c descrive i momenti in cui almeno un\u2019attivit\u00e0 \u00e8 in attesa di memoria, mentre \u201efull\u201c indica le fasi in cui tutte le attivit\u00e0 sono bloccate. Esempio: \u201esome avg10=4.67\u201c significa che negli ultimi 10 secondi si sono verificati 4,67 % di stallo dovuti a colli di bottiglia della memoria; \u201efull avg10=0.30\u201c indica rari casi di blocco totale. Correlando tempestivamente i valori crescenti di \u201esome\u201c con i tempi di risposta, provvedo a ridimensionare, ottimizzare o alleggerire il carico prima che si verifichino gravi OOM. Questa prospettiva mi impedisce di farmi ingannare da una RAM apparentemente \u201elibera\u201c, poich\u00e9 le pagine libere senza un accesso rapido <strong>Reclaim<\/strong>-Ne approfittano pochi.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Variabile misurata<\/th>\n      <th>Valore indicativo<\/th>\n      <th>Sintomo<\/th>\n      <th>Azione<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Memoria PSI (media 10)<\/td>\n      <td>&gt; 2\u20133 % prolungato<\/td>\n      <td>I tempi di risposta aumentano<\/td>\n      <td>Verificare il margine della RAM, regolare con precisione i limiti dei cgroup<\/td>\n    <\/tr>\n    <tr>\n      <td>Memoria PSI piena (avg10)<\/td>\n      <td>&gt; 0,1 % percepibile<\/td>\n      <td>Tempi di inattivit\u00e0 brevi<\/td>\n      <td>Identificare la causa, porre fine al thrashing<\/td>\n    <\/tr>\n    <tr>\n      <td>MemDisponibile<\/td>\n      <td>&lt; 10 % di RAM<\/td>\n      <td>Margine ridotto<\/td>\n      <td>Alleggerire la cache\/il carico di lavoro, pianificare la capacit\u00e0<\/td>\n    <\/tr>\n    <tr>\n      <td>vmstat si\/so<\/td>\n      <td>costante &gt; 0<\/td>\n      <td>Pressione di swap<\/td>\n      <td>Swappiness\/Personalizza lo swap, proteggi l'Hotset<\/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\/memorypressurekonferenz3542.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sintomi negli ambienti di hosting<\/h2>\n\n<p>Sugli host molto trafficati noto innanzitutto picchi di latenza, mentre il carico della CPU sembra rimanere moderato; il kernel \u00e8 bloccato in cicli di reclaim, l\u2019I\/O si accumula e le richieste rimangono in attesa. Il carico medio sale, anche se i core sembrano liberi, perch\u00e9 molte attivit\u00e0 sono bloccate dalla memoria o dall\u2019I\/O; questo \u00e8 un segno distintivo di un aumento <strong>Stampa<\/strong>. Valori si\/so persistenti in vmstat indicano che il sistema sta effettuando attivamente lo swap, il che rallenta gli handshake TLS, i contenuti dinamici e i percorsi di query. Se la situazione non viene risolta, il sistema entra in fase di thrashing: la CPU trascorre gran parte del tempo in paging e swapping, invece di svolgere attivit\u00e0 utili. In caso di escalation, interviene l\u2019OOM-Killer e termina i processi con un punteggio elevato; un intervento mirato <a href=\"https:\/\/webhosting.de\/it\/oom-killer-linux-memoria-out-of-memory-analisi-hosting\/\">Analisi dell'OOM-Killer<\/a> mi aiuta a individuare schemi ricorrenti e configurazioni errate.<\/p>\n\n<h2>Rilevanza per i carichi di lavoro di hosting e i cgroup<\/h2>\n\n<p>Negli ambienti gestiti in modo condiviso, bastano poche applicazioni che consumano molte risorse di memoria per aumentare le latenze per molti clienti; i cgroup attenuano l'impatto, ma non risolvono il problema di un dimensionamento errato <strong>Istanze<\/strong>. Nei VPS e nelle istanze cloud, una quantit\u00e0 di RAM insufficiente o una strategia di swap inadeguata porta pi\u00f9 rapidamente a picchi di carico; l\u2019isolamento protegge gli altri servizi, ma non il proprio. I database si basano su grandi pool di buffer; se Reclaim li sostituisce o interviene lo swap, i tempi di query aumentano e la velocit\u00e0 di elaborazione diminuisce in modo significativo. Le orchestrazioni dei container utilizzano memory.low, memory.high e memory.max per proteggere i servizi importanti, limitare i blocchi e, in caso di emergenza, terminarli in modo mirato. Scelgo quindi i limiti in modo consapevole e monitoro il PSI per ogni servizio, per intervenire tempestivamente e garantire riserve per i servizi critici <strong>Carichi di lavoro<\/strong> tenere libero.<\/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-pressure-hosting-4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Strategia di monitoraggio e metriche<\/h2>\n\n<p>Controllo i valori di MemAvailable, Buffers e Cached per capire quanta memoria sia recuperabile nell\u2019immediato; i valori di MemFree da soli possono facilmente indurre in errore. Contemporaneamente controllo vmstat: valori si\/so persistenti indicano una pressione sullo swap, che accelera enormemente l\u2019I\/O e fa aumentare le latenze; per ulteriori approfondimenti su <a href=\"https:\/\/webhosting.de\/it\/utilizzo-dello-swap-prestazioni-del-server-hosting-optimus\/\">Utilizzo dello swap<\/a> Utilizzo modelli diagnostici collaudati. PSI mi fornisce l\u2019elemento mancante, poich\u00e9 \u201esome\u201c e \u201efull\u201c quantificano i ritardi effettivi; genero allarmi al superamento delle soglie e distinguo i picchi di carico dai colli di bottiglia cronici. Le serie temporali ottenute tramite sar o lo stack di osservabilit\u00e0 rendono visibili gli schemi e mi aiutano a confermare i risultati dell\u2019ottimizzazione. dmesg rivela gli eventi OOM che indicano limiti rigidi o configurazioni errate; in questo modo costruisco un quadro coerente dal punto di vista del kernel, del comportamento I\/O e <strong>Applicazione<\/strong>.<\/p>\n\n<h2>Carichi di lavoro tipici sotto pressione<\/h2>\n\n<p>I server web come Nginx o Apache forniscono i contenuti pi\u00f9 lentamente quando Reclaim e Swap sono in esecuzione in background; le connessioni Keep-Alive rimangono aperte pi\u00f9 a lungo, il che aggrava le code. Gli stack PHP e Python occupano RAM a causa delle cache dei framework, delle parti JIT e dei dati di sessione; in caso di sovrascrittura, questi dati oscillano tra la RAM e lo storage, allungando notevolmente i tempi di risposta. I database perdono velocit\u00e0 non appena i pool di buffer si riducono o parti di essi finiscono nello swap; anche una minima latenza aggiuntiva per ogni operazione di I\/O si somma in presenza di molte <strong>Domande<\/strong>. I servizi di caching come Redis o Memcached necessitano di accessi alla RAM; se le aree delle chiavi finiscono nello swap, il vantaggio viene meno e aumenta il rischio di essere terminati in caso di carico elevato. In tutti i casi, le metriche relative alla PSI e allo swap forniscono le indicazioni pi\u00f9 chiare del fatto che la memoria \u00e8 diventata il collo di bottiglia e non la <strong>CPU<\/strong>.<\/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_kernel_memory_pressure_4092.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ottimizzazione del sistema e parametri del kernel<\/h2>\n\n<p>Comincio da vm.swappiness: un valore moderatamente ridotto impedisce un ricorso eccessivo allo swap, senza per\u00f2 bloccare il reclaim necessario; misuro costantemente gli effetti con PSI. Successivamente ottimizzo vm.dirty_ratio e i limiti correlati, in modo da non innescare lunghe ondate di flush senza per\u00f2 provocare un\u2019eccessiva scrittura di dati di piccole dimensioni; entrambi questi aspetti hanno effetti tangibili <strong>Effetti<\/strong> sulle latenze. Su Cgroups v2 imposto memory.low per i servizi critici, memory.high per la limitazione in caso di sovraccarico e memory.max come limite massimo con OOM controllabili. Presto particolare attenzione alle topologie NUMA: pu\u00f2 verificarsi una pressione locale anche se a livello globale c\u2019\u00e8 ancora RAM libera; il binding di processi e memoria mitiga tali insidie. Infine, verifico il comportamento della cache di pagina; lo spostamento superfluo riduce i tassi di hit e comporta una perdita di tempo immediata nei carichi di lavoro web e database, a cui si aggiunge il <a href=\"https:\/\/webhosting.de\/it\/server-page-cache-eviction-linux-memoria-stampa-ottimizzazione-insight\/\">Ottimizzazione della cache delle pagine<\/a> fornisce spunti utili.<\/p>\n\n<h2>Uno sguardo approfondito ai percorsi di recupero<\/h2>\n<p>Per scegliere le misure pi\u00f9 adeguate, distinguo tra <strong>kswapd<\/strong> e <strong>Recupero diretto<\/strong>. kswapd opera in modo asincrono quando si scende al di sotto dei livelli di soglia; il suo funzionamento \u00e8 relativamente delicato fintanto che \u00e8 disponibile una quantit\u00e0 sufficiente di cache facilmente recuperabile. Direct Reclaim interviene in modo sincrono nei contesti di esecuzione quando i thread hanno un bisogno urgente di pagine: \u00e8 qui che si verificano i rallentamenti percepibili dagli utenti. Osservo se il reclaim colpisce maggiormente la cache dei file o le pagine anonime: se il kernel sostituisce principalmente la cache dei file, aumentano i cache miss; se sostituisce la memoria anonima (ad es. l\u2019heap), si rischiano arresti bruschi e attivit\u00e0 di swap. I moderni meccanismi di working set tengono conto delle distanze di refault per mantenere pi\u00f9 a lungo le pagine utili; se nonostante ci\u00f2 osservo molti refault ripetuti, so che gli hotset sono pi\u00f9 grandi dello spazio disponibile <strong>spazio libero<\/strong> sono diventati.<\/p>\n<p>Inoltre, tengo conto della compattazione e della deframmentazione: <strong>kcompactd<\/strong> cerca di creare aree contigue, ad esempio per grandi allocazioni o <strong>THP<\/strong>. Se la compattazione rimane indietro, noto un aumento dell\u2019utilizzo della CPU da parte di kcompactd, latenze crescenti e un aumento della percentuale di PSI \u201efull\u201c durante i picchi di carico. In questi casi, spesso \u00e8 pi\u00f9 sensato ridurre la pressione o adeguare le politiche THP, anzich\u00e9 limitarsi ad aumentare lo \u201eswap\u201c.<\/p>\n\n<h2>Le strategie di swap nel dettaglio<\/h2>\n<p>Lo swap non \u00e8 un nemico, ma uno strumento; se utilizzato in modo errato, per\u00f2, aumenta la latenza. Faccio una distinzione:<\/p>\n<ul>\n  <li><strong>Nessuno swap<\/strong>: Sicuro contro gli swap lag, ma rischioso in caso di picchi \u2013 gli OOM si verificano prima, Reclaim non dispone di un buffer di riserva.<\/li>\n  <li><strong>Swap moderato<\/strong> su un SSD veloce: ottimo per spostare in swap le pagine fredde e anonime; protegge gli hotset nella RAM, se i valori di swappiness e i limiti dei cgroup sono impostati in modo oculato.<\/li>\n  <li><strong>zswap\/zram<\/strong>: La compressione alleggerisce il carico di I\/O; \u00e8 indicata per host con un carico di I\/O ridotto o come buffer contro picchi di carico di breve durata. Verifico il budget della CPU e il rapporto di compressione per evitare che la CPU diventi un collo di bottiglia.<\/li>\n<\/ul>\n<p>Non imposto il valore di swappiness su un livello basso in modo generalizzato; in caso di carichi di lavoro con una cache di file di grandi dimensioni, \u00e8 opportuno impostare un valore di swappiness leggermente pi\u00f9 alto per eliminare le pagine anonime inattive e mantenere stabile la cache di file. Proteggo i servizi critici (ad es. i database) con `memory.low` e, se necessario, bloccando i loro hotset nella RAM, in modo che lo swap non colpisca gli elementi sbagliati. \u00c8 fondamentale che <strong>vmstat si\/so<\/strong> e i valori PSI diminuiscono in modo costante quando adeguo la strategia; in caso contrario, procedo a una correzione.<\/p>\n\n<h2>THP, compattazione e frammentazione<\/h2>\n<p><strong>Pagine enormi trasparenti (THP)<\/strong> riducono gli accessi alla TLB e aiutano le applicazioni che sollecitano la CPU e richiedono un uso intensivo della memoria. In condizioni di carico elevato, tuttavia, generano operazioni di compattazione; l\u2019impostazione \u201ealways\u201c pu\u00f2 quindi causare lunghi tempi di stallo. Utilizzo \u201emadvise\u201c in modo mirato per i carichi di lavoro che ne traggono vantaggio (ad es. determinati motori in-memory) e, nel caso di stack web sensibili alla latenza, preferisco disattivare THP in modo mirato o abilitarlo solo tramite madvise. Inoltre, osservo <strong>vm.compaction_proactiveness<\/strong> e verifica se la compattazione proattiva posticipa la formazione di stalle o le riduce effettivamente. Se le facce THP vengono spesso tagliate o se la compattazione si surriscalda, ci\u00f2 indica una quantit\u00e0 insufficiente di <strong>spazio libero<\/strong> oppure modelli di allocazione inadeguati nell'applicazione.<\/p>\n\n<h2>Trappole NUMA e pressione locale<\/h2>\n<p>Sugli host NUMA, la \u201eRAM libera\u201c globale \u00e8 ingannevole: un socket pu\u00f2 essere sotto pressione, mentre un altro rimane inutilizzato. Controllo le statistiche NUMA e ancoro i processi a livello locale (vincolo CPU\/memoria), in modo che gli hotset rimangano vicini al carico di calcolo. Il Direct Reclaim su un nodo, nonostante le riserve globali, segnala squilibri NUMA; in questo caso sono utili le allocazioni interleaved per servizi ampiamente distribuiti o il binding rigoroso per carichi di lavoro monolitici. Il PSI per cgroup, combinato con le statistiche NUMA, mi mostra se \u00e8 un singolo nodo a generare le code.<\/p>\n\n<h2>Misure relative alle applicazioni<\/h2>\n\n<p>Analizzo i profili di memoria con ps, top, htop e strumenti di profilazione per individuare i veri \u201cdivoratori\u201d di memoria e le perdite; nel farlo, osservo come cambiano gli hotset nel corso del tempo. Scelgo con attenzione le cache delle applicazioni: troppo grandi generano pressione, troppo piccole compromettono la velocit\u00e0; effettuo le regolazioni tenendo conto dei valori PSI e dei tempi di risposta, non basandomi sull\u2019istinto. Quando vengono rilevati segnali di pressione, l\u2019applicazione pu\u00f2 liberare volontariamente cache meno critiche o dati temporanei; in questo modo riduco i blocchi senza intervenire sui limiti globali. Adatto i parametri di avvio e l\u2019ottimizzazione del GC (ad es. per le JVM) in modo che i working set rimangano ben contenuti nella RAM; smorzo i modelli di allocazione aggressivi tramite il batching. Tengo d\u2019occhio anche gli artefatti di build e i simboli di debug, poich\u00e9 i residui trascurati comportano costi nascosti <strong>Memoria<\/strong> e aumentano il rischio di stallo in seguito.<\/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\/MemoryPressureLinuxKernel1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Funzionalit\u00e0 avanzate di Cgroups v2 e strategie OOM<\/h2>\n<p>Con Cgroups v2 separo chiaramente protezione, limitazione e limiti rigidi: <strong>memoria.bassa<\/strong> Riserva headroom per i servizi critici; il resto del reclaim viene assegnato ai gruppi meno importanti. <strong>memoria.alta<\/strong> in caso di superamento dei limiti, limita l'utilizzo in modo mirato e costringe le applicazioni a liberare memoria prima che il sistema ne risenta. <strong>memoria.max<\/strong> \u00e8 l'ultima linea di difesa: se viene superata, si verifica un OOM in un contesto controllato. Impostare <strong>PSI<\/strong> per ogni cgroup, in modo che gli allarmi scoccino proprio dove si verificano gli stalli; il PSI globale rimane stabile mentre un singolo servizio va in crash \u2013 \u00e8 proprio questo schema che voglio individuare. Insieme alle priorit\u00e0 OOM, stabilisco regole di sacrificio chiare: i worker batch non essenziali vengono terminati per primi, mentre le API di base mantengono la loro <strong>spazio libero<\/strong>.<\/p>\n\n<h2>Virtualizzazione: ballooning, KSM e overcommit<\/h2>\n<p>Negli ambienti virtualizzati mi trovo di fronte a una doppia pressione: l\u2019ospite vede una RAM apparentemente libera, mentre l\u2019hypervisor tramite <strong>Mongolfiera<\/strong> sottrae. Questa operazione aumenta i costi di reclaim per entrambe le parti. Misuro il PSI nell'ospite e lo metto in correlazione con le metriche dell'hypervisor; se il PSI aumenta durante gli eventi di ballooning, la VM necessita di maggiore capacit\u00e0 garantita o di politiche Cgroup pi\u00f9 efficaci nell'host. <strong>KSM<\/strong> Consente di risparmiare RAM grazie alla deduplicazione delle pagine identiche, ma comporta un carico sulla CPU; nelle configurazioni di hosting con molte VM simili pu\u00f2 essere vantaggioso, purch\u00e9 il carico aggiuntivo sulla CPU non comprometta gli SLO. Prevedo l\u2019overcommit (ad es. l\u2019assegnazione aggressiva di molte VM di piccole dimensioni) solo con riserve SLO fisse e una rigorosa <strong>memoria.bassa<\/strong> per sistemi in cui la latenza \u00e8 un fattore critico.<\/p>\n\n<h2>Scelte architetturali nell'hosting<\/h2>\n\n<p>Punto sulla distribuzione orizzontale, in modo che le singole istanze subiscano meno picchi di carico; i pool scalabili attenuano i picchi anomali e mantengono le latenze pi\u00f9 contenute. Distinguo chiaramente i ruoli: database, applicazioni e caching dispongono di pool di risorse dedicati, in modo che i processi di reclaim non generino effetti collaterali imprevisti oltre i confini del sistema. Scelgo lo storage tenendo conto della latenza di scrittura, poich\u00e9 i flush delle pagine sporche incidono direttamente sui tempi di risposta; un percorso veloce riduce sensibilmente i tempi di reclaim. Nei cluster prevedo riserve di RAM per ogni nodo e intervengo tramite politiche di scheduler, in modo che il carico e il consumo di memoria rimangano distribuiti in modo pi\u00f9 uniforme. Automatizzo il ridimensionamento con soglie PSI, in modo che l\u2019aumento dei valori \u201esome\u201c inneschi azioni prima che si verifichino brusche frenate e <strong>Uccidere<\/strong>-si verificano eventi.<\/p>\n\n<h2>Pianificazione della capacit\u00e0 e modelli di margine di manovra<\/h2>\n<p>Definisco l\u2019headroom in termini misurabili: mantengo riserve sufficienti affinch\u00e9 il valore \u201esome\u201c PSI rimanga al di sotto di soglie definite durante i picchi normali e il valore \u201efull\u201c non si verifichi praticamente mai. A tal fine utilizzo i percentili (ad es. il 99\u00b0 percentile del carico orario) e pianifico 10\u201330 % di RAM aggiuntiva a seconda della volatilit\u00e0 del carico di lavoro. Ai database vengono assegnate riserve fisse maggiori, mentre i front-end web scalano in modo pi\u00f9 dinamico. Calibro i tempi di rimbalzo: con quale rapidit\u00e0 scendono il PSI e si\/so dopo un picco? Se rimangono elevati, \u00e8 segno di riserve insufficienti o di una strategia di swap\/dirty inadeguata. In questo modo, la pianificazione della capacit\u00e0 diventa un processo continuo anzich\u00e9 una stima annuale.<\/p>\n\n<h2>Allarme e regolazione controllata da SLO<\/h2>\n<p>Collegher\u00f2 PSI agli SLO degli utenti: se \u201esome avg10\u201c aumenta contemporaneamente alle latenze dell\u2019API, interverr\u00f2. Classifico gli allarmi in \u201egiallo\u201c (persistente 2\u20133 % \u201esome\u201c, \u201efull\u201c vicino a 0) e \u201erosso\u201c (oltre 5 % \u201esome\u201c o \u201efull\u201c &gt; 0,1 %). Gli allarmi basati su cgroup aiutano a isolare la minoranza rumorosa. Inoltre, imposto allarmi per l\u2019aumento delle code dirty e dei tempi di attesa in scrittura, in modo da poter livellare tempestivamente le onde dirty. L\u2019obiettivo \u00e8 che le misure di ottimizzazione (swappiness, memory.high, dimensioni della cache) siano monitorabili e reversibili; implemento le modifiche gradualmente e confronto i dati \u00abprima\u00bb e \u00abdopo\u00bb utilizzando le stesse metriche.<\/p>\n\n<h2>Diagnosi passo dopo passo nella vita quotidiana<\/h2>\n\n<p>Per prima cosa controllo `free -h` e `MemAvailable`: se il valore cala in modo significativo, cerco le cache che possono essere liberate in modo sensato e i servizi con hotset in crescita. Successivamente eseguo `vmstat` a intervalli brevi per individuare eventuali tendenze; uno swapping prolungato conferma la pressione e mi conduce al percorso I\/O. Successivamente leggo \/proc\/pressure\/memory e valuto i valori \u201esome\u201c e \u201efull\u201c su intervalli di 10, 60 e 300 secondi; collego direttamente i valori medi in aumento alle latenze osservate. dmesg mi mostra tracce di OOM e rivela quali processi hanno recentemente causato o subito crisi di memoria; da ci\u00f2 deduco limiti e priorit\u00e0 per i Cgroup. Da tutto ci\u00f2 formulo un\u2019ipotesi, implemento piccoli interventi di ottimizzazione, verifico tramite PSI e mantengo la <strong>Tempo di risposta<\/strong> in sintesi.<\/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\/hosting-serverraum-4671.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Runbook e catene di cause tipiche<\/h2>\n<p>Ci sono alcuni schemi che mi capitano spesso:<\/p>\n<ul>\n  <li><strong>I processi di backup o di scansione sostituiscono la cache delle pagine<\/strong>: Improvvisamente i tassi di cache hit calano, il web e il database rallentano. Misura: limitare i job (priorit\u00e0 I\/O), spostare le finestre temporali, impostare `memory.high` per il cgroup dei job, proteggere il budget della cache di pagina dei servizi critici.<\/li>\n  <li><strong>Vulnerabilit\u00e0 nei processi worker<\/strong>: Aumento graduale della memoria anonima; il PSI \u201esome\u201c continua a salire nel corso delle ore. Misure da adottare: identificare la perdita di memoria, introdurre politiche di riavvio automatico e riciclaggio della memoria, impostare limiti di memoria affinch\u00e9 le perdite non mettano a rischio l\u2019intero host.<\/li>\n  <li><strong>Stalli causati dal THP<\/strong>: Il carico di kcompactd aumenta durante i picchi di traffico. Misura: impostare THP su \u201emadvise\u201c, adeguare i servizi interessati, verificare i parametri di compattazione, aumentare il margine di sicurezza.<\/li>\n  <li><strong>Stampa locale NUMA<\/strong>: Un socket va in thrash nonostante ci sia RAM libera a livello globale. Misura: correggere le affinit\u00e0, impostare l'interleave per carichi di lavoro molto distribuiti, regolare la distribuzione del carico nello scheduler.<\/li>\n  <li><strong>Swap su dischi lenti<\/strong>: se aumenta, i tempi di risposta salgono alle stelle. Misura: spostare lo swap su uno storage pi\u00f9 veloce, valutare zswap\/zram, ottimizzare lo swappiness e le politiche dei cgroup.<\/li>\n<\/ul>\n<p>Ogni runbook si conclude con una fase di convalida: i valori \u201esome\/full\u201c diminuiscono e le latenze si stabilizzano? Se la risposta \u00e8 no, significa che l\u2019ipotesi era errata o incompleta \u2013 in tal caso, continuo a iterare.<\/p>\n\n<h2>Strumenti e tracciamento durante il funzionamento<\/h2>\n<p>Oltre agli strumenti classici, mi affido a un\u2019analisi pi\u00f9 approfondita: osservo i rapporti tra cache di pagina e Anon, i tassi di page fault, i modelli di refault e le code di writeback. Gli approcci eBPF e di tracciamento mi indicano con precisione dove si verificano i tempi di attesa \u2013 ad esempio lungo i percorsi di reclaim, nel writeback o durante l\u2019allocazione di blocchi di grandi dimensioni. Per me \u00e8 importante disporre di una strumentazione leggera e adatta all\u2019ambiente di produzione: finestre di attivazione brevi, campionamento anzich\u00e9 monitoraggio continuo e una chiara correlazione con le metriche dell\u2019applicazione. In questo modo riesco a individuare le cause prima di procedere a modifiche su larga scala dei parametri.<\/p>\n\n<h2>Punti chiave e prossimi passi<\/h2>\n\n<p>Il termine \u201cmemory pressure\u201d descrive il tempo perso a causa della carenza di memoria, non solo della RAM occupata; lo misuro con PSI, individuo tempestivamente le tendenze e agisco sulla base dei dati. Chi analizza insieme MemAvailable, vmstat si\/so, PSI e dmesg, individua le vere cause dei picchi di latenza e del thrashing. Grazie all\u2019ottimizzazione di swappiness, dirty e cgroup, riduco in modo mirato i blocchi e garantisco ai servizi importanti il loro <strong>spazio libero<\/strong>. A livello di architettura, la distribuzione orizzontale, la chiara suddivisione dei ruoli e i percorsi di archiviazione veloci attenuano le conseguenze di ogni picco di carico. Alla fine, ci\u00f2 che conta \u00e8 che io colleghi continuamente la diagnosi alle contromisure: misurare, adeguare, misurare nuovamente \u2013 fino a quando le prestazioni e <strong>Stabilit\u00e0<\/strong> di nuovo a posto.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scopri in che modo la pressione sulla memoria nel kernel Linux influisce sulle prestazioni di hosting, come funzionano le metriche PSI e quali ottimizzazioni sono necessarie per la memoria del server.<\/p>","protected":false},"author":1,"featured_media":20205,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20212","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":"89","_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":"Memory Pressure","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":"20205","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20212","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=20212"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20212\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20205"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20212"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20212"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20212"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}