{"id":21443,"date":"2026-09-16T08:36:31","date_gmt":"2026-09-16T06:36:31","guid":{"rendered":"https:\/\/webhosting.de\/linux-numa-statistiken-auswerten\/"},"modified":"2026-09-16T08:36:31","modified_gmt":"2026-09-16T06:36:31","slug":"analisi-delle-statistiche-di-numa-su-linux","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/linux-numa-statistiken-auswerten\/","title":{"rendered":"Come interpretare correttamente le statistiche NUMA di Linux"},"content":{"rendered":"<p><strong>Linux NUMA<\/strong> Le statistiche mi mostrano in che misura i processi mantengono la memoria a livello locale e dove gli accessi remoti aumentano le latenze. Spiego come interpreto questi dati in modo mirato, valuto le tendenze nel tempo e ne ricavo chiare misure di ottimizzazione per <strong>Prestazioni<\/strong> derivare.<\/p>\n\n<h2>Punti centrali<\/h2>\n<ul>\n  <li><strong>Capire i contatori<\/strong>: numa_hit, numa_miss, numa_foreign, local_node, other_node, interleave_hit<\/li>\n  <li><strong>Valutare il contesto<\/strong>: profilo di carico, topologia, tipo di carico di lavoro<\/li>\n  <li><strong>Misurare le tendenze<\/strong>: Prima\/dopo e a intervalli<\/li>\n  <li><strong>Verificare i processi<\/strong>: A livello di sistema vs. per processo<\/li>\n  <li><strong>Applicare le modifiche<\/strong>: Affinit\u00e0, Politiche, Posizionamento<\/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\/09\/linux-numa-analyse-8293.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cosa rivelano realmente le statistiche NUMA<\/h2>\n\n<p>Interpreto i dati NUMA come una mappa per <strong>Posizione di stoccaggio<\/strong> e i percorsi dei dati. Un elevato <strong>numa_hit<\/strong> significa che le allocazioni sono state effettuate sul nodo desiderato. Al contrario, numa_miss indica che il kernel ha dovuto ricorrere a un altro nodo. Il contatore numa_foreign mostra la corrispondenza sul nodo di destinazione e completa il quadro. Con local_node e other_node posso capire se gli accessi sono rimasti locali o hanno utilizzato memoria remota.<\/p>\n\n<p>Questi valori non vanno mai interpretati isolatamente, perch\u00e9 <strong>Carichi di lavoro<\/strong> reagiscono in modo molto diverso. I processi brevi generano occasionalmente errori, senza modificare in modo percettibile le prestazioni complessive. Le politiche di interleave, invece, generano allocazioni intenzionalmente distribuite, il che fa aumentare il valore di interleave_hit. Verifico quindi sempre la politica prevista e il carico attuale. Solo allora decido se un valore richiede un intervento o se \u00e8 in linea con il progetto.<\/p>\n\n<p>Per me l'idea centrale \u00e8 questa: <strong>Contatore<\/strong> Forniscono segnali, non giudizi. Cerco modelli nel tempo, non singoli valori. In questo modo capisco se una modifica al sistema sposta la localit\u00e0. Solo sulla base di questo quadro di tendenza valuto se spostare i processi, adeguare le policy o impostare i vincoli di CPU. Ogni analisi NUMA parte quindi da una domanda chiara e da punti di misurazione ripetibili.<\/p>\n\n<h2>Interpretare i conteggi dei nuclei nel loro contesto<\/h2>\n\n<p>Faccio sempre dei confronti <strong>numa_hit<\/strong> e numa_miss insieme, invece di valutare i valori assoluti. Se i \u201cmiss\u201d aumentano, controllo parallelamente l\u2019andamento di numa_foreign sui potenziali nodi di destinazione. Se entrambi i valori coincidono, ci\u00f2 indica un vero e proprio spostamento e non un semplice artefatto di lettura. local_node e other_node completano questo quadro fornendo informazioni sugli accessi effettivi. In questo modo riesco a capire se un'allocazione \u00e8 iniziata a livello locale, ma l'operazione ha successivamente letto da una memoria pi\u00f9 distante.<\/p>\n\n<p>Un unico alto <strong>altro_nodo<\/strong> Non mi d\u00e0 fastidio se il carico di lavoro viene distribuito in modo mirato. I server web con molti worker, invece, traggono vantaggio da una localizzazione coerente. Per questo motivo esamino i singoli processi, non solo il quadro generale. Non appena singoli servizi escono dagli schemi, intervengo sulla loro collocazione. Solo quando aumentano gli errori a livello di sistema, cerco le cause nella topologia o nel carico di lavoro.<\/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\/09\/linux_numa_meeting_8326.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Confronti nel tempo: una routine di misurazione che d\u00e0 risultati concreti<\/h2>\n\n<p>Rilevo le letture dei contatori all'inizio e alla fine di un <strong>Fase finale<\/strong> e calcolo la differenza. I singoli valori nascondono gli effetti, mentre le differenze evidenziano l\u2019andamento. Intervalli ripetuti, ad esempio da 30 a 60 secondi, sono spesso sufficienti per individuare le tendenze. Dopo i deploy, gli aggiornamenti del kernel o le modifiche hardware, confronto nuovamente gli stessi intervalli. Se si verificano pi\u00f9 errori o se local_node si sposta, si tratta di un cambiamento reale.<\/p>\n\n<p>Tali serie temporali coprono <strong>Errore di posizionamento<\/strong> pi\u00f9 rapidamente rispetto alle istantanee. Metto in correlazione le linee con il carico della CPU, i cambi di contesto e l\u2019occupazione della memoria per ogni nodo. In questo modo riesco a capire se i colli di bottiglia nella RAM di un nodo causano movimenti di compensazione. Oppure se i nuovi processi alterano l\u2019equilibrio dei nodi. Il rapporto puro tra \u00abhit\u00bb e \u00abmiss\u00bb lo riporto sempre come andamento, non come singolo valore.<\/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\/09\/linux-numa-stat-analysis-4857.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Analizzare a livello di sistema, poi approfondire i processi<\/h2>\n\n<p>Comincio con una panoramica generale da <strong>numastat<\/strong> e solo dopo verifico i singoli processi. Questa sequenza fa risparmiare tempo, perch\u00e9 molti effetti diventano visibili a livello globale. Per la visione a livello di processo, utilizzo l\u2019output specifico del processo per isolare i servizi che destano sospetti. Non appena ho individuato i candidati, regolo il <strong>Posizionamento<\/strong> sull\u2019utilizzo della CPU e della memoria. Il contributo su questo argomento raccoglie alcuni consigli pratici <a href=\"https:\/\/webhosting.de\/it\/server-numa-localita-cpu-memoria-affinita-ottimizzazione-core\/\">Affinit\u00e0 della CPU e della memoria<\/a>.<\/p>\n\n<p>Soprattutto nel caso dei servizi Java, PHP-FPM o dei database, spesso \u00e8 sufficiente una corretta <strong>Affinit\u00e0<\/strong>, per ridurre significativamente gli errori. L\u2019orchestrazione dei container tende a mascherare questi problemi, poich\u00e9 gli scheduler distribuiscono le risorse senza tenere conto della struttura NUMA. Controllo quindi l\u2019assegnazione dei nodi per ogni pod o VM. Se i set di CPU e l\u2019assegnazione della RAM coincidono, il valore di `local_node` aumenta in modo misurabile. Alcuni problemi si risolvono non appena il processo viene eseguito in prossimit\u00e0 del set di dati richiesto.<\/p>\n\n<h2>Panoramica dei contatori NUMA (tabella)<\/h2>\n\n<p>Quando valuto un nuovo sistema, inserisco la tabella seguente in modo da poter esaminare ogni <strong>Figura chiave<\/strong> la classifichi rapidamente. Essa indica il significato, l\u2019interpretazione tipica e le possibili misure da adottare. Non la considero uno schema rigido, ma piuttosto una lista di controllo. Rimane fondamentale il confronto con il profilo di carico e la topologia del server. Solo in questo contesto posso prendere una decisione sensata.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Contatore<\/strong><\/th>\n      <th><strong>Significato<\/strong><\/th>\n      <th><strong>Interpretazione<\/strong><\/th>\n      <th><strong>Approccio<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>numa_hit<\/td>\n      <td>Allocazione nel nodo desiderato<\/td>\n      <td>Un valore elevato \u00e8 positivo<\/td>\n      <td>Mantenere la posizione<\/td>\n    <\/tr>\n    <tr>\n      <td>numa_miss<\/td>\n      <td>L'allocazione \u00e8 stata trasferita ad altri nodi<\/td>\n      <td>Maggiore rischio di ritardi<\/td>\n      <td>Verifica Affinity\/Policy<\/td>\n    <\/tr>\n    <tr>\n      <td>numa_foreign<\/td>\n      <td>Allocazione esterna su questo nodo<\/td>\n      <td>Controparte di numa_miss<\/td>\n      <td>Analizzare i nodi di destinazione<\/td>\n    <\/tr>\n    <tr>\n      <td>local_node<\/td>\n      <td>Accessi alla memoria locale<\/td>\n      <td>Pi\u00f9 in alto costa meno<\/td>\n      <td>Processo pi\u00f9 vicino alla RAM<\/td>\n    <\/tr>\n    <tr>\n      <td>altro_nodo<\/td>\n      <td>Accessi alla memoria remota<\/td>\n      <td>Solo discutibile, senza alcuna intenzione<\/td>\n      <td>Verifica topologia\/carico<\/td>\n    <\/tr>\n    <tr>\n      <td>interleave_hit<\/td>\n      <td>Risultati con distribuzione interleave<\/td>\n      <td>Previsto nella politica di interleave<\/td>\n      <td>Valutare l'uniformit\u00e0<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Con questo <strong>Panoramica<\/strong> Decido pi\u00f9 rapidamente quando intervenire. Un aumento di numa_miss senza variazioni spiegabili fa scattare un\u2019analisi delle cause. Se i valori di interleave_hit rimangono elevati, verifico se la policy \u00e8 attiva come previsto. Se other_node mostra un aumento senza un corrispondente aumento del carico, controllo la presenza di carichi di lavoro che potrebbero essere in competizione. In questo modo, la tabella diventa il punto di partenza per interventi mirati.<\/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\/09\/NUMA_Statistik_Auswertung_1023.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comprendere e utilizzare la topologia NUMA<\/h2>\n\n<p>Prima di effettuare la messa a punto, controllo il <strong>Topologia<\/strong> del server: socket, core, canali di memoria, percorsi di latenza. Se un processo viene eseguito sul socket 0, ma i record di lavoro si trovano sul socket 1, il tempo di accesso aumenta. Ci\u00f2 riduce la larghezza di banda e fa variare i tempi di risposta. I servizi particolarmente esigenti in termini di memoria risentono di ogni distanza superflua. Pertanto, assegno i processi ad alta intensit\u00e0 di dati a nodi con RAM libera sufficiente.<\/p>\n\n<p>Asimmetriche <strong>Collegamenti<\/strong> Gli effetti si amplificano, ad esempio quando un nodo utilizza un numero inferiore di canali. In questi casi, sposto in modo mirato i dati memorizzati nella cache, invece di distribuire il processo. Configuro gli host delle VM e dei container in modo tale che ogni istanza mantenga un collegamento coerente con il nodo. In questo modo riduco il traffico dati remoto senza limitare le quote. Sono i limiti fisici della macchina a dettare le regole, e io mi attengo a esse.<\/p>\n\n<h2>Comprendere correttamente i concetti di interleave e balancing<\/h2>\n\n<p>Le politiche di interleave distribuiscono intenzionalmente la memoria tra i nodi in modo che <strong>Produttivit\u00e0<\/strong> aumenta per ogni processo oppure gli hotspot diminuiscono. In questa configurazione, valori elevati di interleave_hit sono considerati desiderabili. In questo caso verifico soprattutto l'uniformit\u00e0, non la localit\u00e0 assoluta. L'AutoNUMA o il bilanciamento NUMA possono essere d'aiuto, ma non in ogni situazione.<\/p>\n\n<p>Decido a seconda della situazione se utilizzare la funzione automatica <strong>Bilanciamento<\/strong> rimane attivo. Per i servizi costanti e di lunga durata, tendo a impostare collegamenti fissi. In caso di carichi variabili, AutoNUMA pu\u00f2 reagire in modo adeguato. Una buona panoramica dei vantaggi e dei rischi \u00e8 disponibile nell'articolo <a href=\"https:\/\/webhosting.de\/it\/disattivare-o-mantenere-attivo-il-bilanciamento-numa-per-ottenere-prestazioni-ottimali-su-linux\/\">Bilanciamento NUMA<\/a>. Solo quando l\u2019obiettivo e il contesto sono chiari, scelgo la modalit\u00e0 pi\u00f9 adatta.<\/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\/09\/NUMA_Statistik_Auswertung_1023.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Modelli di carico di lavoro: database, macchine virtuali, servizi web<\/h2>\n\n<p>I database sono sensibili a <strong>Latenza<\/strong> tra CPU e RAM. Per questo motivo mantengo l\u2019istanza, la cache del buffer e gli shard attivi sullo stesso nodo. Le macchine virtuali traggono vantaggio da set di CPU ben definiti e dalla RAM del nodo, in modo che i sistemi operativi ospiti vedano percorsi coerenti. I servizi web con molti worker danno il meglio di s\u00e9 quando i gruppi di worker rimangono associati a un singolo nodo. Per la strategia di archiviazione, a seconda dei casi, utilizzo misure mirate <a href=\"https:\/\/webhosting.de\/it\/politiche-di-memoria-numa-ottimizzazione-dei-server-di-database-server\/\">Politiche di memoria NUMA<\/a>.<\/p>\n\n<p>Per quanto riguarda invece i lavori analitici e le scansioni di grandi dimensioni, li svolgo in parte <strong>distribuito<\/strong> . In questo caso, l\u2019interleave offre spesso una larghezza di banda migliore rispetto alla localit\u00e0 rigida. \u00c8 fondamentale analizzare con obiettivit\u00e0 i modelli di I\/O del carico di lavoro. La scrittura prevale rispetto alla lettura, cos\u00ec come gli accessi casuali prevalgono su quelli sequenziali. Scelgo la politica che si adatta al modello di accesso, non quella che sembra pi\u00f9 appropriata nei libri di testo.<\/p>\n\n<h2>Procedura di misurazione pratica e strumenti<\/h2>\n\n<p>Per iniziare mi bastano <strong>numastat<\/strong> e la vista del processo. Registro le letture dei contatori con data, PID e indicatori di carico. \u00c8 importante effettuare le misurazioni in intervalli di tempo identici. In questo modo \u00e8 possibile rappresentare chiaramente le differenze tra la situazione precedente e quella successiva. Nei periodi di produzione, annoto le variazioni e le metto in correlazione con le date di rilascio.<\/p>\n\n<p>In caso di anomalie <strong>Servizi<\/strong> Verifico inoltre l'utilizzo della CPU e la visualizzazione dei nodi con strumenti come lscpu, numactl e perf per monitorare il carico remoto. Per ogni ciclo di misurazione documento la politica scelta. Dopo ogni modifica, ripeto la misurazione. Solo quando le linee di tendenza si stabilizzano, valuto l\u2019effetto come positivo. Il cambio cieco delle impostazioni porta facilmente a miglioramenti apparenti.<\/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\/09\/linux_numa_auswertung_7463.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Evitare le interpretazioni errate pi\u00f9 comuni<\/h2>\n\n<p>Un alto <strong>interleave_hit<\/strong> Non \u00e8 un errore se l\u2019interleave \u00e8 attivamente previsto. Allo stesso modo, un singolo errore \u00e8 trascurabile in presenza di una durata prolungata. Verifico sempre la densit\u00e0 e la distribuzione sull\u2019intervallo, non solo i picchi. Alcuni interpretano \u00abother_node\u00bb come un dato generalmente negativo e trascurano la natura del carico di lavoro. Per questo motivo, esamino prima l\u2019obiettivo di progettazione e poi valuto i numeri.<\/p>\n\n<p>Un altro errore: <strong>Vista d'insieme<\/strong> Bene, cos\u00ec va tutto bene. Spesso i valori anomali si nascondono solo in alcuni PID. Oppure gli scheduler dei container distribuiscono i pod su pi\u00f9 nodi, anche se sarebbe pi\u00f9 sensato raggrupparli localmente. Mi accorgo di questi effetti solo quando effettuo misurazioni per singolo processo. Senza questo livello di dettaglio, l\u2019analisi rimane incompleta.<\/p>\n\n<h2>Passaggi di messa a punto efficaci<\/h2>\n\n<p>Inizio con <strong>Posizionamento<\/strong>: Processi sui nodi in cui si trovano o dovrebbero trovarsi i dati. Quindi imposto l\u2019affinit\u00e0 della CPU affinch\u00e9 i thread non saltino da un socket all\u2019altro. Segue l\u2019assegnazione della memoria, in modo che il kernel effettui l\u2019allocazione nella posizione desiderata. Per i carichi variabili, valuto le politiche e, se opportuno, utilizzo AutoNUMA.<\/p>\n\n<p>Successivamente mi occuper\u00f2 di <strong>Coerenza<\/strong> Nel ciclo di vita: i riavvii, i deploy e le operazioni di scalabilit\u00e0 non devono modificare casualmente i riferimenti ai nodi. Documento i collegamenti nel codice, in modo che rimangano riproducibili. Successivamente, effettuo una nuova misurazione, valuto le variazioni e decido se procedere con una messa a punto. Ogni modifica merita una chiara prova misurabile.<\/p>\n\n<h2>Esempio pratico: da fiasco a successo<\/h2>\n\n<p>Supponiamo che una <strong>Banca dati<\/strong> mostra, sotto carico, un valore pi\u00f9 elevato di numa_miss e un aumento di other_node. La latenza delle query oscilla maggiormente. Controllo innanzitutto l\u2019assegnazione dei processi e constato che, dopo un rollout, il servizio gira sul nodo A, mentre la cache \u00e8 stata allocata sul nodo B. Dopo aver fissato l\u2019assegnazione della CPU e della memoria al nodo B, il rapporto si inverte: numa_hit aumenta, mentre i miss diminuiscono. I tempi di risposta diventano pi\u00f9 costanti e il carico della CPU diminuisce leggermente, poich\u00e9 vengono eliminati gli accessi remoti.<\/p>\n\n<p>Nel frattempo, controllo la <strong>Politica<\/strong>. La funzione Interleave era attiva involontariamente e ha distribuito le allocazioni. Dopo il passaggio al nodo preferito, la cache rimane chiusa a livello locale. Dopo un\u2019ora di misurazione, i delta confermano il miglioramento. Solo allora considero la messa a punto un successo. Senza questa verifica incrociata, un\u2019istantanea avrebbe potuto trarre in inganno.<\/p>\n\n<h2>Metriche e valori di riferimento per la pratica<\/h2>\n\n<p>Per prendere decisioni mi affido a dati affidabili <strong>Probabilit\u00e0<\/strong> anzich\u00e9 singoli valori grezzi. Per ogni processo calcolo il tasso di allocazione local_alloc = numa_hit \/ (numa_hit + numa_miss). Inoltre, valuto il <strong>Tasso di accesso<\/strong> calcolo local_access = local_node \/ (local_node + other_node). Questi due valori insieme indicano se la memoria rimane utilizzata localmente anche dopo l\u2019allocazione. Come valori di riferimento approssimativi, mi attengo a quanto segue: per i servizi in cui la latenza \u00e8 critica, punto a accessi remoti inferiori a 5\u201310 %. Per i carichi di lavoro analitici legati alla larghezza di banda, tollero valori compresi tra 20 e 30 %, a condizione che la velocit\u00e0 di trasmissione aumenti. Il fattore decisivo \u00e8 la <strong>Stabilit\u00e0<\/strong> nel tempo. Preferisco un valore che rimanga stabilmente costante sotto carico piuttosto che un breve picco con valori perfetti. Documento questi intervalli target per ogni intervento di manutenzione, in modo che le misurazioni successive possano essere chiaramente classificate.<\/p>\n\n<h2>Cgroups, container e le insidie dello scheduler<\/h2>\n\n<p>Negli ambienti container, per prima cosa controllo il <strong>cpuset<\/strong>\u2011Assegnazione: set di CPU e <em>cpuset.mems<\/em> devono mappare lo stesso spazio di nodo, altrimenti si verificano inevitabilmente errori. Mi assicuro che i pod con richieste CPU fisse non vengano distribuiti su pi\u00f9 nodi NUMA e che lo scheduler non distribuisca i worker della stessa applicazione su pi\u00f9 nodi. Per i tipi burst, limito il numero massimo di thread per pod in modo che rimangano all\u2019interno di un singolo nodo. Documento il <strong>Dominio NUMA<\/strong> per ogni distribuzione e richiedo repliche coerenti (un gruppo di worker per nodo, non mezzi gruppi distribuiti su due nodi). Se calcolo al minimo lo spazio di archiviazione per ogni pod, mi creo una pressione indesiderata: un leggero margine per ogni nodo impedisce al kernel di dover ricorrere prematuramente a nodi esterni. Se i container vengono riavviati frequentemente, faccio attenzione al binding deterministico, in modo che <strong>Avviamenti a freddo<\/strong> non ricevere per caso una sede peggiore.<\/p>\n\n<h2>Allineamento coerente delle macchine virtuali e dei vNUMA<\/h2>\n\n<p>Per quanto riguarda le macchine virtuali, la mia attenzione si concentra su <strong>vNUMA<\/strong>: La topologia virtuale deve corrispondere a quella fisica. Assegno le vCPU in modo tale che ogni nodo vNUMA corrisponda esattamente a un nodo NUMA fisico. A livello di host, assegno i thread di QEMU\/hypervisor a questo dominio e mi assicuro che la RAM assegnata provenga interamente da quel nodo. <strong>Mongolfiera<\/strong> E accetto con cautela l\u2019overcommit per le VM in cui la latenza \u00e8 critica; un ballooning aggressivo pu\u00f2 spingere gli hotset fuori dal nodo e far aumentare gli accessi remoti. In caso di migrazione live, dopo lo spostamento verifico nuovamente i collegamenti: in alcuni ambienti, infatti, si perdono le impostazioni precise relative alla CPU e alla memoria. Solo quando l\u2019allineamento vNUMA \u00e8 corretto, valuto numastat a livello di sistema: altrimenti mi limito a risolvere i sintomi, non la causa.<\/p>\n\n<h2>THP, Hugepages e migrazione delle pagine<\/h2>\n\n<p><strong>Pagine trasparenti di grandi dimensioni<\/strong> (THP) possono essere sia d\u2019aiuto che d\u2019intralcio. Le pagine pi\u00f9 grandi riducono i TLB miss e migliorano la larghezza di banda, ma se il kernel attiva le Hugepages solo in una fase avanzata <em>crollato<\/em> oppure migrati, possono risultare inadeguati <strong>Distanze a lunga distanza<\/strong> nascono. Mi attengo a due regole: in primo luogo, la <strong>Politica<\/strong> definire chiaramente (ad es. nodo preferito) e, per quanto possibile, impostare fin dall\u2019inizio allocazioni locali di grandi dimensioni. In secondo luogo, per i carichi di lavoro con cache fisse e di grandi dimensioni, impiego, se possibile, Hugepages statiche (hugetlb) che riservo esplicitamente su un nodo. Ci\u00f2 riduce la frammentazione e i movimenti di compensazione. Se osservo nelle serie temporali che, dopo un periodo di esecuzione prolungato, il <em>altro_nodo<\/em>- Se la quota aumenta, verifico se <strong>Migrazione delle pagine<\/strong> o se si verifica una compattazione e se le impostazioni THP corrispondono al modello. Per me \u00e8 importante non disattivare o attivare l'opzione a livello globale: prendo una decisione per ogni servizio e ne valuto l'effetto in termini di localit\u00e0 e latenza.<\/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\/09\/linux-numa-analyse-4746.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Come interpretare correttamente i termini \u201cReclaim\u201d, \u201cSwap\u201d e \u201cMemory-Pressure\u201d<\/h2>\n\n<p>Se le miss salgono senza un evidente cambiamento di posizione, cerco <strong>pressione di accumulo<\/strong> per nodo. I nodi pieni costringono il kernel a eseguire operazioni di recupero dello spazio e compattazione, in parte innescate da <em>kswapd<\/em> su un altro nodo \u2013 ci\u00f2 provoca effetti collaterali sui contatori. Verifico per ogni nodo la memoria libera e il carico della cache di pagina. Attivato <strong>Scambio<\/strong> pu\u00f2 sostituire gli hot set e far aumentare vertiginosamente le latenze; per i servizi particolarmente sensibili, disattivo lo swap o lo limito rigorosamente. Nei log e nelle viste perf cerco i picchi di reclaim durante i picchi di carico. L\u2019obiettivo \u00e8 avere spazio libero sufficiente, <strong>locali<\/strong> Mantenere la RAM sul nodo di destinazione, in modo che le allocazioni non vadano perse. Se per farlo \u00e8 necessario ridurre le cache, do la priorit\u00e0 al set di lavoro del servizio rispetto alla cache di pagina generica.<\/p>\n\n<h2>Comandi pratici e analisi dei risultati<\/h2>\n\n<p>Per la visualizzazione del processo utilizzo <code>numastat -p<\/code> e aggiungo: <code>cat \/proc\/\/numa_maps<\/code>, per visualizzare le allocazioni per area (anonime, basate su file) e per nodo. <code>numactl --hardware<\/code> mi fornisce le matrici di latenza e le dimensioni dei nodi, <code>lscpu --extended<\/code> mostra l'assegnazione della CPU ai nodi. Per gli accessi alla memoria incentrati sui percorsi remoti, imposto <code>memoria perf<\/code> per verificare i modelli di carico. Raccolgo i delta in modo riproducibile, ad esempio:<\/p>\n\n<p><em>Routine di misurazione<\/em><\/p>\n<ul>\n  <li>t0: eseguire il backup di numastat (completo) e numastat -p per i PID principali<\/li>\n  <li>30\u201360 s di esercizio con carico, fase di carico identica<\/li>\n  <li>t1: rileggere numastat, calcolare i delta per ogni contatore<\/li>\n  <li>Registrazione dei valori della CPU parallela, dei cambi di contesto e della memoria dei nodi<\/li>\n<\/ul>\n\n<p>Successivamente calcolo il <strong>Probabilit\u00e0<\/strong> e evidenzio quali processi si discostano in modo significativo dalle tendenze a livello di sistema. Laddove permangono incertezze, ripeto la misurazione almeno tre volte. Solo i delta coerenti li considero affidabili. Per un monitoraggio continuo, mappo i contatori su serie temporali e li collego ai metadati delle versioni \u2013 in questo modo riesco a individuare <strong>Punti di regressione<\/strong> immediatamente.<\/p>\n\n<h2>Lista di controllo per un\u2019ottimizzazione NUMA ben strutturata<\/h2>\n\n<ul>\n  <li>Definire l'obiettivo: latenza vs. throughput, carico fisso vs. variabile<\/li>\n  <li>Acquisizione della topologia: nodi, latenze, riserve di RAM libere per nodo<\/li>\n  <li>Misurare i valori di riferimento: numastat complessivo e per processo, ricavare i rapporti<\/li>\n  <li>Correzione dell'allocazione: affinit\u00e0 CPU, associazione della memoria, criteri<\/li>\n  <li>Configurazione dei container\/VM: cpuset.cpus = nodi, cpuset.mems adeguato; mappatura corretta di vNUMA<\/li>\n  <li>Scegliere consapevolmente THP\/Hugepages, tenendo d\u2019occhio la frammentazione<\/li>\n  <li>Ridurre la pressione sulla memoria: verificare l\u2019headroom per ogni nodo e la strategia di swap<\/li>\n  <li>Verifica successiva: confrontare i delta, garantire la stabilit\u00e0 nel tempo<\/li>\n  <li>Documentazione: collegamenti come codice, note di rilascio con contesto NUMA<\/li>\n<\/ul>\n\n<h2>Riassumendo brevemente<\/h2>\n\n<p>Analizzo i dati NUMA utilizzando <strong>Segnali<\/strong> A questo proposito, si veda: coppie di contatori, andamenti temporali e visione del processo. I valori chiave numa_hit, numa_miss, numa_foreign, local_node, other_node e interleave_hit mi indicano la localit\u00e0, i movimenti di deviazione e le strategie di distribuzione. Prendo le mie decisioni in base alla topologia e al carico di lavoro, non in base a valori limite rigidi. L\u2019ottimizzazione inizia con il posizionamento, l\u2019affinit\u00e0, una politica adeguata e una routine di misurazione accurata. In questo modo garantisco prestazioni costanti <strong>Prestazioni<\/strong>, poich\u00e9 la CPU e la RAM sono adeguate all'applicazione e i trasferimenti di dati su lunghe distanze sono rari.<\/p>","protected":false},"excerpt":{"rendered":"<p>Analizzare correttamente le statistiche NUMA di Linux: comprendere le statistiche NUMA, verificare la localit\u00e0 della memoria e migliorare in modo mirato le prestazioni del server.<\/p>","protected":false},"author":1,"featured_media":21436,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21443","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":"63","_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":"Linux NUMA","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":"21436","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21443","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=21443"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21443\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21436"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21443"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21443"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21443"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}