{"id":19369,"date":"2026-05-15T11:51:18","date_gmt":"2026-05-15T09:51:18","guid":{"rendered":"https:\/\/webhosting.de\/server-irq-balancing-netzwerk-performance-optimierung-datacenter\/"},"modified":"2026-05-15T11:51:18","modified_gmt":"2026-05-15T09:51:18","slug":"server-irq-balancing-ottimizzazione-delle-prestazioni-di-rete-datacenter","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/server-irq-balancing-netzwerk-performance-optimierung-datacenter\/","title":{"rendered":"Bilanciamento degli IRQ del server e prestazioni di rete per l'hosting ad alto carico"},"content":{"rendered":"<p>Il carico di rete elevato \u00e8 determinato dall'elaborazione efficiente di <strong>IRQ del server<\/strong> segnali: Se si distribuiscono saggiamente gli interrupt tra i core della CPU, si riduce la latenza e si prevengono le cadute. In questa guida vi mostrer\u00f2 come combinare il bilanciamento degli IRQ, l'RSS\/RPS e l'affinit\u00e0 della CPU in modo pratico per rendere sostenibile l'hosting ad alto carico. <strong>performante<\/strong> per operare.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>Distribuzione IRQ<\/strong> impedisce la formazione di punti caldi sui singoli core della CPU.<\/li>\n  <li><strong>Multi-queue<\/strong> pi\u00f9 RSS\/RPS parallelizza l'elaborazione dei pacchetti.<\/li>\n  <li><strong>Attenzione NUMA<\/strong> riduce l'accesso e la latenza tra i nodi.<\/li>\n  <li><strong>Governatore della CPU<\/strong> e il pinning dei thread riducono i tempi di risposta.<\/li>\n  <li><strong>Monitoraggio<\/strong> Controlla pps, latenze, cadute e utilizzo dei core.<\/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\/05\/serverraum-hosting-0382.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gli IRQ spiegati brevemente: perch\u00e9 controllano il carico di rete<\/h2>\n\n<p>Per ogni pacchetto in arrivo, la scheda di rete segnala via <strong>IRQ<\/strong>, che il lavoro \u00e8 in attesa, altrimenti il kernel dovrebbe eseguire un polling attivo. Se l'assegnazione rimane su un core, il suo utilizzo aumenta, mentre altri core <strong>inutilizzato<\/strong> rimangono. Questo \u00e8 esattamente il momento in cui le latenze aumentano, i buffer dell'anello RX si riempiono e i driver iniziano a scartare i pacchetti. Distribuisco gli interrupt tra i core adatti per mantenere l'elaborazione dei pacchetti uniforme e prevedibile. In questo modo si eliminano i colli di bottiglia, i tempi di risposta sono pi\u00f9 fluidi e le perdite di pacchetti sono ridotte al minimo.<\/p>\n\n<h2>Bilanciamento degli IRQ e affinit\u00e0 della CPU in Linux<\/h2>\n\n<p>Il servizio <strong>irqbalance<\/strong> distribuisce gli interrupt dinamicamente, analizza il carico e sposta automaticamente le affinit\u00e0 nel tempo. Per i profili di carico estremi, definisco manualmente le affinit\u00e0 tramite <code>\/proc\/irq\/\/smp_affinity<\/code> e legare le indicazioni in modo specifico ai nuclei dello stesso <strong>NUMA<\/strong>-nodi. Questa combinazione di automatismo e regolazione fine mi aiuta a elaborare in modo pulito sia i carichi di base che i picchi. Un'introduzione approfondita a <a href=\"https:\/\/webhosting.de\/it\/ottimizzazione-delle-prestazioni-della-cpu-per-la-gestione-degli-interrupt-del-server-7342\/\">Gestione degli interrupt e ottimizzazione della CPU<\/a> Li uso per aiutarmi nella pianificazione. Rimane importante: Collego costantemente la topologia dell'hardware, la distribuzione degli IRQ e i thread delle applicazioni tra loro.<\/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\/05\/server_irq_balance_performance_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Uso pratico di NIC multi-queue, RSS e RPS<\/h2>\n\n<p>Le moderne NIC forniscono diverse code RX\/TX; ogni coda attiva la propria <strong>IRQ<\/strong>, e Receive Side Scaling (RSS) distribuisce i flussi ai core. Se le code hardware non sono sufficienti, aggiungo al kernel il Receive Packet Steering (RPS) e il Transmit Packet Steering (XPS) per ottenere un'ulteriore <strong>Parallelismo<\/strong>. Con <code>ethtool -L ethX combinato N<\/code> Adeguo il numero di coda al numero di core del nodo NUMA associato. Controllo con <code>ettool -S<\/code> e <code>nstat<\/code>, se si verificano cadute, polls occupati o picchi elevati di pps. Per un livellamento pi\u00f9 fine del carico, uso anche <a href=\"https:\/\/webhosting.de\/it\/interruzione-della-coalescenza-ottimizzazione-della-rete-serverflux\/\">Interruzione della coalescenza<\/a> nella pianificazione, in modo che la NIC non generi troppi IRQ individuali.<\/p>\n\n<p>La tabella seguente mostra i componenti centrali e i comandi tipici che utilizzo per una configurazione coerente:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Blocco di costruzione<\/th>\n      <th>Obiettivo<\/th>\n      <th>Esempio<\/th>\n      <th>Suggerimento<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>irqbalance<\/strong><\/td>\n      <td>Distribuzione automatica<\/td>\n      <td><code>systemctl enable --now irqbalance<\/code><\/td>\n      <td>Punto di partenza per carichi di lavoro misti<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Affinit\u00e0<\/strong><\/td>\n      <td>Corregge il Pinning<\/td>\n      <td><code>echo mask &gt; \/proc\/irq\/XX\/smp_affinity<\/code><\/td>\n      <td>Osservare l'assegnazione NUMA<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Spunti<\/strong><\/td>\n      <td>Pi\u00f9 parallelismo<\/td>\n      <td><code>ethtool -L ethX combinato N<\/code><\/td>\n      <td>Corrispondenza con i core del nodo<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>RSS\/RPS<\/strong><\/td>\n      <td>Distribuzione del flusso<\/td>\n      <td><code>sysfs: rps_cpus\/rps_flow_cnt<\/code><\/td>\n      <td>Utile per un numero ridotto di code NIC<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>XPS<\/strong><\/td>\n      <td>Nuclei ordinati del percorso TX<\/td>\n      <td><code>sysfs: xps_cpus<\/code><\/td>\n      <td>Evita il thrash della cache<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Uso sensato del bilanciamento automatico degli IRQ<\/h2>\n\n<p>Per i server di hosting misti, spesso \u00e8 sufficiente attivare <strong>irqbalance<\/strong>, perch\u00e9 il demone riconosce costantemente i cambiamenti di carico. Controllo lo stato tramite <code>systemctl status irqbalance<\/code> e dare un'occhiata a <code>\/proc\/interruzioni<\/code>, per vedere la distribuzione per coda e core. Se le latenze aumentano nei picchi, definisco dei core di prova che elaborano principalmente gli interrupt e confronto i valori misurati prima e dopo la modifica. Mantengo la configurazione <strong>semplice<\/strong>, in modo che le verifiche successive e i rollback siano rapidi. Solo quando gli schemi sono chiari, approfondisco il tema del pinning.<\/p>\n\n<h2>Affinit\u00e0 manuale della CPU per il massimo controllo<\/h2>\n\n<p>In caso di velocit\u00e0 di trasmissione molto elevate, collego le code RX a core selezionati dello stesso sistema. <strong>NUMA<\/strong>-e separo deliberatamente i thread dell'applicazione da essi. Isolo i singoli core per gli interrupt, eseguo i worker su core vicini e presto molta attenzione alla localizzazione della cache. In questo modo, riduco gli accessi cross-node e minimizzo i costosi passaggi di contesto nel percorso caldo. Per ottenere risultati riproducibili, documento chiaramente le maschere IRQ, l'assegnazione delle code e l'affinit\u00e0 dei thread dei servizi. Questa chiarezza consente di mantenere i tempi di esecuzione dei pacchetti <strong>costante<\/strong> e riduce i valori anomali.<\/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\/05\/server-performance-optimization-9876.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Coordinamento pulito dell'ottimizzazione della CPU e delle applicazioni<\/h2>\n\n<p>Ho impostato il <strong>Governatore della CPU<\/strong> spesso impostato su \u201eperformance\u201c perch\u00e9 le variazioni di clock aumentano i salti di latenza. Lego i processi critici come Nginx, HAProxy o i database a core vicini ai core IRQ, oppure li separo deliberatamente se il profilo della cache lo richiede. Rimane importante limitare i cambiamenti di contesto e mantenere il kernel aggiornato in modo che le ottimizzazioni dello stack di rete abbiano effetto. Misuro gli effetti di ogni cambiamento invece di fare ipotesi e mi adatto passo dopo passo. Il risultato \u00e8 una configurazione che funziona sotto carico <strong>prevedibile<\/strong> reagisce.<\/p>\n\n<h2>Impostare correttamente il monitoraggio e la misurazione<\/h2>\n\n<p>Senza valori misurati, la messa a punto rimane un gioco di ipotesi, quindi inizier\u00f2 con <strong>sar<\/strong>, <strong>mpstat<\/strong>, <strong>vmstat<\/strong>, <strong>nstat<\/strong>, <strong>ss<\/strong> e <code>ettool -S<\/code>. Per i test di carico strutturati utilizzo <code>iperf3<\/code> e analizzo throughput, pps, latenza, ritrasmissioni e utilizzo del core. Registro le tendenze a lungo termine utilizzando sistemi di monitoraggio standard per riconoscere modelli come i picchi serali, le finestre di backup o le campagne. Se si vuole comprendere il percorso dei dati in modo olistico, si pu\u00f2 trarre vantaggio da una visione del <a href=\"https:\/\/webhosting.de\/it\/server-elaborazione-dei-pacchetti-pipeline-hosting-router-di-rete\/\">Pipeline di elaborazione dei pacchetti<\/a> dall'IRQ della NIC allo spazio utente. Solo la combinazione di questi segnali mostra se il bilanciamento e l'affinit\u00e0 IRQ hanno ottenuto l'effetto desiderato. <strong>Effetto<\/strong> portare.<\/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\/05\/server_irq_balancing_4356.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comprendere NAPI, Softirqs e ksoftirqd<\/h2>\n<p>Per gestire i picchi di latenza con carichi elevati di pps, tengo conto della <strong>NAPI<\/strong>-e l'interazione tra IRQ hard e IRQ soft. Dopo il primo IRQ hardware, NAPI recupera diversi pacchetti dalla coda RX in modalit\u00e0 poll per evitare le tempeste di IRQ. Se gli IRQ soft non vengono processati tempestivamente, vengono spostati in <code>ksoftirqd\/N<\/code> Thread che vengono eseguiti solo con priorit\u00e0 normale: un motivo classico per aumentare le latenze di coda. Osservo <code>\/proc\/softirqs<\/code> e <code>\/proc\/net\/softnet_stat<\/code>; un alto \u201e<code>tempo_schiacciamento<\/code>\u201cIl valore o i cali indicano che il budget \u00e8 troppo limitato. Con <code>sysctl -w net.core.netdev_budget_usecs=8000<\/code> e <code>sysctl -w net.core.netdev_budget=600<\/code> Aumento il tempo di elaborazione per poll NIC e il budget dei pacchetti come test. Importante: aumento i valori gradualmente, misuro e verifico se si verifica un jitter della CPU o un'interferenza con i thread dell'applicazione.<\/p>\n\n<h2>Messa a punto dell'hash RSS e della tabella di indirezione<\/h2>\n<p>RSS distribuisce i flussi alle code tramite la tabella di indirezione (RETA). Verifico la chiave hash e la tabella con <code>ethtool -n ethX rx-flow-hash tcp4<\/code> e, se necessario, impostare la distribuzione in modo simmetrico. Con <code>ethtool -X ethX uguale N<\/code> o specificamente per voce (<code>ethtool -X ethX hkey ... hfunc toeplitz indir 0:1 1:3 ...<\/code>), abbino le assegnazioni ai core preferiti di un nodo NUMA. L'obiettivo \u00e8 <strong>Appiccicosit\u00e0 del flusso<\/strong>Un flusso rimane sullo stesso core, in modo che la localizzazione della cache e la conservazione dei blocchi nello stack rimangano minime. Per gli ambienti con molti flussi UDP brevi, aumento <code>rps_flow_cnt<\/code> per coda RX, in modo che la distribuzione del software abbia un numero sufficiente di bucket e non crei hotspot. Tengo presente che gli hash simmetrici aiutano con le topologie ECMP, ma nel contesto dei server l'equilibrio dei core \u00e8 ci\u00f2 che conta di pi\u00f9.<\/p>\n\n<h2>Scegliere in modo oculato gli scarichi, GRO\/LRO e le dimensioni degli anelli<\/h2>\n<p>Gli offload hardware riducono il carico sulla CPU, ma possono modificare i profili di latenza. Verifico con <code>ethtool -k ethX<\/code>, se <strong>TSO\/GSO\/UDP_SEG<\/strong> su TX e <strong>GRO\/LRO<\/strong> sono attivi su RX. GRO aggrega i pacchetti nel kernel ed \u00e8 quasi sempre utile per il throughput; LRO pu\u00f2 essere problematico nelle configurazioni di routing o filtraggio ed \u00e8 meglio lasciarlo disattivato. Per le API critiche per la latenza, provo un'aggregazione GRO pi\u00f9 piccola (o temporaneamente disattivata) se le latenze di p99 dominano. Regolo anche le dimensioni degli anelli tramite <code>ethtool -G ethX rx 1024 tx 1024<\/code>Anelli pi\u00f9 grandi intercettano i burst, ma aumentano la latenza in caso di congestione; anelli troppo piccoli portano a <code>rx_missed_errors<\/code>. Mi affido ai valori misurati da <code>ettool -S<\/code> (es. <code>rx_no_buffer_count<\/code>, <code>rx_dropped<\/code>) e concordare questo con <strong>BQL<\/strong> (limiti delle code di byte, automatici sul lato kernel) in modo da non sovraccaricare le code di TX.<\/p>\n\n<h2>Virtualizzazione: IRQ nelle macchine virtuali e nell'hypervisor<\/h2>\n\n<p>Nelle configurazioni virtualizzate, controllo la distribuzione della NIC fisica sull'host e imposto <strong>Bilanciamento IRQ<\/strong> chiaramente. Le macchine virtuali ricevono abbastanza vCPU, ma evito l'overcommitment cieco in modo che i ritardi di pianificazione non aumentino la latenza. I moderni driver paravirtualizzati, come virtio-net o vmxnet3, mi forniscono i percorsi migliori per ottenere elevate velocit\u00e0 di trasmissione. All'interno della macchina virtuale, controllo di nuovo l'affinit\u00e0 e il numero di code in modo che il guest non diventi un collo di bottiglia. \u00c8 fondamentale avere una visione coerente dell'host e del guest in modo che l'intero percorso dati <strong>vero<\/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\/05\/server_irq_balance_net_5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Approfondimento della virtualizzazione: SR-IOV, vhost e OVS<\/h2>\n<p>Per velocit\u00e0 di trasmissione molto elevate, utilizzo l'hypervisor <strong>SR-IOV<\/strong>Lego le funzioni virtuali (VF) della NIC fisica direttamente alle macchine virtuali e le collego ai core dei nodi NUMA appropriati. In questo modo si bypassano parti dello stack dell'host e si riduce la latenza. Dove SR-IOV non \u00e8 adatto, faccio attenzione a <strong>vhost-rete<\/strong> e bloccare i thread del vhost, come gli application worker e i core IRQ, in modo che non si verifichino salti cross-NUMA. Nelle configurazioni overlay o switching, valuto i costi aggiuntivi di Linux bridge o OVS; per i profili estremi, utilizzo OVS-DPDK solo se lo sforzo operativo giustifica il vantaggio misurabile. Lo stesso vale in questo caso: misuro pps, latenza e distribuzione della CPU prima di prendere decisioni, non dopo.<\/p>\n\n<h2>Polling occupato e messa a punto dello spazio utente<\/h2>\n<p>Per i servizi critici per la latenza <strong>Sondaggio occupato<\/strong> ridurre il jitter. Ho attivato il seguente test <code>sysctl -w net.core.busy_read=50<\/code> e <code>net.core.busy_poll=50<\/code> (microsecondi) e impostare l'opzione socket <code>SO_BUSY_POLL<\/code> selettivamente per i socket interessati. Lo spazio utente esegue il polling poco prima del blocco e cattura i pacchetti prima che si spostino nelle code. Questo costa tempo alla CPU, ma spesso fornisce latenze p99 pi\u00f9 stabili. Mantengo bassi i valori, monitoro l'utilizzo dei core e combino il polling occupato solo con una chiara affinit\u00e0 dei thread e un governatore fisso della CPU, altrimenti gli effetti si annullano a vicenda.<\/p>\n\n<h2>I costi di Parcel Filter, Conntrack e eBPF in sintesi<\/h2>\n<p>Il firewalling e il NAT fanno parte del percorso dei dati. Pertanto, verifico il <strong>nftables\/iptables<\/strong>-e riordinare le regole morte o le catene profonde. Nelle configurazioni pi\u00f9 impegnative, regolo la dimensione della tabella Conntrack (<code>nf_conntrack_max<\/code>, numero di hash bucket) o disattivare Conntrack specificamente per i flussi stateless. Se si utilizzano programmi eBPF (XDP, tc-BPF), misuro i loro costi di runtime per hook e do priorit\u00e0 a \u201eearly drop\/redirect\u201c per alleggerire i percorsi costosi. \u00c8 importante che la responsabilit\u00e0 sia chiara: l'ottimizzazione viene effettuata nell'offload della NIC, nel programma eBPF o nello stack classico - la duplicazione aumenta solo la latenza.<\/p>\n\n<h2>Isolamento della CPU e core di mantenimento<\/h2>\n<p>Per una latenza assolutamente deterministica, memorizzo il lavoro in background su <strong>CPU di manutenzione<\/strong> off. I parametri del kernel, come <code>nohz_full=<\/code>, <code>rcu_nocbs=<\/code> e <code>irqaffinit\u00e0=<\/code> aiutano a mantenere i core dedicati ampiamente liberi dalla gestione dei tick, dai callback RCU e dagli IRQ esterni. Isolo un gruppo di core per gli application worker e un altro per gli IRQ e i softirq; i servizi di sistema e i timer vengono eseguiti su core separati. Questo assicura profili di cache puliti e riduce gli effetti di prelazione. L'hyper-threading pu\u00f2 aumentare il jitter in singoli casi; verifico se la sua disattivazione per ogni coppia di core attenua le latenze di p99 prima di prendere una decisione globale.<\/p>\n\n<h2>Manuale di diagnostica e tipici anti-pattern<\/h2>\n<p>Quando si verificano cadute o picchi di latenza, seguo un approccio strutturato: 1) <code>\/proc\/interruzioni<\/code> Controllare che non vi sia una distribuzione non uniforme. 2) <code>ettool -S<\/code> su cadute RX\/TX, errori FIFO, <code>rx_no_buffer_count<\/code> controllo. 3) <code>\/proc\/net\/softnet_stat<\/code> a \u201e<code>tempo_schiacciamento<\/code>\" o \"<code>gocce<\/code>\u201c. 4) <code>mpstat -P TUTTI<\/code> e <code>top<\/code> per l'attivit\u00e0 di ksoftirqd. 5) Metriche dell'applicazione (numero di connessioni attive, ritrasmissioni con <code>ss -ti<\/code>). Antipattern che evito: anelli RX enormi (congestione nascosta), accensione\/spegnimento selvaggio di offload senza misurazioni, mescolanza di affinit\u00e0 fisse con irqbalance aggressivo, o RPS e RSS simultaneamente senza un'architettura target chiara. Ogni modifica viene confrontata con una misura prima\/dopo e con un breve protocollo.<\/p>\n\n<h2>Concetti esemplificativi per l'hosting web e le API<\/h2>\n\n<h3>Server di web hosting classico<\/h3>\n<p>Per molti piccoli siti web attivo <strong>irqbalance<\/strong>, Configuro diverse code e seleziono il governatore delle prestazioni. Misuro le latenze L7 durante i picchi e faccio attenzione ai picchi di pps, che si verificano principalmente con TLS e HTTP\/2. Se le code hardware non sono sufficienti, aggiungo RPS per una distribuzione aggiuntiva a livello software. Questa regolazione mantiene i tempi di risposta <strong>costante<\/strong>, anche se l'utilizzo complessivo della capacit\u00e0 appare moderato. Controlli regolari di <code>\/proc\/interruzioni<\/code> mi mostra se i singoli nuclei si stanno inclinando.<\/p>\n\n<h3>Proxy inverso ad alto carico o gateway API<\/h3>\n<p>Per i frontend con un numero elevato di connessioni, applico le code RX in modo mirato a determinati core e posiziono i proxy worker sui core vicini. Decido consapevolmente se irqbalance rimane attivo o se il pinning fisso offre risultati pi\u00f9 chiari. Se non ci sono code sufficienti, seleziono RPS\/XPS e calibro <strong>Coalescenza<\/strong>, per evitare le tempeste di IRQ. Questo mi permette di ottenere una bassa latenza con una velocit\u00e0 di trasmissione molto elevata e di tenere sotto controllo le latenze di coda. La documentazione di ogni modifica facilita le verifiche successive e mantiene il comportamento <strong>prevedibile<\/strong>.<\/p>\n\n<h2>Scelta del fornitore e criteri di hardware<\/h2>\n\n<p>Presto attenzione alle NIC con <strong>Multi-queue<\/strong>, latenza affidabile nella spina dorsale e versioni aggiornate del kernel della piattaforma. La topologia bilanciata delle CPU e la netta separazione NUMA impediscono agli interrupt di rete di raggiungere le zone di memoria remote. Per i progetti con alti tassi di pps, la scelta dell'infrastruttura onora ogni ora di messa a punto perch\u00e9 l'hardware fornisce riserve. Nei confronti pratici, ho lavorato bene con i provider che rivelano i profili delle prestazioni e forniscono impostazioni predefinite IRQ-friendly, come ad esempio provider come webhoster.de. Tali configurazioni mi consentono di utilizzare efficacemente il bilanciamento degli IRQ, l'RSS e l'affinit\u00e0 e di ridurre al minimo i tempi di risposta. <strong>stretto<\/strong> per tenere.<\/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\/05\/serverraum-performance-2468.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Procedura passo-passo per la propria messa a punto<\/h2>\n\n<p><strong>Fase 1:<\/strong> Determino lo stato attuale con <code>iperf3<\/code>, <code>sar<\/code>, <code>mpstat<\/code>, <code>nstat<\/code> e <code>ettool -S<\/code>, in modo da avere chiari i valori iniziali. <strong>Fase 2:<\/strong> Se irqbalance non \u00e8 in esecuzione, attivo il servizio, attendo sotto carico e confronto latenza, pps e cadute. <strong>Fase 3:<\/strong> Adeguo il numero di coda e la configurazione RSS ai core del nodo NUMA associato. <strong>Passo 4:<\/strong> Ho impostato il governor della CPU su \u201eperformance\u201c e ho assegnato i servizi centrali ai core appropriati. <strong>Passo 5:<\/strong> Solo allora modifico l'affinit\u00e0 manuale e il pinning NUMA se i valori misurati mostrano ancora colli di bottiglia. <strong>Passo 6:<\/strong> Verifico le tendenze nel corso dei giorni per classificare in modo affidabile i picchi di eventi, i backup o i picchi di marketing.<\/p>\n\n<h2>Riassumendo brevemente<\/h2>\n\n<p>Efficace <strong>Bilanciamento IRQ<\/strong> distribuisce il lavoro di rete tra i core adatti, riduce le latenze e previene le cadute a velocit\u00e0 elevate. In combinazione con NIC multi-queue, RSS\/RPS, un governor CPU adeguato e un'affinit\u00e0 di thread pulita, utilizzo in modo affidabile lo stack di rete. Valori misurati da <code>ettool -S<\/code>, <code>nstat<\/code>, <code>sar<\/code> e <code>iperf3<\/code> mi guidano passo dopo passo verso il mio obiettivo, invece di brancolare nel buio. Se si pensa alla topologia NUMA, al pinning IRQ e al posizionamento delle applicazioni, \u00e8 possibile ridurre al minimo i tempi di risposta. <strong>basso<\/strong> - anche durante i picchi di carico. Ci\u00f2 significa che l'hosting ad alto carico rimane sensibilmente reattivo senza bruciare inutili riserve di CPU.<\/p>","protected":false},"excerpt":{"rendered":"<p>Imparate a migliorare le prestazioni di rete dei vostri server Linux e a rendere pi\u00f9 efficienti le configurazioni di hosting concentrandovi sul bilanciamento degli IRQ dei server.<\/p>","protected":false},"author":1,"featured_media":19362,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19369","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":"105","_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 IRQ","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":"19362","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/19369","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=19369"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/19369\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/19362"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=19369"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=19369"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=19369"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}