{"id":21103,"date":"2026-08-28T11:49:48","date_gmt":"2026-08-28T09:49:48","guid":{"rendered":"https:\/\/webhosting.de\/numa-balancing-deaktivieren-oder-aktiv-lassen-linux-performance-optimal\/"},"modified":"2026-08-28T11:49:48","modified_gmt":"2026-08-28T09:49:48","slug":"disattivare-o-mantenere-attivo-il-bilanciamento-numa-per-ottenere-prestazioni-ottimali-su-linux","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/numa-balancing-deaktivieren-oder-aktiv-lassen-linux-performance-optimal\/","title":{"rendered":"Bilanciamento NUMA in Linux: disattivarlo o lasciarlo attivo?"},"content":{"rendered":"<p>Il bilanciamento NUMA in Linux determina se il <strong>Kernel<\/strong> Se gli accessi alla memoria vengono localizzati automaticamente o se sono io a controllarne il posizionamento in modo mirato. In questa guida vi mostrer\u00f2 quando lasciare attivo il \"numa balancing\" e quando disattivarlo per <strong>Latenza<\/strong>-Disattiva la sicurezza.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>Automatico<\/strong> \u00c8 utile in presenza di carichi di lavoro misti senza ottimizzazione NUMA.<\/li>\n  <li><strong>Disattivare<\/strong> in caso di pinning, policy statiche o latenza elevata.<\/li>\n  <li><strong>Spese generali<\/strong> \u00e8 il risultato di scansioni, errori e migrazioni.<\/li>\n  <li><strong>Configurazione<\/strong> controllare tramite sysctl o parametri di avvio.<\/li>\n  <li><strong>Test<\/strong> e misurare invece di tirare a indovinare, poi decidere.<\/li>\n<\/ul>\n\n<h2>NUMA in breve: latenze e localit\u00e0<\/h2>\n\n<p>Nei sistemi NUMA, l'hardware organizza la memoria in diversi nodi, i singoli <strong>CPU<\/strong> si trovano geograficamente vicini. Gli accessi locali richiedono meno tempo rispetto a quelli a distanza, cosa che ho notato immediatamente <strong>Latenza<\/strong> e la larghezza di banda. Se un processo \u00e8 in esecuzione su un nodo, ma i dati si trovano su un altro, perdo preziosi microsecondi per ogni accesso. \u00c8 proprio in questo punto che interviene il kernel per ottimizzare la <strong>Localit\u00e0<\/strong> in termini di pagine. Chi comprende l\u2019idea di base se ne rende subito conto: la vicinanza tra i nuclei di calcolo e i dati \u00e8 la via diretta per ottenere una <strong>Prestazioni<\/strong>.<\/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\/linux-numa-balancing-2345.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Come funziona il bilanciamento automatico NUMA<\/h2>\n\n<p>Il kernel monitora da quali nuclei un processo accede alle pagine e interviene in modo mirato <strong>Suggerimento<\/strong>-Faults. In questo modo, il sistema individua quale nodo registra un numero maggiore di accessi e trasferisce quindi le pagine corrispondenti su quel nodo. Queste migrazioni riducono gli accessi da remoto e aumentano la velocit\u00e0 locale <strong>Tasso di successo<\/strong>. Ne noto l'effetto soprattutto nei carichi di lavoro dinamici, in cui i thread si spostano e la memoria cambia posizione. Chi desidera approfondire l'argomento pu\u00f2 esaminare le relazioni tra la vicinanza della CPU e della memoria tramite <a href=\"https:\/\/webhosting.de\/it\/server-numa-localita-cpu-memoria-affinita-ottimizzazione-core\/\">Affinit\u00e0 CPU\/memoria<\/a> comprendere in modo pratico.<\/p>\n\n<h2>Quando lasciarlo attivo: carichi di lavoro tipici<\/h2>\n\n<p>Lascio la funzione attiva quando le applicazioni non dispongono di una propria logica NUMA e i processi spesso <strong>cambiamento<\/strong>. Tra i candidati pi\u00f9 comuni figurano i server applicativi, i database con carico variabile e gli host con molti <strong>contenitori<\/strong>. In configurazioni di questo tipo, il sistema automatico avvicina le pagine e i thread senza che io debba fissarli manualmente. Soprattutto sugli host multi-socket, la percentuale di accessi locali aumenta in modo tangibile. Per gli amministratori con servizi eterogenei, ci\u00f2 rappresenta un buon <strong>Compromesso<\/strong> in termini di tempo e impegno.<\/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\/numa_balancing_linux_5843.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quando disattivare: criteri chiari<\/h2>\n\n<p>Disattivo il pilota automatico non appena mi accorgo di aver perso il controllo o di essere in difficolt\u00e0 <strong>Politiche<\/strong> impostare. Se utilizzo numactl, cgroups o MPOL_BIND\/MPOL_PREFERRED, esiste gi\u00e0 una scelta definitiva riguardo ai percorsi di memoria. In tal caso, gli hint fault e le migrazioni generano un inutile <strong>Spese generali<\/strong>. Lo stesso vale per gli scenari in tempo reale o di HFT, in cui ogni microsecondo conta e la prevedibilit\u00e0 \u00e8 una priorit\u00e0. Chi approfondisce la scelta delle regole di collocamento trarr\u00e0 vantaggio da un\u2019analisi delle opzioni pi\u00f9 adatte <a href=\"https:\/\/webhosting.de\/it\/politiche-di-memoria-numa-ottimizzazione-dei-server-di-database-server\/\">Politiche di memoria<\/a>.<\/p>\n\n<h2>Comprendere e misurare l'overhead<\/h2>\n\n<p>Il bilanciamento automatico comporta del lavoro: scansioni, <strong>Errori<\/strong> e le migrazioni tra pagine richiedono tempo di CPU. Ci\u00f2 passa quasi inosservato quando gli accessi remoti diminuiscono drasticamente, ma non vale quasi la pena se il layout \u00e8 gi\u00e0 locale. Verifico quindi sempre l\u2019effetto effettivo con numastat, perf e metriche significative <strong>Parametri di riferimento<\/strong>. Ci\u00f2 che interessa \u00e8 l'andamento nel corso dei minuti, non solo un breve picco. Solo quando i valori misurati indicano in modo costante che gli accessi locali aumentano e le latenze diminuiscono, mantengo quella modalit\u00e0.<\/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\/numa-balancing-decision-linux-4539.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configurazione: Sysctl e parametri di avvio<\/h2>\n\n<p>Controllo lo stato tramite \/proc o Sysctl e, se necessario, lo modifico immediatamente, senza un <strong>Riavvio<\/strong>. Per i test bastano semplici comandi come quelli riportati di seguito, che eseguo nella console. In modo permanente, imposto il valore in un file sysctl, in modo che rimanga invariato dopo un riavvio. Chi preferisce impostarlo gi\u00e0 all\u2019avvio, utilizza il parametro del kernel numa_balancing=enable oppure <strong>disabilita<\/strong>. Documento ogni modifica e annoto in quale fase del carico di lavoro l'ho effettuata.<\/p>\n\n<pre><code>cat \/proc\/sys\/kernel\/numa_balancing\necho 0 &gt; \/proc\/sys\/kernel\/numa_balancing\nsysctl -w kernel.numa_balancing=1\n# \/etc\/sysctl.d\/90-numa.conf\n# kernel.numa_balancing = 0\n<\/code><\/pre>\n\n<h2>Scenari relativi ai container e alla virtualizzazione<\/h2>\n\n<p>Sugli host con molte macchine virtuali e container, l'automatizzazione <strong>Localizzazione<\/strong> spesso mettono in evidenza i loro punti di forza. I processi si avviano e terminano, i Cgroups ridistribuiscono il carico e il kernel mantiene la memoria pi\u00f9 vicina ai nuclei attivi. Lo noto soprattutto su grandi server multi-socket con diversi <strong>Nodi<\/strong>. Distinguo chiaramente i casi particolari in cui \u00e8 richiesto un pinning rigido di singole istanze e in tali casi disattivo in modo mirato la funzione automatica. Per una classificazione pi\u00f9 approfondita, \u00e8 utile dare un\u2019occhiata agli esempi pratici <a href=\"https:\/\/webhosting.de\/it\/numa-bilanciamento-dei-server-ottimizzazione-della-memoria-hardware-numaflux\/\">Ottimizzazione NUMA<\/a> in modalit\u00e0 host.<\/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\/numa_balancing_linux_5823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Tabella decisionale per la pratica<\/h2>\n\n<p>La seguente panoramica riassume gli scenari tipici, l'effetto atteso e la mia chiara <strong>Raccomandazione<\/strong>. Li uso come punto di partenza, ma non li sostituisco mai con i valori misurati sul sistema reale. Ogni ambiente presenta delle peculiarit\u00e0, e prendo decisioni solo dopo aver ottenuto risultati riproducibili <strong>Risultati<\/strong> sicuro. Chi procede in modo sistematico risparmia tempo in seguito nella ricerca degli errori e nella messa a punto. Effettuare piccoli test prima di un lancio si rivela quasi sempre utile in <strong>Costanza<\/strong> e la prevedibilit\u00e0.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Scenario<\/th>\n      <th>Effetto tipico<\/th>\n      <th>Il mio consiglio<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Carichi di lavoro standard senza ottimizzazione NUMA<\/td>\n      <td>Pi\u00f9 accessi locali, meno accessi da lontano <strong>Letture<\/strong><\/td>\n      <td>Lasciare attivo<\/td>\n    <\/tr>\n    <tr>\n      <td>Banche dati con carico variabile<\/td>\n      <td>Localizzazione dinamica delle pagine, moderata <strong>Scansioni<\/strong><\/td>\n      <td>Lasciare attivo, testare<\/td>\n    <\/tr>\n    <tr>\n      <td>Trading in tempo reale o HFT<\/td>\n      <td>La latenza Hint-Fault \u00e8 un problema <strong>Jitter<\/strong>-Obiettivi<\/td>\n      <td>Disattiva, fissa manualmente<\/td>\n    <\/tr>\n    <tr>\n      <td>Fissaggio manuale tramite numactl\/cgroups<\/td>\n      <td>Il sistema automatico entra in collisione con gli elementi fissi <strong>Politiche<\/strong><\/td>\n      <td>Disattivare<\/td>\n    <\/tr>\n    <tr>\n      <td>Politiche di memoria statiche (MPOL_BIND, ecc.)<\/td>\n      <td>Le migrazioni non apportano alcun reale <strong>Vantaggio<\/strong><\/td>\n      <td>Disattivare<\/td>\n    <\/tr>\n    <tr>\n      <td>Ambiente di test\/analisi<\/td>\n      <td>Buona visibilit\u00e0 sulla localit\u00e0 e <strong>Effetti<\/strong><\/td>\n      <td>Lasciare attivo, verificare le varianti<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Linee guida per i test e la convalida<\/h2>\n\n<p>Inizio con il Balancer attivato e registro i dati locali rispetto a quelli remoti <strong>Accessi<\/strong> tramite Numastat. Successivamente disattivo la funzione e ripeto le misurazioni in modo identico. Valuto le differenze non solo in termini di valori medi, ma anche in <strong>Percentili<\/strong>. I test di regressione con profili di carico provenienti dalla produzione forniscono i risultati pi\u00f9 affidabili. Solo allora prendo la decisione definitiva in merito a host, VM o un determinato <strong>Servizio<\/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\/devdesk_linux_numa_bal_7283.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ostacoli comuni e miti<\/h2>\n\n<p>Un errore comune \u00e8 quello di ritenere che il sistema automatico sostituisca ogni <strong>Appuntatura<\/strong>. Non \u00e8 vero, perch\u00e9 i budget di latenza rigidi non tollerano quasi nessun errore aggiuntivo. Altrettanto errata \u00e8 l\u2019ipotesi secondo cui le migrazioni siano sempre <strong>gratuito<\/strong> accadere. Soprattutto nel caso di layout gi\u00e0 di per s\u00e9 locali, il sovraccarico ha pi\u00f9 spesso un effetto negativo che positivo. Chi evita i miti e effettua misurazioni accurate, prende decisioni con un livello di <strong>Precisione<\/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-numa-balancing-8192.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Limiti dell'automatismo e interazioni<\/h2>\n\n<p>AutoNUMA ha un forte impatto sulle pagine anonime allocate autonomamente da un processo. Tuttavia, non tutto pu\u00f2 essere migrato in modo sensato. Le pagine fissate (mlock), la memoria DMA\/dispositivo, le aree registrate DAX o RDMA rimangono dove sono. Anche le pagine condivise (ad es. librerie altamente condivise o la cache di pagina) offrono solo benefici limitati dalla migrazione, poich\u00e9 pi\u00f9 processi competono per l\u2019accesso <strong>Modello di accesso<\/strong> produrre. Inoltre, tengo conto dei costi di <strong>Pagine trasparenti di grandi dimensioni<\/strong> (THP): la loro migrazione \u00e8 pi\u00f9 costosa rispetto alle pagine da 4 KiB e pu\u00f2 causare picchi di carico. Chi persegue obiettivi di latenza rigorosi spesso combina THP=never o madvise con il bilanciamento disattivato e il pinning pulito, per evitare sorprese.<\/p>\n\n<p>Un altro aspetto \u00e8 l\u2019interazione con lo scheduler della CPU. Lo scheduler cerca di collocare i thread dove si trovano i loro dati, mentre il bilanciatore sposta i dati dove sono in esecuzione i thread. I due meccanismi si completano a vicenda, ma in caso di carico instabile possono causare temporaneamente <strong>Oscillazioni<\/strong> portare. In pratica, gli intervalli di scansione attenuano questi effetti; chi riscontra profili di carico estremamente instabili pu\u00f2 stabilizzare la situazione utilizzando periodi di scansione pi\u00f9 lunghi o un thread pinning pi\u00f9 stabile.<\/p>\n\n<h2>Messa a punto dei parametri di scansione<\/h2>\n\n<p>Oltre all'opzione globale, esistono dei parametri del kernel che mi consentono di regolare con precisione l'aggressivit\u00e0 del sistema automatico. I nomi esatti possono variare leggermente a seconda della versione del kernel, ma lo scopo rimane lo stesso:<\/p>\n\n<ul>\n  <li>kernel.numa_balancing_scan_delay_ms: tempo di attesa dopo l'avvio, un 'fork' o un 'exec' prima che inizi la prima scansione.<\/li>\n  <li>kernel.numa_balancing_scan_period_min_ms \/ _max_ms: limite minimo e massimo della frequenza di scansione per ogni intervallo di indirizzi di processo.<\/li>\n  <li>kernel.numa_balancing_rate_limit_mb: limite massimo per intervallo di tempo per le migrazioni di pagine, al fine di preservare la larghezza di banda della memoria.<\/li>\n  <li>kernel.numa_balancing_scan_size_mb: quantit\u00e0 di memoria contrassegnata per ogni ciclo di scansione (se disponibile).<\/li>\n<\/ul>\n\n<p>In configurazioni in cui la latenza \u00e8 fondamentale, per prudenza aumento i periodi minimi e massimi e riduco i limiti di frequenza, invece di disattivare immediatamente la funzione automatica. Questo spesso offre un buon compromesso: meno errori di hint, meno migrazioni, ma una reazione comunque sufficiente in caso di posizionamenti errati effettivi.<\/p>\n\n<pre><code>Esempi # (temporanei, fino al riavvio)\nsysctl -w kernel.numa_balancing_scan_period_min_ms=60000\nsysctl -w kernel.numa_balancing_scan_period_max_ms=240000\nsysctl -w kernel.numa_balancing_rate_limit_mb=64\n<\/code><\/pre>\n\n<h2>Metriche e analisi diagnostica approfondita<\/h2>\n\n<p>Per prendere decisioni fondate, analizzo gli indicatori che mettono direttamente in luce il meccanismo. Utilizzo regolarmente tre fonti:<\/p>\n\n<ul>\n  <li>numastat: rapporto tra accessi locali e remoti a livello di sistema e per processo.<\/li>\n  <li>\/proc\/\/numa_maps: distribuzione delle pagine di memoria di un processo tra i nodi, inclusi flag quali active, file, anon.<\/li>\n  <li>\/proc\/vmstat: contatori come numa_hint_faults, numa_hint_faults_local e numa_pages_migrated indicano se il bilanciatore \u00e8 attivo e se <strong>Il successo<\/strong> ha.<\/li>\n<\/ul>\n\n<pre><code>Panoramica # per processo\nnumastat -p \n\nVista dettagliata #: dove si trovano le aree?\ngrep -E 'anon|file' \/proc\/\/numa_maps | head\n\n#: panoramica a livello di kernel sull'attivit\u00e0 AutoNUMA\ngrep -E 'numa_(hint_faults|pages_migrated)' \/proc\/vmstat\n<\/code><\/pre>\n\n<p>Nei risultati cerco delle tendenze: la percentuale di accessi locali sta aumentando in modo costante? Allo stesso tempo, gli \u201chint fault\u201d stanno diminuendo? In tal caso, significa che il layout \u00e8 efficace. Se la percentuale locale rimane stabile nonostante le numerose migrazioni, tendo a sprecare cicli. Per gli obiettivi di latenza, verifico inoltre il 95\u00b0 e il 99\u00b0 percentile dei tempi di risposta; piccoli miglioramenti nella media possono essere compensati da <strong>Jitter<\/strong> essere coperti.<\/p>\n\n<h2>Profili di carico di lavoro: cosa funziona in genere<\/h2>\n\n<p>Dall'esperienza pratica sono emersi alcuni modelli che indicano quando AutoNUMA \u00e8 solitamente utile e quando invece non lo \u00e8:<\/p>\n\n<ul>\n  <li>Servizi JVM e server applicativi: spesso ne traggono vantaggio, purch\u00e9 non sia attiva una strategia rigida di thread pinning n\u00e9 una logica NUMA propria troppo aggressiva. Alcuni runtime offrono opzioni NUMA; se le utilizzo in modo rigoroso, riduco l'automaticit\u00e0 o la disattivo.<\/li>\n  <li>Banche dati relazionali: in caso di carico variabile con cache miste, il sistema automatico spesso funziona bene. Tuttavia, se impiego il pinning dedicato (da worker a nodo, buffer condivisi distribuiti in modo rigoroso), disattivo il bilanciamento per garantire una riproducibilit\u00e0 accurata.<\/li>\n  <li>Memorie in-memory e cache: un set di dati di lavoro di grandi dimensioni e ad alta attivit\u00e0 trae vantaggio dal posizionamento locale. Se l'istanza opera in modalit\u00e0 single-threaded o \u00e8 rigorosamente fissata, evito migrazioni inutili disattivando la funzione.<\/li>\n  <li>HPC\/MPI e codici scientifici: nella maggior parte dei casi esistono regole chiare di posizionamento e di binding (OpenMP\/numactl). In questo caso la prevedibilit\u00e0 \u00e8 pi\u00f9 importante dell\u2019automatismo: tralascio il bilanciamento NUMA.<\/li>\n<\/ul>\n\n<h2>Virtualizzazione: vNUMA, pinning e migrazione live<\/h2>\n\n<p>Nell\u2019interazione tra ospite e ospitante, prendo in considerazione entrambi i livelli:<\/p>\n\n<ul>\n  <li>Se la topologia vNUMA dell'ospite corrisponde alla topologia NUMA fisica dell'host, il bilanciatore dell'ospite \u00e8 in grado di prendere decisioni sensate. Se vi si discosta, si creano \u201evicindanze errate\u201c che AutoNUMA compensa solo in misura limitata.<\/li>\n  <li>Se assegno in modo fisso le vCPU alle CPU dell'host e associo la memoria dell'ospite a nodi specifici, si tratta di una politica esplicita: a questo livello della macchina virtuale riduco o disattivo AutoNUMA per evitare migrazioni doppie.<\/li>\n  <li>Dopo le migrazioni live, osservo una fase di assestamento: gli Hint-Fault aumentano fino a quando non si raggiunge un nuovo equilibrio. In questo periodo prevedo dei margini per <strong>Latenza<\/strong>-punte.<\/li>\n<\/ul>\n\n<p>Su host di virtualizzazione ad alta densit\u00e0, dove le istanze vengono avviate\/arrestate e i Cgroup ridistribuiscono il carico, la gestione automatica a livello di host rappresenta spesso un vantaggio netto. Per le VM dedicate sensibili al fenomeno del \u201eNoisy Neighbor\u201c, isolo accuratamente le risorse e imposto le regole in modo statico.<\/p>\n\n<h2>Valori target pragmatici e criteri di accettabilit\u00e0<\/h2>\n\n<p>Definisco in anticipo cosa significa \u201ebuono\u201c, in modo da non dover continuare all\u2019infinito a perfezionarlo:<\/p>\n\n<ul>\n  <li>Servizi generali: 70\u201385% accessi locali sono spesso sufficienti, purch\u00e9 la varianza rimanga bassa.<\/li>\n  <li>SLA sulla latenza: obiettivo &gt;90% a livello locale, limiti massimi ben definiti per l'Hint-Fault-Rate e percentili al 99\u00b0 stabili.<\/li>\n  <li>Con carico sulla larghezza di banda: le migrazioni non devono saturare i canali di memoria \u2013 adeguare di conseguenza i limiti di velocit\u00e0 e i periodi.<\/li>\n<\/ul>\n\n<p>Documento queste soglie e valuto i test A\/B su diverse fasi di carico. Prendo una decisione solo quando i risultati sono ripetibili.<\/p>\n\n<h2>Lista di controllo per la risoluzione dei problemi<\/h2>\n\n<ul>\n  <li>Picchi improvvisi di latenza: verificare se vi sia una correlazione tra le migrazioni THP e i picchi in `numa_hint_faults`. Contromisura: aumentare i periodi di scansione, impostare THP su `madvise\/never`, disattivare `Balance` se necessario.<\/li>\n  <li>Effetto quasi nullo nonostante l'attivazione: i thread sono fortemente bloccati o esistono politiche di memoria fisse? In tal caso, il sistema automatico entra in conflitto con le impostazioni predefinite.<\/li>\n  <li>Elevato ritmo di migrazione, ma comunque molti accessi da remoto: verificare e aumentare il limite di velocit\u00e0; in alternativa, stabilizzare il carico di lavoro (thread pinning, mantenere le cache stabili dal punto di vista termico).<\/li>\n  <li>Valori di misurazione poco chiari: utilizzare la vista per processo con numastat -p e \/proc\/\/numa_maps, non solo i valori complessivi del sistema.<\/li>\n<\/ul>\n\n<h2>Dettagli spesso trascurati<\/h2>\n\n<ul>\n  <li>Carichi di lavoro che fanno ampio ricorso alla cache delle pagine: AutoNUMA \u00e8 particolarmente efficace con le pagine anonime. Chi opera principalmente in contesti vincolati dall'I\/O non dovrebbe aspettarsi miracoli dal bilanciamento.<\/li>\n  <li>Cgroups e cpusets: il file cpuset.mems limita i nodi a cui un gruppo pu\u00f2 accedere. Si tratta di un quadro rigido entro il quale opera il sistema automatico.<\/li>\n  <li>Hot-plug della memoria\/disattivazione dei nodi: le topologie dinamiche modificano le distanze; dopo le modifiche \u00e8 consigliabile eseguire un nuovo test e, se necessario, adeguare i parametri di scansione.<\/li>\n<\/ul>\n\n<h2>Riassumendo brevemente<\/h2>\n\n<p>Per i carichi di lavoro generici del server, lascio attiva la modalit\u00e0 automatica, perch\u00e9 senza intervento manuale si avvicina <strong>Dati<\/strong> che porta a core attivi. In caso di elaborazione in tempo reale, HFT, pinning manuale o policy fisse, li disattivo per evitare overhead e jitter. Nelle fasi di test lavoro in modo iterativo: misuro, decido, ripeto <strong>convalidare<\/strong>. Mantengo la configurazione semplice, documento ogni modifica e ne verifico l'efficacia tramite indicatori affidabili. In questo modo sfrutto i punti di forza dell'hardware NUMA senza inutili <strong>I rischi<\/strong> affrontare.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scopri come il NUMA Balancing influisce sulle prestazioni di Linux sui moderni server e quando \u00e8 opportuno disattivare o mantenere attiva questa funzionalit\u00e0. Focus: NUMA Balancing.<\/p>","protected":false},"author":1,"featured_media":21096,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21103","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":"165","_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":"numa balancing","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":"21096","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21103","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=21103"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21103\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21096"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21103"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21103"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21103"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}