{"id":19865,"date":"2026-06-10T11:53:56","date_gmt":"2026-06-10T09:53:56","guid":{"rendered":"https:\/\/webhosting.de\/server-numa-locality-cpu-memory-affinity-optimierung-core\/"},"modified":"2026-06-10T11:53:56","modified_gmt":"2026-06-10T09:53:56","slug":"server-numa-localita-cpu-memoria-affinita-ottimizzazione-core","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/server-numa-locality-cpu-memory-affinity-optimierung-core\/","title":{"rendered":"Server NUMA Locality e CPU-Memory Affinity per le massime prestazioni di hosting"},"content":{"rendered":"<p><strong>Server NUMA<\/strong> La localizzazione e l'affinit\u00e0 di memoria della CPU determinano la vicinanza dei thread alla loro RAM e la costanza delle latenze negli stack di hosting. Vi mostrer\u00f2 in modo pratico come sia possibile ottenere un throughput misurabilmente pi\u00f9 elevato con il riconoscimento della topologia, le strategie di affinit\u00e0 e i percorsi di I\/O vicini al nodo e <strong>Latenza<\/strong> notevolmente inferiore.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<p>Per un rapido orientamento, riassumo i messaggi chiave prima di spiegare i passaggi in dettaglio e sostenerli con esempi, in modo che possiate vedere immediatamente da dove iniziare per <strong>Localit\u00e0<\/strong> e Affinity con profitto. Sottolineo le relazioni chiare tra thread, memoria e I\/O, in modo da poter ricavare le priorit\u00e0 in modo pulito e <strong>Decisioni<\/strong> incontrare. Identifico anche gli scenari in cui l'Interleave ha senso senza diluire i vostri percorsi critici e mostro come potete dimostrare i progressi reali attraverso il monitoraggio e la verifica dei risultati. <strong>Errore<\/strong> sono evitati. Per gli ambienti virtualizzati, fornisco suggerimenti sul posizionamento delle vCPU e della vRAM, in modo che i sistemi guest non scivolino su pi\u00f9 nodi e che non si verifichino problemi di sicurezza. <strong>Remoto<\/strong>-Gli accessi esplodono. Infine, tradurr\u00f2 i risultati in una breve tabella di marcia, in modo che possiate procedere in modo strutturato e fare ogni passo nella giusta direzione. <strong>misurabile<\/strong> sicuro.<\/p>\n<ul>\n  <li><strong>Localit\u00e0<\/strong> primo: mantenete i thread vicino alla vostra RAM, evitate quelli remoti.<\/li>\n  <li><strong>Affinit\u00e0<\/strong> correggere: Legare core e memoria insieme in base ai criteri.<\/li>\n  <li><strong>Topologia<\/strong> leggere: Nodi, core, dispositivi PCIe per socket.<\/li>\n  <li><strong>Percorsi di I\/O<\/strong> bundle: Accoppiare NIC, NVMe e app nello stesso nodo.<\/li>\n  <li><strong>fiere<\/strong> invece di tirare a indovinare: P95\/P99, accesso remoto e tracciamento della velocit\u00e0.<\/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\/06\/serverraum-performance-1573.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comprendere la topologia NUMA<\/h2>\n\n<p>Prima di spostare i carichi di lavoro, leggo il documento <strong>Topologia<\/strong> del server: quanti nodi NUMA esistono, quanti core e quanta RAM sono collegati a ciascun nodo. Presto anche attenzione a quali dispositivi PCIe, come le schede NIC o le unit\u00e0 SSD NVMe, sono collegati a quale socket, in quanto ci\u00f2 determina i percorsi di interrupt e gli accessi alla memoria, e a quanta RAM \u00e8 collegata a ciascun nodo. <strong>Latenza<\/strong> caratterizzato. Un nodo consente l'accesso alla memoria locale a breve distanza; tutto ci\u00f2 che va oltre costa tempo e larghezza di banda. Pi\u00f9 la macchina si ingrandisce con pi\u00f9 socket, pi\u00f9 l'accesso remoto incide sui tempi di risposta e consuma larghezza di banda. <strong>Produttivit\u00e0<\/strong>. Per un'introduzione comprensibile alla logica dell'hardware, trovo che un compatto <a href=\"https:\/\/webhosting.de\/it\/nodi-numa-server-hosting-grandi-sistemi-serverboost\/\">I nodi NUMA in sintesi<\/a>, per considerare consapevolmente i confini dei nodi ed evitare distribuzioni errate.<\/p>\n\n<p>In pratica, inizio con un breve inventario della topologia e lo documento in modo da poter poi ricavare le decisioni sull'affinit\u00e0 in modo comprensibile. Comandi utili:<\/p>\n<pre><code>Core # e assegnazione NUMA\nlscpu -e=CPU,Core,Socket,Nodo\n\nPanoramica dell'hardware # NUMA\nnumactl --hardware\n\n# Assegnare i dispositivi PCIe al proprio nodo NUMA\nlspci -nn | grep -E \"Ethernet|Non volatile\"\nper d in \/sys\/bus\/pci\/devices\/*; fare echo -n \"$d: \"; cat $d\/numa_node; done\n<\/code><\/pre>\n<p>L'importante \u00e8 che <strong>Complesso radice PCIe<\/strong> e gli slot dei dispositivi ai socket. Due porte della stessa NIC possono essere assegnate a nodi diversi; questo influenza la posizione delle code RX\/TX e degli IRQ. Lo stesso vale per NVMe: i moderni controller hanno diverse code che dovrebbero essere assegnate a core vicini al nodo, in modo che il DMA non attivi alcun salto di nodo.<\/p>\n\n<h2>Utilizzo corretto dell'affinit\u00e0 di memoria della CPU<\/h2>\n\n<p>Con l'Affinit\u00e0 CPU-Memoria, collego saldamente i processi alle aree centrali e impongo l'allocazione della memoria locale per quanto possibile, in modo che <strong>Discussioni<\/strong> non superino costantemente il bordo del nodo. In Linux, definisco le CPU tramite systemd o cgroup e combino questo con le politiche di memoria in modo che la RAM sia preferibilmente creata sullo stesso nodo e <strong>Remoto<\/strong> rimane ridotto al minimo. I servizi critici (front-end API, cache in-memory, database) ne beneficiano immediatamente, perch\u00e9 i tempi di attesa del controller di memoria si riducono e gli hit della cache sono pi\u00f9 frequenti. Tuttavia, limiti di pinning troppo rigidi possono limitare la pianificazione, quindi mi avvalgo di ogni regolazione con dei benchmark e osservo i valori P95\/P99 per verificare se ci sono effetti evidenti su <strong>Utente<\/strong>-esperienza. Un'introduzione compatta ad Affinity in hosting vi aiuta a iniziare: <a href=\"https:\/\/webhosting.de\/it\/processo-di-server-affinita-numa-consapevolezza-hosting-ressourcentuning\/\">Affinit\u00e0 e consapevolezza NUMA<\/a> fornire gli strumenti necessari per un posizionamento pulito.<\/p>\n\n<p>Il fattore decisivo \u00e8 la <strong>Principio del primo contatto<\/strong>La memoria viene creata sul nodo che scrive per primo sulla pagina. Pertanto, inizializzare gli heap o i buffer di grandi dimensioni sui core di destinazione del nodo in cui il servizio verr\u00e0 eseguito in seguito, idealmente con i criteri di CPU e memoria gi\u00e0 impostati (ad esempio, tramite systemd unit o numactl). Se si avvia il cold sul nodo 0 e poi si spostano i thread sul nodo 1, la maggior parte delle pagine rimane remota. Per gli heap di grandi dimensioni, vale la pena di usare il \u201epre-touch\u201c durante l'avvio, in modo che le pagine ruotino localmente e rimangano calde.<\/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\/06\/server_numa_affinity_2763.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Consapevolezza di NUMA nello stack di hosting<\/h2>\n\n<p>Un sistema operativo NUMA-aware, un hypervisor adatto e applicazioni con thread pinning dispiegano insieme tutto il loro potenziale. <strong>Potenziale<\/strong>. Il sistema operativo favorisce il posizionamento locale se nel nodo sono disponibili risorse libere, mentre l'hypervisor alloca le macchine virtuali in modo tale che le vCPU e la vRAM non si allontanino tra loro e che le macchine virtuali non si allontanino tra loro. <strong>Localit\u00e0<\/strong> viene mantenuto. Nell'applicazione, separo i pool di lavoratori per ogni nodo e mantengo le code a livello locale invece di gestire pool globali in modo trasversale. Organizzo i processi di database, i demoni della cache e le istanze del server web su base nodo per nodo, in modo che i percorsi a caldo rimangano brevi e <strong>Jitter<\/strong> diminuisce. Ci\u00f2 aumenta la coerenza e la prevedibilit\u00e0 sotto carico, che influisce direttamente sulla prevedibilit\u00e0 degli SLA in euro ed evita un costoso overprovisioning.<\/p>\n\n<p>A livello di Ingress, mi occupo di <strong>Affinit\u00e0 dei nodi<\/strong> delle sessioni, ad esempio attraverso un instradamento appiccicoso o un hashing coerente (ad esempio sull'IP del cliente o sui token di sessione), in modo che le richieste finiscano di nuovo al \u201eloro\u201c worker locale del nodo e alla cache. Per i servizi stateful, pianifico le repliche per nodo e bilancia l'accesso in lettura a livello locale; equalizzo i percorsi di scrittura tramite repliche asincrone o batching per evitare il ping-pong tra i nodi.<\/p>\n\n<h2>Programmare i servizi nodo per nodo<\/h2>\n\n<p>Raggruppo i livelli di una pila in modo tale che ogni livello abbia un chiaro riferimento a un nodo e <strong>Percorsi<\/strong> rimanere breve. Una separazione classica: web\/API per nodo, app worker accanto ad esso, pi\u00f9 la cache locale; anche il database si trova vicino al nodo, se l'ingombro della RAM \u00e8 sufficiente e il database non \u00e8 troppo grande. <strong>IO<\/strong>-non viene interrotto. Sposto i lavori di reporting, i backup o i batch worker su nodi meno critici, in modo che le richieste interattive non vengano influenzate. Evito le istanze monolite di grandi dimensioni perch\u00e9 spesso attraversano i confini dei nodi e quindi generano un carico remoto, che <strong>Prestazioni<\/strong> sfocata. Le istanze pi\u00f9 piccole e replicate per nodo spesso offrono un throughput migliore nell'uso quotidiano, poich\u00e9 rispettano le regole NUMA e attenuano i picchi.<\/p>\n\n<p>Per la pianificazione della capacit\u00e0, calcolo <strong>spazio libero<\/strong> separatamente per ogni nodo: buffer della CPU per i burst, buffer della RAM contro l'OOM e margini separati per la cache delle pagine. In questo modo, evito che il kernel commuti involontariamente in remoto. Definisco percorsi di commutazione chiari per il failover: se un nodo si guasta, le istanze sostitutive possono essere eseguite da un nodo all'altro, ma limito la loro concomitanza fino al ripristino del nodo originale, in modo da mantenere stabile la latenza complessiva.<\/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\/06\/server-performance-numa-locality-4759.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Impostazione dell'affinit\u00e0 della CPU: Metodi e insidie<\/h2>\n\n<p>Per l'allocazione dei core, uso systemd con CPUAffinity o cgroups con cpuset.cpus, in modo da avere servizi fissi <strong>Aree principali<\/strong> ottenere. Quando faccio il pinning, faccio attenzione alle coppie di hyper-threading, perch\u00e9 due thread logici di un'unit\u00e0 fisica condividono le risorse e possono rallentarsi a vicenda se li combino in modo infelice, e <strong>Suggerimenti<\/strong> creare. I percorsi di latenza - terminazione TLS, ingresso API, lettori di cache - ottengono core esclusivi, mentre i log, la compressione o i backup si spostano in altri pool. I pool troppo stretti senza buffer causano code, per cui considero lo spazio a disposizione e verifico gli switch di contesto, la lunghezza delle code e il numero di giri. <strong>IRQ<\/strong>-distribuzione. Dall'osservazione deduco se aprire maggiormente i core o concentrarli ulteriormente fino a quando la distribuzione della latenza si riduce in modo netto e i picchi di P99 diventano pi\u00f9 silenziosi.<\/p>\n\n<p>Per ridurre ulteriormente il jitter, ho impostato selettivamente gli interruttori del kernel, come ad esempio <strong>nohz_full<\/strong> e <strong>rcu_nocbs<\/strong> per i core a latenza esclusiva, isolarli dai servizi di sistema e posizionare deliberatamente gli IRQ solo sulle CPU destinate a questo scopo. Uso il servizio \u201eirqbalance\u201c con cautela: configuratelo in modo specifico o disattivatelo se ostacola l'affinit\u00e0 IRQ manuale. Uso SCHED_FIFO\/SCHED_RR con parsimonia e solo con limiti di Be per evitare l'inversione di priorit\u00e0 o l'inedia.<\/p>\n\n<h2>Politiche di memoria e maschere NUMA<\/h2>\n\n<p>Per la politica della memoria, si distingue tra allocazione locale preferita, interleave su pi\u00f9 nodi e maschere NUMA fisse tramite cpuset.mems, in modo che <strong>RAM<\/strong> in base al luogo in cui i thread sono effettivamente in esecuzione. Per i servizi interattivi, di solito imposto \u201epreferito\u201c, il che significa che il sistema alloca localmente e devia solo quando c'\u00e8 una carenza, il che \u00e8 <strong>Remoto<\/strong>-Gli accessi sono limitati. I lavori di analisi o di streaming a volte traggono vantaggio dall'interleave perch\u00e9 la larghezza di banda \u00e8 distribuita tra i nodi e la pressione su un controller \u00e8 ridotta. Le maschere fisse offrono un controllo, ma richiedono una disciplina nella pianificazione della capacit\u00e0, in modo che non si verifichino eventi OOM indesiderati in un nodo e che si verifichino eventi OOM indesiderati in un nodo. <strong>Servizi<\/strong> interferire. La tabella seguente suddivide le politiche comuni in scenari tipici e aiuta a prendere una decisione rapida.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Politica<\/strong><\/th>\n      <th><strong>Effetto<\/strong><\/th>\n      <th><strong>Carichi di lavoro tipici<\/strong><\/th>\n      <th><strong>Il rischio<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Preferito (locale)<\/td>\n      <td>RAM principalmente nel nodo locale, opzione di ripiego in caso di scarsit\u00e0<\/td>\n      <td>Web\/Api, cache, database OLTP<\/td>\n      <td>Leggera deriva a pieno carico su altri nodi<\/td>\n    <\/tr>\n    <tr>\n      <td>Interleave<\/td>\n      <td>Distribuzione uniforme sui nodi selezionati<\/td>\n      <td>Streaming, analisi, scansioni di grandi dimensioni<\/td>\n      <td>Latenza pi\u00f9 elevata per i singoli accessi<\/td>\n    <\/tr>\n    <tr>\n      <td>Maschera NUMA fissa<\/td>\n      <td>Legame rigoroso con i nodi di memoria definiti<\/td>\n      <td>Servizi rigorosamente incapsulati, test deterministici<\/td>\n      <td>Rischio di OOM se il budget \u00e8 pianificato in modo errato<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Tenere d'occhio gli interruttori a livello di sistema: <strong>modalit\u00e0_recupero_zona<\/strong> influenza se un nodo pulisce in modo aggressivo la propria memoria prima di allocarla in remoto - spesso indesiderabile per i percorsi a latenza. <strong>Pagine trasparenti di grandi dimensioni<\/strong> (THP) pu\u00f2 innescare la migrazione delle pagine o generare stalli; per i servizi sensibili alla latenza, di solito scelgo \u201emadvise\u201c e uso hugepages statiche dove ha senso, in modo da aumentare le visite al TLB e ridurre i picchi di errore delle pagine.<\/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\/06\/server_performance_optimization_2314.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Legare i percorsi di rete e di I\/O vicino al nodo<\/h2>\n\n<p>Allineo le code delle NIC (RX\/TX) in modo che i loro IRQ puntino ai core del nodo appropriato e l'elaborazione dei pacchetti avvenga nel punto in cui il nodo \u00e8 stato selezionato. <strong>App<\/strong> calcoli. Lo stesso vale per le unit\u00e0 SSD NVMe o i controller RAID: i thread di I\/O dovrebbero essere eseguiti sul nodo a cui il dispositivo \u00e8 collegato tramite PCIe, in modo che i percorsi DMA rimangano brevi e il dispositivo possa essere utilizzato in modo pi\u00f9 efficiente. <strong>Colli di bottiglia<\/strong> non si concretizzano. Su Linux, regolo le maschere di affinit\u00e0 IRQ e le collego ai pool di CPU dei miei servizi per creare un percorso continuo. In caso di microburst dalla rete, come ad esempio molti handshake TLS, questa vicinanza si ripaga direttamente perch\u00e9 i percorsi di copia sono pi\u00f9 brevi e le cache della CPU rimangono calde e <strong>Contesto<\/strong> meno frequentemente. In questo modo si ottiene un flusso di dati coerente dal pacchetto all'applicazione alla memoria, senza inutili salti di nodo.<\/p>\n\n<p>Leve concrete nello stack di rete: <strong>RSS<\/strong> per la distribuzione hardware alle code, <strong>RPS\/RFS<\/strong> per il controllo della CPU basato su software e <strong>XPS<\/strong> per la selezione dei TX. Uso ethtool per assegnare le code RX ai gruppi di core che funzionano nello stesso nodo dei lavoratori. Per l'archiviazione uso <strong>blk-mq<\/strong>-I controller NVMe offrono diverse code di invio\/completamento, che scalano e affinano \u2264 numero di core per nodo. Controllate regolarmente se gli interrupt (cat \/proc\/interrupts) si attivano nei punti in cui si trovano i core dell'applicazione: potete riconoscere una deriva dall'aumento dei byte remoti nonostante un carico stabile.<\/p>\n\n<h2>Struttura dell'architettura applicativa in linea con NUMA<\/h2>\n\n<p>A livello di applicazione, creo i miei pool di lavoratori per ogni nodo NUMA, mantengo le code a livello locale ed evito gli hotspot di blocco globale, in modo che <strong>Discussioni<\/strong> non saltare avanti e indietro. Ho impostato lo sharding delle sessioni e dei dati in modo che le partizioni calde rimangano dove sono in esecuzione i lavoratori richiedenti e che le partizioni calde rimangano dove sono in esecuzione i lavoratori richiedenti. <strong>Tempo<\/strong> non si perde nel traffico tra i nodi. Per le cache, spesso uso repliche invece di un'istanza centrale, in modo che i lettori raggiungano le copie locali dei nodi. In Netty, Tokio, libuv o nei client DB, applico i cicli di eventi a core fissi e faccio attenzione alla vicinanza degli IRQ, in modo che le modifiche ai task siano limitate e che i task non siano in conflitto con i core. <strong>Cache<\/strong> colpire meglio. Questa disposizione riduce l'effetto ping-pong e rende i tempi di risposta pi\u00f9 costanti nel corso della giornata.<\/p>\n\n<p>Una leva sottovalutata \u00e8 <strong>Allocatore<\/strong> e le opzioni di runtime: Gli allocatori abilitati NUMA (jemalloc\/tcmalloc) riducono la contesa tra thread e mantengono le pagine pi\u00f9 vicine ai kernel di origine dei thread. Negli stack JVM, opzioni come NUMA awareness e pre-touch contribuiscono a rendere deterministiche le fasi di errore; in .NET, allineo i thread GC vicino ai nodi e presto attenzione al GC del server per attenuare i tempi di arresto. In Go, dimensiono GOMAXPROCS per pool di nodi e tengo gli scheduler delle goroutine lontani dai core a latenza che lavorano vicino agli IRQ.<\/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\/06\/server_performance_desk_7452.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Controllo sensibile dell'autobilanciamento NUMA<\/h2>\n\n<p>I meccanismi automatici di bilanciamento NUMA del kernel possono aiutare a smussare il carico distribuito, ma verifico sempre se sono in grado di supportare la mia <strong>Affinit\u00e0<\/strong> sono compromessi. Nei servizi critici per la latenza, disabilito o limito lo spostamento automatico se questo tira fuori i thread dalla loro memoria locale e <strong>Suggerimenti<\/strong> generato. Per i lavori di analisi o per l'elaborazione in batch, tendo a lasciare il bilanciamento attivo perch\u00e9 pu\u00f2 aumentare la larghezza di banda senza degradare l'interazione. Un'introduzione pratica alle strategie di bilanciamento mi fornisce ulteriori punti di partenza: <a href=\"https:\/\/webhosting.de\/it\/numa-bilanciamento-dei-server-ottimizzazione-della-memoria-hardware-numaflux\/\">Capire il bilanciamento NUMA<\/a> mostra quando il sistema automatico deve funzionare e quando deve essere assegnato manualmente. Alla fine, prendo una decisione basata sui dati per ogni classe di servizio invece di adottare ciecamente un'impostazione predefinita globale e <strong>Obiettivi<\/strong> da non perdere.<\/p>\n\n<p>Quando il bilanciamento \u00e8 attivato, monitoro i tassi di migrazione, i picchi di errore minore\/maggiore e il consumo di CPU per nodo. Se le pagine vengono spostate avanti e indietro ciclicamente, le contrasto con un pinning pi\u00f9 stretto, un pre-touch e maschere di memoria pi\u00f9 strette. Nei carichi di lavoro con scansioni lunghe e sequenziali, tuttavia, il bilanciamento pu\u00f2 armonizzare il carico, a condizione che non siano interessati percorsi a latenza interattiva.<\/p>\n\n<h2>Monitoraggio: misurare, confrontare, decidere<\/h2>\n\n<p>Senza misurazioni, la messa a punto rimane un gioco di ipotesi, per cui tengo traccia del carico della CPU per core e per nodo, dell'utilizzo della memoria per nodo e della proporzione di <strong>Remoto<\/strong>-accessi. Per l'esperienza dell'utente, le latenze P95\/P99 contano molto di pi\u00f9 dei valori medi, perch\u00e9 gli outlier caratterizzano l'impressione di SLA e <strong>Costi<\/strong> verso l'alto. Eseguo profili di carico realistici con cache fredde e calde, perch\u00e9 entrambi i mondi mostrano colli di bottiglia diversi. Dopo ogni modifica, documento le impostazioni, la data del test e i risultati, in modo da poter invertire con sicurezza le modifiche in un secondo momento e <strong>Conoscenza<\/strong> non va persa. Se si mettono in relazione anche le metriche delle applicazioni (lunghezza delle code, tentativi, garbage collection) con i valori del sistema, \u00e8 possibile riconoscere pi\u00f9 rapidamente la causa e l'effetto.<\/p>\n\n<p>Aiuto pratico nell'analisi:<\/p>\n<ul>\n  <li>numastat (relativi al sistema e al processo) per la zona locale e per la zona di processo. <strong>Remoto<\/strong>-Hit<\/li>\n  <li>\/proc\/interruzioni e tempo SoftIRQ della CPU per la deriva degli IRQ<\/li>\n  <li>eventi perf e statistiche dello scheduler per la profondit\u00e0 della coda, gli scambi di contesto, le mancanze di LLC, ecc.<\/li>\n  <li>fio\/iperf\/wrk con pool di lavoratori specifici per nodo per confronti riproducibili<\/li>\n<\/ul>\n<p>La valutazione viene effettuata per nodo: Mi aspetto che gli istogrammi di latenza siano vicini. Se un nodo si sposta verso l'alto, cerco innanzitutto un carico IRQ distribuito in modo errato, una deriva nella cache delle pagine o heap allocati al nodo sbagliato durante il riscaldamento.<\/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\/06\/hosting-serverraum-8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA nelle macchine virtuali e nei container<\/h2>\n\n<p>Nella virtualizzazione, la collocazione delle vCPU e della vRAM su un nodo comune \u00e8 importante per evitare che i carichi di lavoro dei guest si frammentino e <strong>Latenza<\/strong> tira su. Dimensiono la RAM in modo che si adatti al nodo locale ed evito le macchine virtuali di grandi dimensioni che si estendono su diversi nodi e <strong>Deriva<\/strong> innesco. Per i container, uso i controller cpuset in modo che i gruppi di pod funzionino in modo coerente su un nodo e lo storage sia creato localmente. Preferisco posizionare i guest che fanno uso di I\/O sul nodo con una connessione diretta allo storage, in modo da mantenere i percorsi DMA corti e <strong>IRQ<\/strong>-Ridurre il rumore. Ci\u00f2 significa che anche gli host di virtualizzazione pi\u00f9 densi rimangono prevedibili e portano avanti pi\u00f9 progetti sullo stesso hardware.<\/p>\n\n<p>Presto attenzione a <strong>vNUMA<\/strong>-Esposizione: il guest deve vedere la stessa struttura di nodi che l'hypervisor fornisce fisicamente. vCPU pinning e vRAM binding vanno di pari passo; se possibile, sposto gli hot-add durante le finestre di manutenzione, perch\u00e9 altrimenti le nuove pagine finiscono in remoto. In Kubernetes, imposto QoS \u201egarantito\u201c, CPU manager \u201estatico\u201c e posizionamento topology-aware in modo che i pod non si spostino tra i nodi. Per le SR-IOV\/VF, assegno le VF al nodo fisico appropriato e lego le code IRQ ai set di CPU dei pod o delle VM che servono.<\/p>\n\n<h2>Preparazione mirata del primo tocco, del riscaldamento e dei cumuli<\/h2>\n\n<p>Molti errori di prestazione si verificano durante <strong>Inizio<\/strong>Gli accumuli crescono nella fase di riscaldamento, quando arrivano le prime richieste, spesso centralmente su un nodo. Pertanto, eseguo un riscaldamento controllato per ogni nodo: avvio le istanze con una maschera CPU\/memoria impostata, eseguo query mirate di pre-caricamento e inizializzo le cache in parallelo per ogni nodo. Per i servizi JVM, attivo il pre-touch dell'heap; per i database, segmento i buffer pool nodo per nodo. Questo riduce le migrazioni successive delle pagine e garantisce che le prime richieste non caratterizzino in modo casuale la distribuzione della memoria.<\/p>\n\n<h2>Messa a punto del Kernel\/BIOS per latenze costanti<\/h2>\n\n<p>Sotto il cofano, regolo la potenza e la politica di interruzione:<\/p>\n<ul>\n  <li>Impostate il governatore della CPU su \u201eperformance\u201c, limitate gli stati C profondi, utilizzate con attenzione gli stati C dei pacchetti al fine di <strong>Jitter<\/strong> ridurre.<\/li>\n  <li>Non limitate la frequenza della memoria; i profili energetici bilanciati spesso riducono al minimo la frequenza della memoria. <strong>Produttivit\u00e0<\/strong> sotto carico.<\/li>\n  <li>Evitare lo spettro diffuso\/modulazione di clock se la coerenza \u00e8 pi\u00f9 importante del minimo risparmio energetico.<\/li>\n<\/ul>\n<p>A livello di kernel, tengo separate le CPU di manutenzione dai core di latenza, riduco al minimo gli interrupt del timer sui core caldi (nohz_full) e parcheggio il lavoro in background (compattazione, Kswapd) preferibilmente sui core di sistema di un nodo che non esegue percorsi di latenza.<\/p>\n\n<h2>Risoluzione dei problemi e tipici anti-pattern<\/h2>\n\n<ul>\n  <li><strong>Sintomo<\/strong>La latenza di P99 salta dopo le distribuzioni. <strong>Causa<\/strong>Heaps\/Cache first-touch sul nodo sbagliato. <strong>Soluzione<\/strong>Riscaldamento\/pre-trattamento sotto l'affinit\u00e0 target, quindi aprire il distributore di carico.<\/li>\n  <li><strong>Sintomo<\/strong>Tempo SoftIRQ elevato su CPU \u201esbagliate\u201c. <strong>Causa<\/strong>irqbalance distribuito sui nodi. <strong>Soluzione<\/strong>Correggere l'affinit\u00e0 IRQ, impostare RPS\/RFS\/XPS conforme ai nodi.<\/li>\n  <li><strong>Sintomo<\/strong>OOM in un nodo, anche se la RAM di sistema \u00e8 libera. <strong>Causa<\/strong>Maschera NUMA rigorosa senza buffer. <strong>Soluzione<\/strong>Correggere la capacit\u00e0 o usare \u201epreferito\u201c, stabilire gli avvisi per nodo.<\/li>\n  <li><strong>Sintomo<\/strong>Produttivit\u00e0 irregolare con NVMe. <strong>Causa<\/strong>Mappatura errata delle code, code condivise tra i nodi. <strong>Soluzione<\/strong>: code blk-mq\/NVMe per nodo, thread I\/O appuntati.<\/li>\n<\/ul>\n\n<h2>Lista di controllo pratica<\/h2>\n\n<ul>\n  <li>Topologia record: Nodi, core, RAM, dispositivi PCIe per socket.<\/li>\n  <li>Disegnare la sezione di servizio: Quali percorsi sono <strong>Latenza<\/strong>-critico, quale lotto?<\/li>\n  <li>Impostare l'affinit\u00e0 CPU\/memoria per ogni classe; notare il primo tocco all'inizio.<\/li>\n  <li>Collegare IRQ\/queues vicino al nodo; controllare le code RSS\/RPS\/XPS e NVMe.<\/li>\n  <li>Monitoraggio su P95\/P99, accesso remoto, coda di esecuzione, distribuzione IRQ.<\/li>\n  <li>Controllare in modo specifico l'autobilanciamento; selezionare la modalit\u00e0 THP\/zone_reclaim_mode in modo appropriato.<\/li>\n  <li>Mantenere vNUMA, vCPU pinning e vRAM binding coerenti nelle macchine virtuali\/container.<\/li>\n  <li>Eseguire test iterativi, documentare, tornare indietro in caso di deriva e mettere a punto.<\/li>\n<\/ul>\n\n<h2>Breve riassunto e programma di messa a punto<\/h2>\n\n<p>Porta il massimo rendimento, <strong>Discussioni<\/strong> e memoria insieme, accorciare i percorsi di I\/O e distribuirli solo con attenzione. Inizio con l'analisi della topologia, pianifico i servizi nodo per nodo, imposto l'affinit\u00e0 di CPU e memoria, collego rete\/storage in modo appropriato e monitoro i valori P95\/P99 con particolare attenzione a <strong>Remoto<\/strong>-accessi. Quindi modifico le dimensioni dei pool, le maschere IRQ e le politiche fino a quando i picchi di latenza si attenuano e il throughput aumenta. Per le macchine virtuali e i container, verifico il posizionamento separatamente perch\u00e9 l'hypervisor ha un'influenza notevole e <strong>Confini<\/strong> funzionano in modo diverso. Se ripetete e documentate questo processo, otterrete un aumento misurabile delle prestazioni di Server NUMA Locality e CPU-Memory Affinity, spesso pi\u00f9 economico dell'aggiornamento di hardware aggiuntivo in euro.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scoprite come la localizzazione NUMA dei server e l'affinit\u00e0 CPU-Memoria ottimizzano le prestazioni del vostro hosting. La guida illustra la messa a punto pratica delle prestazioni dei server moderni.<\/p>","protected":false},"author":1,"featured_media":19858,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19865","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":"52","_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":"Server 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":"19858","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/19865","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=19865"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/19865\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/19858"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=19865"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=19865"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=19865"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}