{"id":21057,"date":"2026-08-27T11:49:04","date_gmt":"2026-08-27T09:49:04","guid":{"rendered":"https:\/\/webhosting.de\/receive-side-scaling-rss-10g-25g-linux-server-optimierung-bitrate\/"},"modified":"2026-08-27T11:49:04","modified_gmt":"2026-08-27T09:49:04","slug":"receive-side-scaling-rss-10g-25g-ottimizzazione-server-linux-bitrate","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/receive-side-scaling-rss-10g-25g-linux-server-optimierung-bitrate\/","title":{"rendered":"Receive Side Scaling a 10 e 25 Gbit\/s: ottimizzazione delle prestazioni per le moderne reti di server Linux"},"content":{"rendered":"<p><strong>Receive Side Scaling<\/strong> distribuisce in modo mirato il traffico di rete su pi\u00f9 core tramite collegamenti a 10 e 25 Gbit\/s, consentendo ai server Linux di gestire elevate velocit\u00e0 di trasmissione con bassa latenza. Vi mostrer\u00f2 in modo pratico come attivo RSS, che <strong>Spunti<\/strong> sulla mappa di Core, evitando cos\u00ec colli di bottiglia a livello di interrupt e di hit della cache.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<p>Riassumo brevemente gli aspetti pi\u00f9 importanti, in modo che tu possa pianificare rapidamente i prossimi passi.<\/p>\n<ul>\n  <li><strong>Distribuzione del carico<\/strong>: I pacchetti vengono distribuiti su pi\u00f9 core attraverso diverse code.<\/li>\n  <li><strong>Localit\u00e0 della cache<\/strong>: Un flusso rimane sempre sulla stessa coda.<\/li>\n  <li><strong>Hashing<\/strong>: L'hash a 4 elementi distribuisce i flussi in modo uniforme tra le code.<\/li>\n  <li><strong>affinit\u00e0<\/strong>: Una mappatura mirata degli IRQ riduce le latenze.<\/li>\n  <li><strong>Scala<\/strong>: A partire da 10\/25 Gbit\/s, RSS garantisce un\u2019elevata velocit\u00e0 di trasmissione.<\/li>\n<\/ul>\n<p>Questi punti sono strettamente interconnessi e costituiscono la <strong>Prestazioni<\/strong> su carichi di lavoro reali. Do la priorit\u00e0 innanzitutto al numero corretto di code, poi alla <strong>CPU<\/strong>-Affinit\u00e0. Successivamente controllo i parametri hash e le impostazioni di precisione.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/servernetzwerk-performance-2947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cosa offre il Receive Side Scaling<\/h2>\n\n<p>RSS suddivide la ricezione dei pacchetti in pi\u00f9 <strong>Code di ricezione<\/strong>, che assegno a specifici core della CPU, in modo che nessun singolo core diventi un collo di bottiglia. Ci\u00f2 riduce i picchi di interrupt \u201chard\u201d e uniforma l\u2019elaborazione tramite SoftIRQ, riducendo i picchi di latenza e aumentando la velocit\u00e0 di elaborazione. Ogni coda genera i propri interrupt, che associo in modo fisso a determinati core per mantenere la coerenza dei percorsi dei dati. Questa coerenza favorisce la <strong>Cache<\/strong>-Localit\u00e0, poich\u00e9 un flusso incontra sempre lo stesso nucleo. \u00c8 proprio questa interazione che, in presenza di elevati tassi di PPS, si traduce direttamente in un\u2019efficienza misurabile.<\/p>\n\n<h2>Ecco come funziona tecnicamente l'RSS<\/h2>\n\n<p>Il NIC crea, a partire dall'IP di origine\/destinazione e dalla porta di origine\/destinazione, un <strong>Hash<\/strong> e lo utilizza come indice per la tabella di indirezione, che punta alle code. In questo modo, i pacchetti di un flusso finiscono sempre nella stessa coda e rimangono quindi associati allo stesso kernel. I diversi flussi si distribuiscono in modo uniforme, a condizione che le chiavi hash e i campi di protocollo siano configurati in modo appropriato. Il carico di lavoro si sposta quindi vicino alla <strong>Hardware<\/strong>, il che riduce il carico di bilanciamento del kernel e diminuisce l'overhead. \u00c8 proprio quello che voglio, per mantenere basso il numero di pacchetti elaborati per core a 10G\/25G.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linuxnetzwerke_tuning4683.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Perch\u00e9 l'RSS conta a partire da 10 e 25 Gbit\/s<\/h2>\n\n<p>A 1 Gbit\/s, spesso basta un singolo <strong>Nucleo<\/strong> il carico dei pacchetti, ma a partire da 10 Gbit\/s l\u2019equilibrio si altera rapidamente. I pacchetti di piccole dimensioni fanno aumentare il numero di PPS, per cui un core raggiunge rapidamente il 100% di carico e si verificano dei drop. Proprio in quel momento l\u2019RSS agisce come un moltiplicatore della larghezza di banda utilizzabile. Distribuisco il carico su pi\u00f9 <strong>Nuclei<\/strong>, riduce i cambi di contesto e mantiene le curve di latenza pi\u00f9 stabili. Il risultato: solo con un RSS pulito la velocit\u00e0 effettiva si avvicina alla velocit\u00e0 di collegamento.<\/p>\n\n<h2>Configurare RSS sul server Linux<\/h2>\n\n<p>Su Linux gestisco i feed RSS principalmente tramite <strong>ettool<\/strong>, le opzioni del driver e sysfs, affinch\u00e9 le funzionalit\u00e0 della scheda di rete vengano effettivamente sfruttate. Per prima cosa rilevo il numero massimo di canali RX, poi imposto un numero di code adeguato alla CPU. Successivamente, verifico l\u2019hash RSS per TCP\/UDP e, facoltativamente, per VLAN o tunneling, in modo che i profili di carico rimangano distribuiti correttamente. Per il rumore di fondo della distribuzione degli interrupt mi aiuta <a href=\"https:\/\/webhosting.de\/it\/configurare-lirq-balance-su-linux-per-un-server\/\">Bilanciamento IRQ<\/a>, anche se preferisco fissare manualmente le code critiche. Ecco come le associo <strong>Spunti<\/strong> si adatti perfettamente alla topologia dell'host e impedisca spostamenti indesiderati.<\/p>\n\n<h2>Tabella di indirezione, chiave RSS e ottimizzazione dell'hash: comandi specifici<\/h2>\n\n<p>Per prima cosa controllo la configurazione corrente e la chiave della scheda di rete:<\/p>\n<pre><code>ethtool -x eth0 # Visualizza la tabella di indirezione (code di ricezione) e la chiave RSS\nethtool -n eth0 rx-flow-hash tcp4\nethtool -n eth0 rx-flow-hash udp4\n<\/code><\/pre>\n<p>Per ottenere una distribuzione pulita e uniforme, imposto la tabella di indirezione sul numero desiderato di code. Con 16 code, scelgo una mappatura uniforme:<\/p>\n<pre><code>ethtool -X eth0 equal 16  Distribuzione # uniforme su 16 code\n<\/code><\/pre>\n<p>Se necessario, adeguer\u00f2 i campi hash. Per TCP4 con quartette (s=IP sorgente, d=IP destinazione, f=porta sorgente, n=porta destinazione):<\/p>\n<pre><code>ethtool -N eth0 rx-flow-hash tcp4 sdfn\nethtool -N eth0 rx-flow-hash udp4 sdfn\nethtool -N eth0 rx-flow-hash tcp6 sdfn\nethtool -N eth0 rx-flow-hash udp6 sdfn\n<\/code><\/pre>\n<p>Alcuni driver consentono anche di impostare una propria chiave RSS (ad esempio, per una migliore distribuzione in casi particolari):<\/p>\n<pre><code>ethtool -X eth0 hkey   # solo se il driver\/la scheda di rete lo supportano\n<\/code><\/pre>\n\n<h2>Impostare correttamente l'affinit\u00e0 della CPU e il NUMA<\/h2>\n\n<p>Mappo ogni coda RX tramite <strong>Affinit\u00e0 IRQ<\/strong> Assegna le code ai core dedicati, tenendo conto della struttura NUMA, in modo che i dati transitino per brevi tratti attraverso il controller di memoria. Se la scheda di rete (NIC) \u00e8 sul nodo 0, associo anche le code principali ai core del nodo 0 e colloco i carichi di lavoro nelle vicinanze. Questa vicinanza riduce gli accessi a distanza e abbassa notevolmente le latenze di memoria. A tal fine \u00e8 utile un profilo per le code di produzione, nonch\u00e9 core separati per le attivit\u00e0 di gestione e di offload. Chi desidera approfondire l\u2019argomento trover\u00e0 indicazioni per la messa a punto in <a href=\"https:\/\/webhosting.de\/it\/server-irq-affinita-multicore-ottimizzazione-delle-prestazioni-di-rete\/\">Affinit\u00e0 IRQ<\/a>, per quanto riguarda la pianificazione per <strong>Core<\/strong> semplificato.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-server-network-tuning-2478.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Guida pratica sull'affinit\u00e0 IRQ: dagli IRQ all'assegnazione stabile dei core<\/h2>\n\n<p>Per prima cosa individuo quali IRQ appartengono alle code RX, quindi le assegno in modo fisso:<\/p>\n<pre><code>grep -E \"eth0.*Rx\" \/proc\/interrupts\ncat \/sys\/class\/net\/eth0\/device\/numa_node\n<\/code><\/pre>\n<p>Effettuo l'assegnazione tramite <code>smp_affinity_list<\/code>, cos\u00ec non devo fare calcoli complicati. Esempio: code RX da 0 a 7 sui core da 2 a 9:<\/p>\n<pre><code>Esempio #: assegnare gli IRQ ai core 2-9 (una riga per ogni IRQ)\necho 2  &gt; \/proc\/irq\/\/smp_affinity_list\necho 3  &gt; \/proc\/irq\/\/smp_affinity_list\necho 4  &gt; \/proc\/irq\/\/smp_affinity_list\n...\necho 9  &gt; \/proc\/irq\/\/smp_affinity_list\n<\/code><\/pre>\n<p>Importante: MSI-X deve essere attivo affinch\u00e9 ogni coda disponga dei propri interrupt. Se utilizzo il pinning manuale, blocco <code>irqbalance<\/code> per questi IRQ (ad esempio tramite blacklist) oppure disattivo il servizio in modo mirato sugli host con layout statico. Verifico inoltre il NUMA con <code>lscpu<\/code> e l'assegnazione PCIe, in modo da non creare percorsi cross-node.<\/p>\n\n<h2>Configurazione hash e protocolli<\/h2>\n\n<p>Definisco i campi hash in modo tale che i veri <strong>Traffico<\/strong>-Distribuire bene i modelli, invece di concentrarli su poche code. Per TCP\/UDP utilizzo il quadruplo, per IPv6 in modo simile, mentre per VXLAN o GRE prendo in considerazione campi aggiuntivi relativi all\u2019incapsulamento. Alcune schede di rete (NIC) offrono chiavi di hash configurabili, che adatto al carico di lavoro dominante. Non appena rilevo un accumulo di carico su singole code, adeguo la selezione delle chiavi di hash. Questa operazione richiede poco tempo, ma impedisce un <strong>squilibrio<\/strong> in presenza di un elevato numero di connessioni.<\/p>\n\n<h2>Coalescenza degli interrupt e PPS<\/h2>\n\n<p>Abbino l'RSS a un uso moderato <strong>Interruzione della coalescenza<\/strong>, per raggruppare il traffico ad alta intensit\u00e0 di PPS in batch gestibili. Ci\u00f2 riduce l\u2019overhead degli interrupt, ma non deve compromettere la latenza dei servizi pi\u00f9 sensibili. Per questo motivo misuro i tempi di andata e ritorno e modifico gradualmente i valori di coalescing. Chi gestisce carichi di storage o backup pu\u00f2 raggruppare i dati in modo pi\u00f9 marcato rispetto alle API L7 o al VoIP. In sintesi, bilancio <strong>Latenza<\/strong> rispetto alla portata, finch\u00e9 entrambi i valori non sono coerenti.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/performance_tuning_linux_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Il coalescente nella pratica: profili e punti di misurazione<\/h2>\n\n<p>Comincio con impostazioni predefinite moderate e cerco di individuare la configurazione ottimale per ogni carico di lavoro. Tre profili di partenza collaudati:<\/p>\n<ul>\n  <li>API\/Bassa latenza: <code>rx-usecs 2\u20136<\/code>, <code>rx-frames 16\u201332<\/code>, disattivato in modo adattivo<\/li>\n  <li>A tutto tondo: <code>rx-usecs 8\u201316<\/code>, <code>rx-frames 32\u201364<\/code>, adattivo a<\/li>\n  <li>All'ingrosso\/Stoccaggio: <code>24\u201348 rx-usecs<\/code>, <code>rx-frames 128\u2013256<\/code>, adattivo a<\/li>\n<\/ul>\n<pre><code>ethtool -c eth0\nethtool -C eth0 rx-usecs 12 rx-frames 64 adaptive-rx on\n<\/code><\/pre>\n<p>A tal fine misuro le latenze p95\/p99, il PPS, il carico della CPU per core e le ritrasmissioni. Non appena noto un aumento della varianza per API\/VoIP, procedo con <code>rx-usecs<\/code> di nuovo gi\u00f9. Per quanto riguarda lo storage, tendo ad aumentare la scalabilit\u00e0 tramite frame, per risparmiare sugli interrupt.<\/p>\n\n<h2>RSS in ambienti a 10 Gbit<\/h2>\n\n<p>Sulle schede di rete da 10G, di solito lavoro con valori compresi tra 8 e 16 <strong>Spunti<\/strong> per porta, a condizione che la CPU metta a disposizione un numero sufficiente di core. In questo modo, i server web, i gateway di archiviazione e gli host di virtualizzazione scalano in modo ottimale su numerose connessioni parallele. Assegno le code principali ai core liberi e poi misuro PPS, latenza e ritrasmissioni. Se si verificano perdite di pacchetti, controllo il coalescing, l\u2019hash e l\u2019utilizzo per ciascuna coda. Successivamente ottimizzo la <strong>affinit\u00e0<\/strong>, finch\u00e9 il carico di lavoro non appare uniforme.<\/p>\n\n<h2>RSS in configurazioni a 25 Gbit e Multi-25G<\/h2>\n\n<p>Con 25 Gbit\/s aumentano il PPS e il carico della bus, motivo per cui io <strong>NUMA<\/strong>-Presto maggiore attenzione alla gestione delle code e agli offload. Il Large Receive Offload (LRO) o l\u2019RSC possono ridurre il carico di pacchetti sullo stack, a condizione che le applicazioni lo consentano. Inoltre, controllo le lane PCIe per escludere eventuali colli di bottiglia al di fuori della rete. Negli host con pi\u00f9 collegamenti a 25G, separo rigorosamente le code e l\u2019affinit\u00e0 in base alle attivit\u00e0 e ai nodi. In questo modo utilizzo <strong>Larghezza di banda<\/strong> e i core in modo efficiente, senza incorrere in traffico tra nodi.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linuxnetztuning_7234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dettagli su hardware e driver: a cosa faccio attenzione<\/h2>\n\n<p>Non tutte le schede di rete si comportano allo stesso modo. Le generazioni Intel (ad es. ixgbe, i40e, ice) offrono funzionalit\u00e0 come Flow Director\/ATR, che associano in modo mirato i flussi alle code \u2013 utili quando voglio livellare i picchi di traffico. Mellanox mlx5 \u00e8 in grado di supportare aRFS a livello hardware, il che riduce il carico della CPU quando lo stack gestisce molti socket. Decido caso per caso se attivare queste funzioni e verifico se migliorano la distribuzione. Sui sistemi di routing\/NAT spesso disattivo LRO e utilizzo GRO per mantenere la coerenza delle intestazioni; su carichi di lavoro esclusivamente server, LRO\/GRO possono aiutare a smorzare la pressione PPS. Sono inoltre importanti un numero sufficiente di vettori MSI-X per coda e versioni corrette del firmware.<\/p>\n\n<h2>RSS nella virtualizzazione e nei container<\/h2>\n\n<p>Nell'hypervisor combino le risorse fisiche <strong>RSS<\/strong>-Code con vNIC compatibili con il multi-queue, come ad esempio virtio-net, affinch\u00e9 gli ospiti non subiscano colli di bottiglia artificiali. Presto attenzione al CPU-pinning delle VM e definisco la vicinanza NUMA delle loro vCPU alla scheda di rete fisica. In questo modo i dati rimangono in locale e l\u2019host paga meno per gli accessi alla memoria. Per i container, associo i pod critici ai core appropriati e mantengo le code dell\u2019host libere da carico di disturbo. Questo ordine aumenta la <strong>Efficienza<\/strong> nel caso dei microservizi, dove si generano molti piccoli flussi.<\/p>\n\n<h2>Come utilizzare correttamente SR-IOV e VF-RSS<\/h2>\n\n<p>Con SR-IOV assegno alle VM delle VF dedicate, che a loro volta possono fornire pi\u00f9 code e RSS. Prevedo un numero sufficiente di VF per ogni porta, prendo in considerazione la capacit\u00e0 MSI-X e assegno gli IRQ delle VF nella VM in base alle rispettive vCPU. Nelle macchine virtuali Linux attivo esplicitamente il Multi-Queue, altrimenti la vNIC rimane spesso a un solo livello:<\/p>\n<pre><code># come guest (esempio virtio-net)\nethtool -l eth0\nethtool -L eth0 combined 4\n<\/code><\/pre>\n<p>Distribuisco rigorosamente gli host con pi\u00f9 VF in base al nodo NUMA e al carico di lavoro, in modo che le macchine virtuali non si interferiscano a vicenda negli stessi percorsi RX fisici.<\/p>\n\n<h2>Monitoraggio e risoluzione dei problemi<\/h2>\n\n<p>Controllo il carico di lavoro per <strong>Coda<\/strong>, singoli kernel, perdite di pacchetti e ritrasmissioni, per individuare tempestivamente eventuali squilibri. Se un kernel si distacca dagli altri mentre gli altri rimangono inattivi, spesso l\u2019affinit\u00e0 o il numero di code non \u00e8 corretto. In questi casi controllo uno dopo l\u2019altro i campi hash, le maschere IRQ e i valori di coalescing. Inoltre, controllo il <a href=\"https:\/\/webhosting.de\/it\/softirq-cpu-hosting-rete-ottimizzazione-del-throughput-datacenter\/\">Carico SoftIRQ<\/a>, poich\u00e9 fornisce indicazioni sulla presenza di effetti di spiazzamento. Solo quando questi segnali sembrano stabili, aumento il traffico o espando <strong>Spunti<\/strong> continuare.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/servernetzwerk-optimierung-4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>RPS, RFS e XPS: estensioni software per RSS<\/h2>\n\n<p>Se una scheda di rete ha solo poche code o se utilizzo il bonding\/tunneling, integro RSS con <strong>RPS<\/strong> (Receive Packet Steering) e <strong>RFS<\/strong> (Receive Flow Steering). RPS distribuisce gli SoftIRQ tra i core, mentre RFS associa i flussi al core su cui \u00e8 attivo il socket corrispondente. Attivo entrambi in modo mirato:<\/p>\n<pre><code># Aumentare globalmente il numero di voci di flusso (RFS)\necho 32768 &gt; \/proc\/sys\/net\/core\/rps_sock_flow_entries\n\n# Impostare le CPU per RPS per ogni coda RX (maschera di esempio, da adattare!)\nfor f in \/sys\/class\/net\/eth0\/queues\/rx-*\/rps_cpus; do echo ffff &gt; \"$f\"; done\n\nImpostare la tabella dei flussi per coda RX # per RFS\nfor f in \/sys\/class\/net\/eth0\/queues\/rx-*\/rps_flow_cnt; do echo 4096 &gt; \"$f\"; done\n<\/code><\/pre>\n<p>Sul lato TX utilizzo <strong>XPS<\/strong> (Transmit Packet Steering), affinch\u00e9 i pacchetti in uscita vengano inviati dal core che li ha generati:<\/p>\n<pre><code>for f in \/sys\/class\/net\/eth0\/queues\/tx-*\/xps_cpus; do echo ffff &gt; \"$f\"; done\n<\/code><\/pre>\n<p>RPS\/RFS\/XPS richiedono un po' di risorse della CPU, ma sono utili quando mi mancano le code a livello hardware o quando voglio mantenere rigorosamente la localit\u00e0 dei socket.<\/p>\n\n<h2>Prestazioni Single-Flow, GRO\/TSO e Busy-Polling<\/h2>\n\n<p>Un singolo flusso rimane associato a un core per una buona ragione. Se voglio aumentare la larghezza di banda di un singolo flusso, ricorro agli offload (GRO\/TSO), a un\u2019elevata frequenza del core e a un coalescing ben calibrato. Per i percorsi in cui la latenza \u00e8 un fattore critico, \u00e8 possibile <strong>Sondaggio occupato<\/strong> aiutare:<\/p>\n<pre><code>Impostare un valore basso per # ed effettuare la misurazione\nsysctl -w net.core.busy_read=25\nsysctl -w net.core.busy_poll=25\n<\/code><\/pre>\n<p>Il \"busy polling\" riduce i cambi di contesto, ma occupa tempo di CPU. Lo attivo solo nei casi in cui le latenze p99 sono rilevanti e ne valuto sempre gli effetti sul carico complessivo e sulla latenza di coda. Di norma mantengo attivo il GRO sui server, mentre utilizzo l\u2019LRO a seconda del ruolo; nei middlebox adotto un approccio conservativo per non interferire con l\u2019elaborazione delle intestazioni e la coerenza degli hash.<\/p>\n\n<h2>Suggerimenti ed esempi: code, affinit\u00e0, comandi<\/h2>\n\n<p>Come punto di partenza scelgo un numero di code che sia adeguato alla <strong>CPU<\/strong> regola, poi osserva il carico per ciascuna coda e modificalo gradualmente. Con 10G spesso bastano 8\u201316 code, mentre con 25G tendo a impostare un numero pi\u00f9 alto, purch\u00e9 ci siano i core disponibili. Per l\u2019affinit\u00e0 utilizzo maschere ben definite per ogni IRQ, in modo da poter analizzare pi\u00f9 facilmente i percorsi in un secondo momento. La tabella seguente fornisce valori di riferimento sintetici, che successivamente verifico tramite misurazioni. Solo i risultati delle misurazioni determinano se <strong>di pi\u00f9<\/strong> aumenta o riduci.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Velocit\u00e0 di connessione<\/th>\n      <th>Code RX tipiche<\/th>\n      <th>Comandi di esempio<\/th>\n      <th>Note<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>10 Gbit\/s<\/td>\n      <td>8-16<\/td>\n      <td><code>ethtool -l eth0<\/code> | <code>ethtool -L eth0 rx 16<\/code><\/td>\n      <td><strong>Coalescenza<\/strong> mantenere un livello moderato, verificare la latenza L7<\/td>\n    <\/tr>\n    <tr>\n      <td>25 Gbit\/s<\/td>\n      <td>16\u201332+<\/td>\n      <td><code>grep . \/proc\/interrupts<\/code> | Maschere IRQ tramite <code>eco<\/code><\/td>\n      <td><strong>NUMA<\/strong> tenere presente, verificare le linee PCIe<\/td>\n    <\/tr>\n    <tr>\n      <td>Multi-25G<\/td>\n      <td>Per ogni porta separatamente<\/td>\n      <td>Attivare la funzione multi-queue della vNIC (ad es. virtio)<\/td>\n      <td>Code su core e <strong>Carichi di lavoro<\/strong> dividere<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Questi valori di riferimento costituiscono solo il punto di partenza, non l'obiettivo, poich\u00e9 i carichi di lavoro variano notevolmente. Registro le modifiche, effettuo misurazioni prima e dopo l\u2019adeguamento e, per il resto, mantengo l\u2019ambiente invariato. Non appena il sistema rimane stabile sotto carico di produzione, blocco la configurazione. Successivamente, ripeto le misurazioni in seguito ad aggiornamenti del kernel o dei driver. In questo modo mi attengo a <strong>RSS<\/strong> senza deviazioni dalla rotta e con risultati sicuri e riproducibili.<\/p>\n\n<h2>Ostacoli tipici e contromisure<\/h2>\n\n<p>Troppo pochi <strong>Spunti<\/strong> I singoli core vengono sovraccaricati, mentre un numero eccessivo aumenta il carico amministrativo e compromette la percentuale di hit della cache. Un\u2019affinit\u00e0 non ottimale sposta gli interrupt su core gi\u00e0 sovraccarichi o su nodi NUMA errati. Anche un hash inadeguato fa s\u00ec che i flussi dominanti intasino le code. Risolvo il problema passo dopo passo: regolo il numero di code, correggo l\u2019affinit\u00e0, espando i campi hash e ottimizzo il coalescing. Documento ogni modifica con <strong>Metriche<\/strong>, prima di passare alla leva successiva.<\/p>\n\n<h2>Scenari pratici<\/h2>\n\n<p>Un server di archiviazione con 10G raggiunge rapidamente valori compresi tra 8 e 12 <strong>Spunti<\/strong> oltre a un coalescing moderato, per garantire il corretto svolgimento dei trasferimenti in blocco. Un server API con un numero elevato di connessioni richiede spesso campi hash pi\u00f9 precisi e una minore latenza negli interrupt. Gli host di virtualizzazione traggono notevoli vantaggi quando la funzione vNIC Multi-Queue \u00e8 attiva sul lato guest e si adatta al layout dell\u2019host. I carichi di lavoro dei container funzionano in modo pi\u00f9 fluido quando i pod critici vengono eseguiti vicino alla scheda di rete e alla memoria NUMA. Estendo questi modelli a seconda della situazione, utilizzando <strong>PPS<\/strong>, confronta le ritrasmissioni e la distribuzione delle code.<\/p>\n\n<h2>Il vantaggio delle piattaforme efficienti<\/h2>\n\n<p>Configurazioni di hosting con <strong>RSS<\/strong>, le schede di rete multi-queue e un\u2019affinit\u00e0 ben gestita garantiscono riserve tangibili in caso di picchi di carico. Chi valuta le offerte di server dovrebbe informarsi in modo mirato sulla funzionalit\u00e0 multi-queue, sul NUMA-pinning e sul monitoraggio. Un fornitore che attua in modo evidente questi aspetti ottiene spesso curve di throughput notevolmente migliori. Per soluzioni di server e hosting ad alte prestazioni, consiglio vivamente webhoster.de. Questo orientamento ripaga in <strong>Prestazioni<\/strong> e stabilit\u00e0, soprattutto in presenza di numerosi flussi paralleli.<\/p>\n\n<h2>Sintesi per la pratica<\/h2>\n\n<p>Attivo <strong>Ricevere<\/strong> Side Scaling: imposta un numero ragionevole di code, associa gli IRQ ai core appropriati e verifica la configurazione dell\u2019hash. Successivamente ottimizzo il coalescing in funzione della latenza, prendo in considerazione la vicinanza NUMA e distribuisco i carichi di lavoro in modo coerente. Nella virtualizzazione utilizzo il multi-queue fino ai sistemi guest e mantengo sincronizzati il pinning e l\u2019affinit\u00e0. Le misurazioni relative a PPS, carico delle code, ritrasmissioni e latenza determinano il passo successivo. Chi procede in questo modo sfrutta appieno le capacit\u00e0 di 10G e 25G, mantenendo <strong>Latenza<\/strong> nell'ambito di tale contesto e ottiene in modo affidabile un ritorno dalla rete.<\/p>","protected":false},"excerpt":{"rendered":"<p>Il Receive Side Scaling ottimizza le reti da 10G e 25G distribuendo i pacchetti su pi\u00f9 core della CPU. Scopri come configurare l'RSS sul server Linux per ottenere le massime prestazioni dalla tua configurazione. Focus: il Receive Side Scaling in ambienti ad alta velocit\u00e0.<\/p>","protected":false},"author":1,"featured_media":21050,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21057","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":"136","_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":"receive side scaling","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":"21050","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21057","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=21057"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21057\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21050"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21057"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21057"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21057"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}