{"id":21143,"date":"2026-08-29T15:03:43","date_gmt":"2026-08-29T13:03:43","guid":{"rendered":"https:\/\/webhosting.de\/linux-socket-backlog-richtig-dimensionieren-tcp-tuning-netzwerkoptimierung\/"},"modified":"2026-08-29T15:03:43","modified_gmt":"2026-08-29T13:03:43","slug":"dimensionamento-corretto-del-backlog-dei-socket-linux-ottimizzazione-tcp-ottimizzazione-della-rete","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/linux-socket-backlog-richtig-dimensionieren-tcp-tuning-netzwerkoptimierung\/","title":{"rendered":"Dimensionare correttamente il backlog dei socket Linux per ottenere le massime prestazioni di rete"},"content":{"rendered":"<p>Ti mostrer\u00f2 concretamente come <strong>Backlog di Linux<\/strong> dimensionare correttamente, in modo che le connessioni in entrata vengano gestite in modo ottimale e accettate rapidamente. In questo modo otterrai una <strong>costante<\/strong> Prestazioni di rete anche in caso di picchi di carico, senza che le richieste rimangano in sospeso o vengano rifiutate.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<p>Prima di approfondire l'argomento, riassumo i seguenti punti chiave come punto di partenza.<\/p>\n<ul>\n  <li><strong>Coda di accettazione<\/strong> dimensionare in modo mirato, senza confondere la coda SYN.<\/li>\n  <li><strong>somaxconn<\/strong> imposta il limite massimo rigido per il backlog di list()\u2011.<\/li>\n  <li><strong>tcp_max_syn_backlog<\/strong> protegge gli handshake in caso di picchi di traffico.<\/li>\n  <li><strong>min(backlog, somaxconn)<\/strong> determina il valore effettivo.<\/li>\n  <li><strong>Monitoraggio<\/strong> e i test di carico guidano ogni adeguamento.<\/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\/08\/linux-socket-backlog-5609.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Come funziona il backlog dei socket in Linux<\/h2>\n\n<p>Un socket server cambia con <strong>listen()<\/strong> entra in modalit\u00e0 di ascolto e riceve cos\u00ec un valore di backlog che memorizza temporaneamente le connessioni gi\u00e0 stabilite fino a quando l'applicazione non le richiama tramite <strong>accept()<\/strong> si fa carico. I moderni kernel Linux utilizzano questo valore esclusivamente per la coda di accettazione, mentre le connessioni semi-aperte durante l\u2019handshake finiscono nella coda SYN. Separo rigorosamente queste due code per poter attribuire correttamente causa ed effetto ed evitare di intervenire sui parametri sbagliati. La coda di accettazione impedisce i traboccamenti a breve termine quando l\u2019applicazione non accetta immediatamente le connessioni, mentre la coda SYN gestisce gli handshake in un breve intervallo di tempo. Chi ignora questa semantica, ottimizza in base a <strong>falso<\/strong> Luogo e spreca preziose riserve.<\/p>\n\n<h2>Perch\u00e9 la misura giusta influisce direttamente sulle prestazioni<\/h2>\n\n<p>La dimensione del backlog determina il numero di sessioni completamente stabilite che possono rimanere in attesa di accettazione, il che <strong>Tempo di risposta<\/strong> influisce sulla creazione della connessione. Se la coda di accettazione \u00e8 piena, il kernel rifiuta nuovi tentativi o li ritarda in modo evidente, il che si traduce in errori sporadici e avvii di connessione lenti. In linea di massima, vale la seguente approssimazione: tasso massimo di accettazione \u2248 dimensione della coda divisa per il tempo medio di permanenza per ogni voce. Se le richieste vengono elaborate in modo molto rapido e in grandi quantit\u00e0, cresce l\u2019importanza di una coda di accettazione sufficientemente dimensionata. Per quanto riguarda i pacchetti, vale la pena dare un\u2019occhiata a <a href=\"https:\/\/webhosting.de\/it\/server-code-di-pacchetti-stabilita-della-rete-ottimizzazione-dellhosting-latenza\/\">Code dei pacchetti del server<\/a>, perch\u00e9 l\u00ec si trova il livello di buffer successivo, che includo nella messa a punto e che coordino con la strategia di gestione del backlog.<\/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_socket_backlog_opt_8492.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Parametri del kernel: somaxconn e tcp_max_syn_backlog<\/h2>\n\n<p>Ai fini del backlog effettivo non conta solo il valore in <strong>listen()<\/strong>, poich\u00e9 il kernel ne limita rigidamente il valore massimo tramite net.core.somaxconn. Inoltre, net.ipv4.tcp_max_syn_backlog controlla il numero di handshake semi-aperti, il che \u00e8 fondamentale soprattutto in caso di picchi di carico o modelli simili a attacchi DDoS. In pratica vale una semplice regola: backlog effettivo = min(backlog, somaxconn), cosa che tengo sempre presente ogni volta che effettuo una regolazione. I valori predefiniti conservativi sono stati storicamente bassi, il che fa s\u00ec che i moderni servizi web e API raggiungano rapidamente dei colli di bottiglia. Scelgo quindi somaxconn in modo tale che le connessioni accettate abbiano un buffer sufficiente e regolo tcp_max_syn_backlog di conseguenza, affinch\u00e9 gli handshake non vadano in overflow e i client legittimi possano passare rapidamente.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametri<\/th>\n      <th>Scopo<\/th>\n      <th>Verificare<\/th>\n      <th>Valori iniziali predefiniti<\/th>\n      <th>Suggerimento<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>net.core.somaxconn<\/strong><\/td>\n      <td>Limite massimo per la coda di accettazione e, di conseguenza, per il backlog di `listen()`<\/td>\n      <td>sysctl net.core.somaxconn<\/td>\n      <td>Da 128 a 4096+, a seconda del kernel<\/td>\n      <td>Backlog effettivo = min(backlog dell'app, somaxconn)<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.ipv4.tcp_max_syn_backlog<\/strong><\/td>\n      <td>Limite per le connessioni semi-aperte (SYN-Queue)<\/td>\n      <td>sysctl net.ipv4.tcp_max_syn_backlog<\/td>\n      <td>Da 256 a 8192+ a seconda dell'applicazione<\/td>\n      <td>Combinare con i cookie SYN per attenuare i picchi di traffico<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.core.netdev_max_backlog<\/strong><\/td>\n      <td>Buffer per i pacchetti in entrata nel percorso SoftIRQ<\/td>\n      <td>sysctl net.core.netdev_max_backlog<\/td>\n      <td>Da 1000 a 5000+, a seconda della scheda di rete\/IRQ<\/td>\n      <td>Valutare insieme ai buffer di ricezione\/invio<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Valori indicativi in base al profilo di carico e alla latenza<\/h2>\n\n<p>Dimensiono la coda di accettazione in base al valore previsto <strong>profilo di carico<\/strong> e dalla durata media di elaborazione delle richieste dell\u2019applicazione. Per i servizi di moderata intensit\u00e0, spesso sono sufficienti valori compresi tra 256 e 1024, mentre le API o gli shop molto trafficati traggono vantaggio da valori compresi tra 2048 e 8192, purch\u00e9 l\u2019hardware e l\u2019architettura del server web lo consentano. La presenza di molte richieste brevi justifica valori pi\u00f9 elevati, poich\u00e9 un numero maggiore di connessioni rimane in attesa per brevi periodi e viene comunque inoltrato rapidamente. Le sessioni di lunga durata richiedono piuttosto un numero ottimizzato di worker e percorsi di I\/O, anzich\u00e9 code sempre pi\u00f9 grandi. Tengo sotto controllo l\u2019interazione con gli scheduler della CPU, la distribuzione degli IRQ e il percorso di accettazione dello spazio utente, in modo che la coda non debba essere l\u2019unico strumento a cui ricorrere.<\/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-socket-backlog-netzwerk-4421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Misurare lo stato attuale e individuare i colli di bottiglia<\/h2>\n\n<p>Prima di modificare i valori, misuro l'utilizzo della coda con <strong>ss<\/strong> oppure uso netstat e controllo se ci sono anomalie nelle code Recv\/Send. Le statistiche del kernel e i messaggi dmesg forniscono informazioni su overflow delle liste, pacchetti persi o perdite di backlog, che metto in correlazione temporale con i picchi di carico. Analizzo i log del server web e dei proxy a monte per individuare i tassi di errore nella creazione delle connessioni e nei tentativi di riconnnessione. Parallelmente, monitoro il carico della CPU, il bilanciamento degli IRQ e il comportamento dello scheduler, in modo da non trascurare eventuali colli di bottiglia in altri livelli. Solo dopo aver compreso la situazione, pianifico i passi successivi per un intervento mirato <strong>Sintonizzazione<\/strong>.<\/p>\n\n<h2>Analisi approfondita: indicatori, tipi di errore e percorso diagnostico<\/h2>\n<p>Per una diagnosi precisa, controllo i contatori del kernel in \/proc\/net\/netstat. Nella riga TcpExt mi interessano in particolare i valori di ListenOverflows e ListenDrops (coda di accettazione) nonch\u00e9 SyncookiesSent\/SyncookiesRecv (fase SYN). Se i ListenOverflows aumentano, significa che la coda di accettazione \u00e8 troppo piccola oppure che l\u2019applicazione accetta le richieste troppo lentamente. Se i contatori Syncookies aumentano, significa che la coda SYN \u00e8 satura o che il servizio \u00e8 soggetto ad attacchi aggressivi. Con il comando `ss -ltn` verifico il backlog attualmente configurato per ciascuna porta e capisco se l\u2019applicazione trasmette effettivamente al kernel il valore desiderato. Messaggi dmesg come \u201eTCP: request_sock_queue is full\u201c indicano un overflow della coda SYN, mentre \u201eTCP: listen overflow\u201c rimanda alla coda di accettazione. Metto a confronto questi indicatori con le metriche di monitoraggio (latenze, tassi di errore, tentativi di riprova), in modo da poter intervenire con precisione.<\/p>\n<p>In caso di picchi di breve durata, creo serie temporali ad alta risoluzione. Correlando il livello massimo di riempimento della coda di accettazione con la latenza di accettazione nello spazio utente. Facoltativamente, utilizzo tracce basate su eBPF per profilare i tempi di attesa di Accept e i wakeup. Ci\u00f2 risulta particolarmente utile quando sono presenti molti listener, affinit\u00e0 di processo o contese sui lock e gli effetti non possono essere spiegati esclusivamente tramite i contatori.<\/p>\n\n<h2>Ottimizzazione graduale con cicli di misurazione<\/h2>\n\n<p>Inizio documentando lo stato attuale, annotando i valori predefiniti esistenti e le caratteristiche di carico attuali in <strong>ore di punta<\/strong>. Successivamente aumento moderatamente somaxconn e il backlog dell'applicazione, in circa due o tre fasi, e osservo ogni volta i tassi di errore, le latenze e i tempi di accettazione. Successivamente, verifico tcp_max_syn_backlog e i SYN-cookie, nel caso in cui gli handshake falliscano gi\u00e0 prima della coda di accettazione. Per ogni livello eseguo test di carico riproducibili e mi affido a metriche oggettive anzich\u00e9 all\u2019intuito. L\u2019impostazione ottimale emerge da un ciclo di misurazione in cui integro sistematicamente i feedback provenienti dal monitoraggio e dal profiling dell\u2019applicazione nella fase successiva <strong>Personalizzazione<\/strong> condanni.<\/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\/linuxsocketbacklognetzwerk5234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configurazione dell'applicazione e strategia di accettazione<\/h2>\n\n<p>Verifico le impostazioni del backlog dei servizi server, come Apache, NGINX o i server delle applicazioni, per evitare che un valore predefinito troppo basso comprometta l\u2019intero <strong>coda<\/strong> limita. Alcuni framework impostano valori predefiniti o ignorano i parametri elevati finch\u00e9 non viene impostata esplicitamente un\u2019opzione. Nei casi in cui siano disponibili molti core della CPU, integro il concetto tramite <a href=\"https:\/\/webhosting.de\/it\/reuseport-linux-server-web-ottimizzazione-delle-prestazioni-core\/\">SO_REUSEPORT<\/a>, in modo che pi\u00f9 listener eseguano parallelamente la funzione `accept()` sulla stessa porta. In questo modo riduco sensibilmente il tempo di accettazione, il che riduce il tempo medio di permanenza nella coda di accettazione. \u00c8 importante, tuttavia, adeguare di conseguenza eventuali limiti relativi ai descrittori di file aperti e ai processi worker, in modo da evitare la creazione di un nuovo collo di bottiglia nello spazio utente.<\/p>\n\n<h2>Applicazione nei server e nei framework pi\u00f9 diffusi<\/h2>\n<p>In pratica, controllo il backlog effettivo per ogni servizio: NGINX consente di specificare il backlog nel blocco `listen`; inoltre, ci sono `accept_mutex` e `worker_processes`, che determinano la velocit\u00e0 di accettazione. Con Apache imposto ListenBacklog (per ogni vHost\/Bind) e mi assicuro che l\u2019MPM (ad es. event) metta a disposizione un numero sufficiente di worker. In HAProxy definisco il backlog tramite le opzioni bind e, parallelamente, regolo tune.maxaccept e il numero di processi\/thread. Negli stack Java (Netty, Undertow, Tomcat) \u00e8 solitamente presente una propriet\u00e0 soBacklog; Node.js\/Libuv accetta un parametro backlog in server.listen(), che senza un\u2019impostazione esplicita \u00e8 spesso inferiore a somaxconn. In Go, net.Listen o http.Server utilizzano i valori predefiniti del sistema operativo; in questo caso prendo maggiormente in considerazione un valore sufficiente di somaxconn, poich\u00e9 il livello dell\u2019applicazione raramente imposta un proprio backlog.<\/p>\n<p>Testo ogni servizio con serie di connessioni brevi e intense (ad esempio senza Keep-Alive) per verificare la resilienza del backlog. Solo quando la stabilit\u00e0 rimane costante anche in condizioni di picco, riprendo a utilizzare tempi di Keep-Alive pi\u00f9 lunghi e il riutilizzo delle connessioni nell'uso quotidiano, al fine di risparmiare risorse.<\/p>\n\n<h2>SO_REUSEPORT: parallelizzazione senza contesa<\/h2>\n<p>Con SO_REUSEPORT distribuisco le connessioni in entrata su pi\u00f9 socket listener, in genere uno per worker\/core della CPU. Ogni socket dispone di una propria coda di accettazione con un proprio backlog, il che moltiplica di fatto la capacit\u00e0 complessiva. \u00c8 fondamentale che tutti i listener siano configurati in modo identico (stessi valori di backlog, stesse priorit\u00e0), affinch\u00e9 il kernel distribuisca equamente il carico e non si verifichino squilibri. Controllo se i singoli worker sono sovraccarichi o sottoutilizzati e regolo il numero di processi o l\u2019affinit\u00e0 della CPU. In pratica, questa strategia riduce significativamente la contesa dei lock nel percorso di accettazione e riduce i picchi di wakeup, livellando cos\u00ec le latenze.<\/p>\n\n<h2>TCP_DEFER_ACCEPT, dati anticipati e momento dell'accettazione<\/h2>\n<p>Tramite TCP_DEFER_ACCEPT posso impostare il kernel in modo che la funzione accept() si attivi solo quando sono gi\u00e0 arrivati dati utili. In questo modo si riduce il numero di wakeup inutili (client che si connettono ma non inviano nulla) e il tempo di permanenza nella coda di accettazione risulta minore. Utilizzo questa opzione con cautela, poich\u00e9 i timeout a livello di applicazione, il comportamento dei middlebox e gli stack dei client possono interagire tra loro. I carichi di lavoro passivi (ad es. protocolli che inviano inizialmente dati dal server) ne traggono meno vantaggio; al contrario, i protocolli \"chatty\" con invii immediati da parte dei client possono essere alleggeriti. Pertanto, verifico sempre l\u2019impatto di DEFER_ACCEPT su ritentativi, timeout e latenze complessive prima di attivarlo in modo permanente. Inoltre, prevedo l\u2019uso di TCP_FASTOPEN solo se i costi dell\u2019handshake sono predominanti e l\u2019infrastruttura \u00e8 in grado di gestirli in modo stabile.<\/p>\n\n<h2>Sicurezza in caso di picchi di carico e flussi SYN<\/h2>\n\n<p>I valori elevati nella coda SYN li gestisco con <strong>Cookie SYN<\/strong> che rendono gli handshake pi\u00f9 gestibili quando si verificano molte connessioni incomplete. In caso di anomalie nella fase iniziale, aumento il valore di `tcp_max_syn_backlog` a passi moderati e osservo se i client legittimi ricominciano ad arrivare rapidamente. A ci\u00f2 aggiungo limiti di velocit\u00e0, strategie di backoff e parametri di ritrasmissione ben definiti, affinch\u00e9 modelli sfavorevoli non generino effetti a catena. Nel contesto fornir\u00f2 indicazioni dettagliate su come respingere in modo corretto i modelli ricorrenti. <a href=\"https:\/\/webhosting.de\/it\/syn-flood-protection-gestione-dei-socket-difesa-dei-server\/\">Protezione SYN-Flood<\/a> insieme. Le funzionalit\u00e0 di sicurezza sono pi\u00f9 efficaci se le coordino con le dimensioni del backlog, i buffer dei pacchetti e le prestazioni di accettazione delle app, e le verifico regolarmente rispetto a profili di test realistici.<\/p>\n\n<h2>Ottimizzazione del backlog nelle attivit\u00e0 quotidiane di hosting<\/h2>\n\n<p>Nell'ambito dell'hosting professionale, verifico sempre i valori del backlog insieme a <strong>somaxconn<\/strong>, tcp_max_syn_backlog, backlog dei dispositivi di rete e worker delle applicazioni. In questo modo mi assicuro che i tempi di risposta garantiti rimangano raggiungibili anche in caso di fluttuazioni del traffico. Documento tutti i parametri del kernel e dei servizi, in modo che gli audit, le routine SRE e i passaggi di consegne possano fare rapidamente chiarezza. Il monitoraggio invia allarmi in caso di livelli di riempimento delle code, errori di accettazione e tentativi di riprova, accelerando cos\u00ec le successive regolazioni di precisione. Chi confronta i pacchetti di hosting dovrebbe valutare, oltre alla CPU e alla RAM, anche questi dettagli di rete, poich\u00e9 hanno un impatto tangibile sui costi, sul time-to-first-byte e sul successo <strong>Sessioni<\/strong> hanno.<\/p>\n\n<h2>Evitare gli errori tipici<\/h2>\n\n<p>Un errore comune: aumento solo il backlog delle applicazioni, ma <strong>somaxconn<\/strong> troppo piccolo, per cui il limite massimo effettivo rimane invariato. Altrettanto insidiosa \u00e8 la confusione tra la coda Accept e quella SYN, che porta a correzioni errate. Valori estremamente elevati, se impostati senza una strategia, nascondono le debolezze dell\u2019applicazione, consumano memoria e rendono difficile l\u2019analisi delle cause. Se accept() non gestisce le connessioni con sufficiente rapidit\u00e0, la coda rimane piena nonostante i valori elevati e i client continuano ad attendere. Pertanto, verifico innanzitutto il percorso dello spazio utente, riduco al minimo la contesa dei blocchi, distribuisco il carico di lavoro tra i core e infine calibro le dimensioni del backlog <strong>Mirato<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-backlog-serverraum-9472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Container, macchine virtuali e orchestrazione<\/h2>\n<p>Negli ambienti virtualizzati e nei container vale quanto segue: il backlog effettivo dipende dal kernel dell\u2019host. Se imposto somaxconn nel container, l\u2019host deve consentirlo e renderlo persistente. In Kubernetes attivo esplicitamente i sysctl necessari e mi assicuro che le politiche di sicurezza lo consentano. Verifico inoltre i valori di ulimit (nofile) e i limiti dei cgroup, in modo che sia possibile aprire un numero elevato di socket contemporaneamente. Se \u00e8 presente un Ingress Controller o un NodePort a monte, dimensiono il suo backlog di ascolto allo stesso modo di quello dell\u2019applicazione vera e propria, in modo che il primo hop non rimanga il collo di bottiglia. Lo stesso vale per i bilanciatori di carico L3\/4 o i proxy: ogni livello dispone di code proprie, che considero nel loro insieme.<\/p>\n\n<h2>Pianificazione della capacit\u00e0: esempi di calcolo delle dimensioni del backlog<\/h2>\n<p>Effettuo il dimensionamento in tre fasi: (1) determinare la velocit\u00e0 massima di arrivo (Conn\/s) nei picchi, (2) misurare la latenza media di accettazione dell\u2019applicazione, (3) prevedere un margine di sicurezza. Esempio: se si verifica un picco di 10.000 Conn\/s e il tempo medio dall\u2019arrivo alla chiamata accept() \u00e8 di 3 ms, allora \u00e8 necessario bufferizzare in media, nel breve termine, 10.000 \u00d7 0,003 = 30 connessioni. Per i picchi e le fluttuazioni di distribuzione, scelgo un fattore compreso tra 5 e 10, ovvero 150\u2013300. Se pianifico inoltre pi\u00f9 listener tramite SO_REUSEPORT, la capacit\u00e0 scala in base al numero di listener. Per le richieste molto brevi (ad es. 5\u201320 ms) faccio calcoli pi\u00f9 prudenti, poich\u00e9 prevalgono le fluttuazioni statistiche. In caso di sessioni di lunga durata, do priorit\u00e0 al numero di worker, alla scalabilit\u00e0 di epoll e ai percorsi I\/O prima di aumentare ulteriormente i backlog.<\/p>\n<p>Calcolo inoltre il fabbisogno di memoria: ogni voce nella coda di accettazione occupa spazio nelle strutture del kernel. Valori molto elevati hanno quindi senso solo se anche la RAM disponibile, i descrittori di file e i worker dello spazio utente riescono a tenere il passo. L\u2019obiettivo non \u00e8 ottenere un buffer il pi\u00f9 grande possibile, ma uno sufficientemente grande da smussare i picchi senza sovraccaricare le altre risorse.<\/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\/linuxsocketbacklog1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gestione delle modifiche, persistenza e rollback<\/h2>\n<p>Separer\u00f2 i test dall'ambiente operativo: effettuer\u00f2 prima le regolazioni in un ambiente di staging con profili di carico rappresentativi, per poi procedere gradualmente al lancio in produzione. Scrivo i parametri del kernel in file sysctl.d dedicati, li documento indicando lo scopo e la data e ne verifico l'efficacia dopo il riavvio. Imposto i backlog dei servizi nel rispettivo file di configurazione e li blocco tramite la gestione della configurazione, in modo da evitare qualsiasi deriva. Per i sistemi critici stabilisco una finestra di rollback e, dopo l\u2019implementazione, monitoro attentamente gli overflow delle liste, le latenze di accettazione e i tassi di errore. Se si manifestano effetti collaterali (ad es. aumento del carico di memoria o saturazione dei thread), faccio un passo indietro e risolvo prima il nuovo collo di bottiglia.<\/p>\n\n<h2>Strumenti e procedure operative<\/h2>\n<p>Nelle mie procedure operative dispongo di una piccola serie di strumenti affidabili: ss\/netstat per visualizzare i socket in ascolto e i valori attuali del backlog, sysctl per la configurazione dei parametri, journalctl\/dmesg per i messaggi del kernel e uno strumento di stress test in grado di generare picchi di carico brevi, ripetibili e misurabili. Inoltre, utilizzo strumenti di esportazione dei processi che registrano il tempo di accettazione e i livelli di riempimento delle code, nonch\u00e9 profili di sistema (perf, eBPF) per approfondire, se necessario, il percorso di accettazione. Il monitoraggio raccoglie istogrammi relativi alle latenze di instaurazione della connessione, in modo da poter visualizzare non solo i valori medi, ma anche le distribuzioni e i valori P95\/P99: \u00e8 proprio l\u00ec che si nascondono i sintomi di code troppo piccole.<\/p>\n\n<h2>Lista di controllo per l'attuazione<\/h2>\n<ul>\n  <li>Rilevazione del profilo di carico: Conn\/s, ampiezza dei picchi, latenza di accettazione, quota di keep-alive.<\/li>\n  <li>Documentare i valori effettivi: somaxconn, tcp_max_syn_backlog, netdev-backlog, backlog dei servizi, nofile.<\/li>\n  <li>Verifica dei contatori del kernel: overflow\/perdite di liste, contatori Syncookie, messaggi dmesg.<\/li>\n  <li>Aumentare gradualmente il backlog: sincronizzazione tra applicazione e somaxconn, cicli di misurazione per ogni livello.<\/li>\n  <li>Proteggere la fase SYN: aumentare moderatamente il valore di tcp_max_syn_backlog, abilitare i SYN-cookie e monitorare la situazione.<\/li>\n  <li>Parallelizzazione: utilizzare SO_REUSEPORT, calibrare i worker e le affinit\u00e0.<\/li>\n  <li>Panoramica sul percorso dei pacchetti: ottimizzare il backlog netdev, il bilanciamento degli IRQ e i buffer di ricezione\/invio.<\/li>\n  <li>Persistenza e rollback: sysctl.d, gestione delle versioni, implementazione graduale, telemetria sotto controllo.<\/li>\n<\/ul>\n\n<h2>Sintesi per una rapida implementazione<\/h2>\n\n<p>Dimensiono il backlog in modo pragmatico: prima misuro, poi <strong>personalizzare<\/strong>, quindi ripetere la misurazione. Per molti server web e API, valori compresi tra 2048 e 8192 per `somaxconn`, abbinati a un\u2019impostazione adeguata dell\u2019applicazione, rappresentano un livello iniziale adeguato, che verifico tramite un test di carico. In caso di picchi di handshake, aumento gradualmente il valore di `tcp_max_syn_backlog` e attivo i SYN-cookie, in modo che i client legittimi non vengano rallentati. Parallelmente mi occupo del backlog netdev, dei buffer di ricezione\/invio, del bilanciamento IRQ e della strategia di accettazione nello spazio utente. In questo modo tengo sotto controllo l\u2019instaurazione delle connessioni, i tempi di risposta e i tassi di errore e utilizzo il <strong>Backlog di Linux<\/strong> come strumento efficace per garantire prestazioni costanti della rete.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scopri come dimensionare correttamente il backlog dei socket Linux e come migliorare in modo duraturo le prestazioni di rete dei tuoi server grazie a un ottimizzazione mirata del protocollo TCP.<\/p>","protected":false},"author":1,"featured_media":21136,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21143","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":"141","_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":"Linux Backlog","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":"21136","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21143","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=21143"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21143\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21136"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21143"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21143"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21143"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}