{"id":19569,"date":"2026-06-01T08:35:01","date_gmt":"2026-06-01T06:35:01","guid":{"rendered":"https:\/\/webhosting.de\/softirq-cpu-hosting-netzwerkdurchsatz-optimierung-datacenter\/"},"modified":"2026-06-01T08:35:01","modified_gmt":"2026-06-01T06:35:01","slug":"softirq-cpu-hosting-rete-ottimizzazione-del-throughput-datacenter","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/softirq-cpu-hosting-netzwerkdurchsatz-optimierung-datacenter\/","title":{"rendered":"softirq cpu hosting: ottimizzare le prestazioni del server e il throughput di rete"},"content":{"rendered":"<p>Mostro come <strong>softirq cpu<\/strong> insieme a NAPI, distribuzione degli IRQ e progettazione delle code limita o libera il throughput di rete nell'hosting. Con punti di misurazione chiari, messa a punto mirata e affinit\u00e0 pulite, riduco <strong>Latenze<\/strong> e aumentare costantemente il throughput pps dei server produttivi.<\/p>\n\n<h2>Punti centrali<\/h2>\n<p>Queste idee fondamentali trasportano i pacchetti di rete in modo efficiente attraverso la CPU, il kernel e la NIC, mantenendo i tempi di risposta al minimo. <strong>costante<\/strong> basso.<\/p>\n<ul>\n  <li><strong>Bilancio NAPI<\/strong> regolazione fine: Un numero maggiore di pacchetti per sondaggio riduce le spese generali e rende pi\u00f9 fluida la <strong>Carico della CPU<\/strong>.<\/li>\n  <li><strong>Bilanciamento IRQ<\/strong> e affinit\u00e0: evitare gli hotspot, aumentare le visite alla cache, <strong>Picchi di latenza<\/strong> Premere.<\/li>\n  <li><strong>Multi-queue<\/strong>, RSS\/RPS\/XPS: parallelizzazione dei flussi, mantenimento dell'allineamento NUMA, <strong>pps<\/strong> aumento.<\/li>\n  <li><strong>Scarichi<\/strong> utilizzare consapevolmente: GRO\/LRO, TSO, valutare la coalescenza, <strong>Jitter<\/strong> in vista.<\/li>\n  <li><strong>Isolamento<\/strong> e il Busy Polling: tempi di risposta prevedibili su sistemi dedicati. <strong>Nuclei<\/strong>.<\/li>\n<\/ul>\n\n<h2>Nozioni di base: cosa succede nel kernel durante il traffico di rete<\/h2>\n<p>Un pacchetto arriva prima in un interrupt hardware, dopodich\u00e9 il kernel si occupa del lavoro in <strong>SoftIRQ<\/strong> e i cicli di polling NAPI. Mi assicuro che la fase HardIRQ veloce rimanga molto breve e che la logica attuale si sposti nel contesto giusto, in modo che la <strong>tempo di CPU<\/strong> non si esaurisce. I thread di ksoftirqd intervengono solo se l'elaborazione diretta non \u00e8 possibile, il che porta rapidamente a code sotto carico continuo. \u00c8 proprio qui che si verificano i tempi di attesa, che si riflettono in un aumento del TTFB e in una fluttuazione del throughput. Se volete approfondire, potete trovare nozioni pratiche sull'elaborazione degli IRQ in questo articolo su <a href=\"https:\/\/webhosting.de\/it\/ottimizzazione-delle-prestazioni-della-cpu-per-la-gestione-degli-interrupt-del-server-7342\/\">Gestione degli interrupt e prestazioni della CPU<\/a>, che utilizzo per la categorizzazione.<\/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\/06\/serverperformance-netzwerk-4861.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NAPI, SoftIRQ e ksoftirqd: controllare la latenza invece di gestirla<\/h2>\n<p>NAPI riduce le tempeste di interruzioni raccogliendo diversi pacchetti per esecuzione entro un budget definito e riducendo cos\u00ec al minimo il tempo di interruzione. <strong>Spese generali<\/strong> si abbassa. Se il budget \u00e8 insufficiente, i pacchi si accumulano, il ksoftirqd si surriscalda e la <strong>Latenza<\/strong> aumenta in modo misurabile. In queste situazioni, controllo sistematicamente \/proc\/softirqs e \/proc\/net\/softnet_stat per visualizzare cadute, time_squeeze o code traboccanti. Poi aumento gradualmente net.core.netdev_budget o net.core.netdev_budget_usecs e monitoro in parallelo il carico della CPU, la distribuzione p95\/p99 e le perdite di pacchetti. Il trucco sta nel riuscire a fare abbastanza lavoro per ogni poll senza affollare l'esecuzione interattiva dei thread userland.<\/p>\n\n<h2>Bilanciamento e affinit\u00e0 IRQ: evitare gli hotspot, aumentare le visite alla cache<\/h2>\n<p>Un singolo core con tutti gli IRQ della NIC diventa un collo di bottiglia perch\u00e9 deve servire gli interrupt, gli IRQ soft e i thread dell'applicazione; quindi distribuisco <strong>IRQ<\/strong> mirato. Il servizio irqbalance \u00e8 d'aiuto, ma per le alte velocit\u00e0 di trasmissione mappo esplicitamente le code RX\/TX tramite l'affinit\u00e0 con le code pi\u00f9 adatte. <strong>nuclei<\/strong>. Sui sistemi NUMA, lego le code ai core dello stesso nodo per evitare accessi remoti alla memoria. I thread delle applicazioni vengono eseguiti su core vicini ma separati, il che migliora la localizzazione della cache e la schedulabilit\u00e0. Questa guida alla distribuzione strategica fornisce una buona panoramica della <a href=\"https:\/\/webhosting.de\/it\/server-irq-balancing-ottimizzazione-delle-prestazioni-di-rete-datacenter\/\">Bilanciamento degli IRQ nel data center<\/a>, che uso come riferimento per la messa a punto.<\/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\/serverperformance3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Multi-queue, RSS\/RPS\/XPS: utilizzare correttamente la parallelizzazione<\/h2>\n<p>Le moderne schede NIC sono dotate di diverse code RX\/TX, che posso controllare tramite <strong>RSS<\/strong> ai flussi, ottenendo cos\u00ec un vero parallelismo. Se la scheda offre un numero insufficiente di code, utilizzo RPS\/XPS per effettuare regolazioni sul lato software al fine di distribuire i pacchetti in modo sensato tra i flussi. <strong>nuclei<\/strong> da spingere. La distribuzione pulita degli hash \u00e8 importante per far s\u00ec che un flusso rimanga sempre sulla stessa CPU e che non si verifichino costose distorsioni della cache. Allo stesso tempo, mantengo i percorsi TX e RX vicini tra loro per evitare la contesa dei blocchi e gli accessi non necessari tra i nodi. In questo modo si aumenta il throughput pps senza che un singolo core tiri il freno.<\/p>\n\n<h2>Affinit\u00e0 della CPU nello spazio utente: pensiero end-to-end<\/h2>\n<p>Pianifico il percorso dei dati dalla NIC-IRQ tramite le code NAPI ai thread worker dell'applicazione, in modo che i pacchetti raggiungano la loro destinazione senza agganci inutili e che la <strong>Tempo di risposta<\/strong> rimane costante. Per ottenere questo risultato, separo coerentemente i core per gli interrupt\/softIRQ da quelli per le applicazioni e creo dei nuclei chiari per le applicazioni. <strong>Affinit\u00e0<\/strong>-regole. Ai server web, ai reverse proxy e ai database vengono assegnati set di CPU fissi, vicini ai core IRQ, per mantenere i percorsi brevi. Inoltre, ho impostato il governatore della CPU sulle prestazioni, in modo che le variazioni di clock non spingano il jitter in p99. Questa assegnazione coerente rende il comportamento prevedibile e aiuta a diagnosticare i colli di bottiglia in modo pulito.<\/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-optimization-8321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Offload, GRO\/LRO, firewall e eBPF: risparmiare il carico senza volare alla cieca<\/h2>\n<p>Salvataggio di checksum offload, TSO e coalescenza <strong>tempo di CPU<\/strong>, Tuttavia, possono modificare le dimensioni dei pacchetti, il comportamento dei burst e il jitter, motivo per cui misuro gli effetti in modo specifico. GRO\/LRO raggruppano i frame e riducono il carico sullo stack, ma per le esigenze in tempo reale decido in base alla situazione. <strong>Disattivazione<\/strong> o di uso limitato. Le tabelle di Conntrack e le catene profonde di nftables\/iptables costano orologi, quindi riordino le regole superflue e semplifico i percorsi. Se necessario, ricorro a eBPF (XDP, tc-BPF) per prendere decisioni tempestive sul NIC ed evitare percorsi costosi. Un buon punto di partenza per la pratica della messa a punto \u00e8 questa panoramica di <a href=\"https:\/\/webhosting.de\/it\/interruzione-della-coalescenza-ottimizzazione-della-rete-serverflux\/\">Interruzione della coalescenza<\/a>, che tengo in considerazione per i budget di latenza sensibili.<\/p>\n\n<h2>Polling occupato e isolamento della CPU: blocco dei tempi di risposta<\/h2>\n<p>Per gli obiettivi a bassa latenza, utilizzo il polling occupato, in modo che i socket dello spazio utente raccolgano i pacchetti anche prima e <strong>Tempi di attesa<\/strong> accorciare. Questo aumenta il carico, ma mi fornisce distribuzioni p99 molto strette per i carichi di lavoro API o di trading su un sistema dedicato. <strong>Nuclei<\/strong>. Inoltre, isolo i core con isolcpus=, nohz_full= e rcu_nocbs= in modo che timer, RCU e servizi di sistema vengano eseguiti solo sulle CPU di mantenimento. Questa separazione evita le interferenze sui core di latenza e rende il comportamento riproducibile. Il risultato \u00e8 una chiara tabella di marcia: core dedicati, raccolta anticipata dei pacchetti, budget definiti.<\/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\/softirq_cpu_hosting_4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoraggio e risoluzione dei problemi: dal sintomo alla causa<\/h2>\n<p>Inizio con pps, throughput e carico del core, poi controllo le cadute e l'attivit\u00e0 di <strong>ksoftirqd<\/strong>-nel tempo per riconoscere in modo affidabile gli schemi. Strumenti come sar, htop, ss, nload e ethtool mi mostrano quando e dove si verificano le congestioni e se il sistema \u00e8 in grado di gestire il traffico. <strong>Spunti<\/strong> raggiungono i loro limiti. Le distribuzioni sono importanti invece dei valori medi, in modo da non perdere i picchi serali, le finestre cron o le campagne. Metto in relazione i picchi TTFB con la distribuzione degli IRQ, il budget NAPI e le impostazioni di offload per apportare modifiche mirate. Una regolazione dell'affinit\u00e0 IRQ o un nuovo budget NAPI su misura sono spesso sufficienti per ridurre sensibilmente i timeout.<\/p>\n\n<h2>Panoramica dei parametri di sintonizzazione<\/h2>\n<p>La seguente panoramica mi aiuta a utilizzare le modifiche con saggezza e ad assegnare gli effetti in modo chiaro prima di apportare modifiche permanenti. <strong>lanci<\/strong> piano. Testiamo ogni aggiustamento in modo iterativo, misuriamo le distribuzioni di latenza e osserviamo gli effetti secondari su <strong>CPU<\/strong> e la memoria. Modifico sempre e solo un punto per ogni finestra di test, in modo che la causa e l'effetto rimangano chiari. Quindi documento i risultati e stabilisco i valori di soglia per gli avvisi. In questo modo ottengo miglioramenti riproducibili senza rischiare sorprese nel traffico produttivo.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Parametro\/caratteristica<\/th>\n      <th>Effetto nel percorso dati<\/th>\n      <th>Quando raccogliere\/attivare<\/th>\n      <th>Rischi\/effetti collaterali<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>net.core.netdev_budget<\/strong><\/td>\n      <td>Pi\u00f9 pacchetti per sondaggio NAPI<\/td>\n      <td>Per le gocce in softnet_stat<\/td>\n      <td>I sondaggi pi\u00f9 lunghi eliminano le discussioni degli utenti<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.core.netdev_budget_usecs<\/strong><\/td>\n      <td>Limitare la finestra temporale per ogni sondaggio<\/td>\n      <td>Per il jitter dovuto a burst di grandi dimensioni<\/td>\n      <td>Troppo piccolo: pi\u00f9 modifiche al contesto<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>RSS\/RPS\/XPS<\/strong><\/td>\n      <td>Distribuire i flussi tra i core<\/td>\n      <td>Per gli hotspot su un nucleo<\/td>\n      <td>Hash errati: distorsioni della cache<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Affinit\u00e0 IRQ<\/strong><\/td>\n      <td>Legare gli IRQ vicino al core<\/td>\n      <td>Con NUMA-Missmatch<\/td>\n      <td>La cattiva allocazione crea nuovi hotspot<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>GRO\/LRO\/TSO<\/strong><\/td>\n      <td>Riduce il numero di pacchetti<\/td>\n      <td>Per il collo di bottiglia della CPU<\/td>\n      <td>Jitter, burst pi\u00f9 grandi<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Sondaggio occupato<\/strong><\/td>\n      <td>Raccolta anticipata dei pacchi<\/td>\n      <td>Per gli obiettivi difficili di p99<\/td>\n      <td>Maggiore consumo di CPU<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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\/developer_desk_focus_optimization_3748.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Anelli RX\/TX e profondit\u00e0 della stecca: dimensionamento corretto dei buffer<\/h2>\n<p>Anche con IRQ distribuiti correttamente e budget adeguati, anelli NIC troppo piccoli o troppo grandi possono ridurre le prestazioni. Per questo motivo verifico le dimensioni degli anelli RX\/TX della scheda e le adatto agli obiettivi di burst e latenza. Anelli troppo piccoli causano cali nella NIC durante i picchi di traffico, visibili come rx_missed_errors o fifo_errors nelle statistiche del driver. Gli anelli troppo grandi nascondono la congestione, aumentano la latenza e creano lunghi bordi di uscita in p95\/p99. Sto cercando una via di mezzo: un buffer sufficiente per assorbire brevi raffiche, ma non cos\u00ec tanto da far \u201cinvecchiare\u201d i pacchetti nelle code.<\/p>\n<p>Inoltre, si esamina il lato host <strong>tx_queue_len<\/strong> e il disco Q utilizzato. Con sch_fq o fq_codel posso attenuare il comportamento dei burst e distribuire i pacchetti TSO di grandi dimensioni tramite il pacing. In questo modo si riducono i microburst sulla porta dello switch e si rende la curva di latenza pi\u00f9 uniforme, importante per i carichi di lavoro misti in cui piccoli RPC vengono eseguiti insieme a grandi upload. Monitoro le statistiche di ethtool e le metto in relazione con softnet_stat per capire se la congestione si verifica nell'anello NIC, nel backlog netdev o nel Qdisc.<\/p>\n\n<h2>MTU, jumbo frame e segmentazione<\/h2>\n<p>Il sito <strong>MTU<\/strong> \u00e8 una leva classica che spesso viene sottovalutata. I jumbo frame riducono il numero di pacchetti per Gbit\/s e riducono il carico sulla CPU, ma solo se il percorso \u00e8 veramente in grado di gestire i jumbo end-to-end. Pertanto, convalido sistematicamente le stazioni remote, gli switch e i tunnel. Non appena la frammentazione torna a 1500 da qualche parte, c'\u00e8 il rischio di problemi di MTU del percorso, di ritrasmissioni e di inutili <strong>Jitter<\/strong>. Nei data center con una comunicazione dominante tra Est e Ovest, vale la pena adottare una strategia omogenea a 9k, mentre 1500 \u00e8 spesso la scelta pi\u00f9 stabile per i carichi di lavoro rivolti a Internet.<\/p>\n<p>Valuto sempre l'MTU insieme a <strong>TSO\/GSO\/GRO<\/strong>Un bundling troppo aggressivo pu\u00f2 portare a grandi burst nel TX che riempiono i buffer a monte e generano picchi di latenza. L'obiettivo \u00e8 un percorso coerente: una segmentazione sensata al trasmettitore, meccanismi di pacing sufficienti e un GRO che risparmia lavoro sul lato del ricevitore senza vanificare i requisiti in tempo reale.<\/p>\n\n<h2>UDP, QUIC e carichi di lavoro in streaming: considerare le specifiche<\/h2>\n<p>Non tutto il traffico \u00e8 TCP. <strong>UDP<\/strong>-I profili pesanti (DNS, VoIP, QUIC, telemetria) si comportano in modo diverso in RSS\/RPS e GRO. Gli stack moderni supportano UDP-GRO\/GSO, che pu\u00f2 ridurre il carico sulla CPU - io lo uso selettivamente e misuro se i rischi di riordino o il jitter aumentano. Per i carichi QUIC\/HTTP3, la distribuzione pulita dei flussi \u00e8 fondamentale: RPS pu\u00f2 aiutare se la NIC offre un numero troppo basso di code RSS, ma non deve \u201cbuttare in giro\u201d i flussi caldi della cache. Sul lato TX ho impostato <strong>XPS<\/strong> per raggruppare i percorsi di trasmissione e ridurre la contesa sui blocchi. In pratica, un'allocazione silenziosa e core-affine \u00e8 vantaggiosa, soprattutto con molti flussi UDP di medie dimensioni, dove ogni hit della cache \u00e8 importante.<\/p>\n\n<h2>Virtualizzazione e container: integrazione pulita di host, guest e vhost<\/h2>\n<p>Negli ambienti virtualizzati, il lavoro si sposta tra host, thread vhost e IRQ guest. Mi assicuro che <strong>vhost-rete<\/strong>-I thread ricevono i propri core e non si scontrano con gli app worker. Le loro affinit\u00e0 devono corrispondere alle code RX\/TX fisiche, altrimenti si verificher\u00e0 un'inutile migrazione tra CPU. Nel guest, controllo le code di virtio-net, attivo il multi-queue e imposto RSS\/RPS analoghi a quelli di bare metal. Dove latenza e pps sono in primo piano <strong>SR-IOV<\/strong> ridurre ulteriormente i costi generali - il prerequisito \u00e8 una topologia NUMA coerente: VF, vCPU e memoria appartengono allo stesso nodo.<\/p>\n<p>Nello stack container, le reti overlay, le catene NAT profonde e le topologie CNI complesse causano ulteriori hop. Per i servizi critici in termini di latenza, preferisco hostNetwork o reti snelle (macvlan\/ipvlan), equalizzare i percorsi NAT e mantenere <strong>Traccia di collegamento<\/strong> il pi\u00f9 piccolo possibile. \u00c8 importante una strategia coerente per la CPU: i core IRQ e NAPI dell'host dovrebbero essere situati nelle vicinanze dei core su cui vengono eseguiti i vhost\/container worker; questo \u00e8 l'unico modo per mantenere il percorso dei dati breve e prevedibile.<\/p>\n\n<h2>Schedulazione, stati C e threading IRQ<\/h2>\n<p>Perch\u00e9 la latenza non \u00e8 solo tempo di calcolo, ma anche <strong>Orario di sveglia<\/strong> Riduco al minimo gli stati C profondi sui core a latenza. Un risparmio energetico aggressivo pu\u00f2 costare millisecondi prima che una SoftIRQ venga effettivamente eseguita. Per questo mi affido ai regolatori di prestazioni, limito gli stati C profondi e mantengo il turbo costante per rendere prevedibili i salti di frequenza. Altrettanto importante \u00e8 <strong>Filettatura IRQ<\/strong>Dove i driver lo consentono, sposto il lavoro sui thread IRQ e stabilisco le priorit\u00e0 in modo che RX si avvii prima del lavoro a valle, senza spostare completamente userland. L'interazione tra le politiche di schedulazione, le affinit\u00e0 e i budget \u00e8 complicata; faccio dei test passo dopo passo, registro p99 e sto attento alle interferenze con ksoftirqd, che altrimenti diventa un collo di bottiglia segreto.<\/p>\n\n<h2>L'osservazione in profondit\u00e0: punti traccia, contatori, istogrammi<\/h2>\n<p>Se le metriche rimangono vaghe, vado un livello pi\u00f9 profondo: utilizzo i punti di traccia del kernel attorno a <strong>netif_receive_skb<\/strong>, <strong>napi_poll<\/strong> e <strong>coda_di_rete<\/strong>, per visualizzare la durata dei sondaggi, il volume dei pacchetti e i tempi di attesa sotto forma di istogrammi. Tali distribuzioni mostrano se 1 % dei polling sta impiegando troppo tempo o se le singole code si stanno esaurendo. Inoltre, ethtool-<strong>rx\/tx<\/strong>-I contatori, le ritrasmissioni TCP, le risposte al poll busy e softnet_stat indicano chiaramente dove vengono persi i pacchetti. Uso l'analisi dei drop per riconoscere se la NIC sta perdendo (anello pieno), se il backlog di netdev sta collassando (time_squeeze) o se il Qdisc\/firewall sta rallentando. Solo quando questi pezzi del puzzle si incastrano, modifico anelli, budget o offload.<\/p>\n\n<h2>Semplificare i percorsi di sicurezza e filtraggio<\/h2>\n<p>ACL complesse, catene profonde di nftables\/iptables e ampie tabelle di conntrack aggiungono una latenza costante per pacchetto. Consolido le regole, lavoro con set\/mappe e sposto i drop generici il pi\u00f9 avanti possibile nel percorso, idealmente il pi\u00f9 presto possibile sulla NIC (XDP\/clsact) se la latenza \u00e8 fondamentale. I flussi stateless, la telemetria o le porte \u201csicure\u201d conosciute possono essere utilizzati in modo mirato. <strong>senza tracciamento<\/strong> per eliminare la necessit\u00e0 di costose ricerche. Allo stesso tempo, mantengo fresche le tabelle di stato, regolo le dimensioni degli hash in base ai picchi di carico e riordino aggressivamente le voci orfane. L'obiettivo \u00e8 un percorso di policy pulito e tracciabile, che non si noti nel profilo come un carico permanente.<\/p>\n\n<h2>Anti-pattern tipici e come li evito<\/h2>\n<ul>\n  <li><strong>Tutti gli IRQ su un core:<\/strong> porta alla congestione e al ksoftirqd caldo. Antidoto: affinit\u00e0 mirate per cue, NUMA-coherent.<\/li>\n  <li><strong>Massimizzazione cieca di anelli\/budget:<\/strong> nasconde la congestione, aumenta le code di latenza. Antidoto: aumentare in modo incrementale, misurare le distribuzioni.<\/li>\n  <li><strong>Configurazione errata dell'hashing del flusso:<\/strong> I flussi saltano da un core all'altro, le cache si esauriscono. Antidoto: chiavi RSS stabili, RPS\/XPS solo con un obiettivo chiaro.<\/li>\n  <li><strong>I thread dell'applicazione sugli stessi core di SoftIRQ:<\/strong> Interferenze e jitter. Antidoto: separazione rigida, allocazione per prossimit\u00e0.<\/li>\n  <li><strong>Sovrapposizioni\/NAT senza budget:<\/strong> aggiunto a ciascun hop. Rimedio: razionalizzare i percorsi e le reti di host per i carichi di lavoro con latenza.<\/li>\n  <li><strong>Risparmio energetico sui core a latenza:<\/strong> Gli stati C profondi rallentano la reazione. Antidoto: regolatore di prestazioni, limitazione degli stati C.<\/li>\n  <li><strong>Scarico senza misurazione:<\/strong> TSO\/GRO pu\u00f2 esacerbare i burst e il jitter. Rimedio: attivare il carico di lavoro specifico, monitorare p99.<\/li>\n<\/ul>\n\n<h2>Hosting pratico: passi che funzionano<\/h2>\n<p>Inizio con una fase di misurazione pulita, stabilisco delle linee di base e mantengo tutti i cambiamenti di piccola entit\u00e0 in finestre temporali brevi, in modo da poter <strong>Cause<\/strong> possono essere separati. Attivo quindi irqbalance, controllo la distribuzione automatica e, se necessario, imposto le affinit\u00e0 manuali fino a quando non <strong>Hotspot<\/strong> non sono pi\u00f9 visibili. Quindi configuro Multi-Queue, RSS e, se necessario, RPS\/XPS, sincronizzati con NUMA. Lego gli app worker a core vicini ai loro IRQ, ma senza collisioni dirette. Infine, spurgo i percorsi del firewall, controllo le tabelle di conntrack e prendo decisioni consapevoli sugli offload in base agli obiettivi di latenza.<\/p>\n\n<h2>Esempio di playbook per le latenze di p99<\/h2>\n<p>Per prima cosa misuro p95\/p99 tramite il carico rappresentativo e i log sicuri di \/proc\/softirqs e \/proc\/net\/softnet_stat, al fine di <strong>Gocce<\/strong> e time_squeeze sono chiaramente visibili. Poi aumento netdev_budget o netdev_budget_usecs passo dopo passo e tengo premuto p99 dopo ogni modifica in modo da poter vedere i dati reali. <strong>Tendenze<\/strong> riconoscere. In parallelo, lego gli IRQ ai core di un nodo NUMA e sposto i lavoratori dell'applicazione nei vicini adatti. Se p99 continua a saltare, provo le varianti GRO\/LRO e i profili di coalescenza degli interrupt, ciascuno con un breve percorso di misurazione. Solo quando la distribuzione rimane stabile trasferisco la configurazione ai ruoli Ansible o ai dropin systemd.<\/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\/serverraum-performance-1947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Versione breve per gli amministratori<\/h2>\n<p>Raggiungo la massima leva finanziaria <strong>SoftIRQ<\/strong>, Il budget NAPI, le affinit\u00e0 IRQ e i thread dell'applicazione come percorso dati coerente. Distribuisco il lavoro di rete tra i core, mantengo le code coerenti con NUMA e collego i lavoratori in modo sensato in modo che <strong>Percorsi<\/strong> non \u00e8 un problema. Imposto deliberatamente gli offload e misuro il jitter invece di ottimizzare alla cieca il throughput. Per gli obiettivi di latenza difficili, mi affido al polling occupato e all'isolamento della CPU, mentre le CPU di mantenimento intercettano le interferenze. Se si implementano questi passaggi in modo disciplinato, si ottiene un throughput costante, distribuzioni di latenza pi\u00f9 strette e un ambiente di hosting che reagisce in modo prevedibile ai picchi di carico.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scoprite come il cpu hosting softirq con interrupt ottimizzati per linux, NAPI e bilanciamento IRQ aumenta il throughput della rete e riduce le latenze nel funzionamento del server.<\/p>","protected":false},"author":1,"featured_media":19562,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19569","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":"67","_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":"softirq cpu","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":"19562","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/19569","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=19569"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/19569\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/19562"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=19569"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=19569"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=19569"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}