{"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":"linux-socket-backlog-correct-dimensioneren-tcp-tuning-netwerkoptimalisatie","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/linux-socket-backlog-richtig-dimensionieren-tcp-tuning-netzwerkoptimierung\/","title":{"rendered":"De Linux-socket-backlog correct dimensioneren voor maximale netwerkprestaties"},"content":{"rendered":"<p>Ik laat je concreet zien hoe je de <strong>Linux-achterstand<\/strong> op de juiste manier dimensioneren, zodat inkomende verbindingen goed worden opgevangen en snel worden verwerkt. Zo bereik je een <strong>constant<\/strong> Netwerkprestaties, zelfs bij pieken in de belasting, zonder dat verzoeken vastlopen of worden afgewezen.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<p>Ik vat de volgende kernpunten samen als uitgangspunt, voordat ik dieper op de materie inga.<\/p>\n<ul>\n  <li><strong>Accept-Queue<\/strong> doelgericht dimensioneren, de SYN-wachtrij niet verwarren.<\/li>\n  <li><strong>somaxconn<\/strong> stelt de strikte bovengrens in voor de backlog van `listen()`.<\/li>\n  <li><strong>tcp_max_syn_backlog<\/strong> beschermt handdrukken bij grote drukte.<\/li>\n  <li><strong>min(backlog, somaxconn)<\/strong> bepaalt de werkelijke waarde.<\/li>\n  <li><strong>Controle<\/strong> en belastingstests zijn bepalend voor elke aanpassing.<\/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>Hoe de Linux-socket-backlog werkt<\/h2>\n\n<p>Een serversocket schakelt over met <strong>listen()<\/strong> in de luistermodus en ontvangt daarbij een backlog-waarde die reeds tot stand gebrachte verbindingen in de buffer opslaat totdat de toepassing ze via <strong>accept()<\/strong> neemt over. Moderne Linux-kernels gebruiken deze waarde uitsluitend voor de Accept-wachtrij, terwijl halfopen verbindingen tijdens de handshake in de SYN-wachtrij terechtkomen. Ik houd deze twee wachtrijen strikt gescheiden, zodat ik oorzaak en gevolg correct aan elkaar kan koppelen en niet aan de verkeerde knoppen draai. De Accept-wachtrij voorkomt kortstondige overloop wanneer de app verbindingen niet onmiddellijk accepteert, terwijl de SYN-wachtrij handshakes gedurende een kort tijdsbestek verwerkt. Wie deze semantiek negeert, optimaliseert op de <strong>vals<\/strong> Plaats en verspilt waardevolle reserves.<\/p>\n\n<h2>Waarom de juiste maat direct tot betere prestaties leidt<\/h2>\n\n<p>De omvang van de backlog bepaalt hoeveel volledig tot stand gekomen sessies mogen wachten op acceptatie, wat de <strong>Reactietijd<\/strong> be\u00efnvloedt het tot stand brengen van een verbinding. Als de Accept-wachtrij vol is, weigert de kernel nieuwe pogingen of vertraagt deze merkbaar, wat zich uit in sporadische fouten en trage verbindingsopbouw. Als eenvoudige benadering geldt: maximale acceptatiesnelheid \u2248 wachtrijgrootte gedeeld door de gemiddelde verblijftijd per vermelding. Als verzoeken zeer kort en in grote hoeveelheden worden verwerkt, wordt het belang van een voldoende gedimensioneerde acceptatiewachtrij steeds groter. Wat de pakketten betreft, is het de moeite waard om te kijken naar <a href=\"https:\/\/webhosting.de\/nl\/server-pakketwachtrijen-netwerkstabiliteit-hosting-optimalisatie-latentie\/\">Serverpakketwachtrijen<\/a>, omdat daar de volgende bufferfase zit, die ik bij het afstemmen meeneem en afstem op de backlog-strategie.<\/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>Kernelparameters: somaxconn en tcp_max_syn_backlog<\/h2>\n\n<p>Voor de effectieve backlog telt niet alleen de waarde in <strong>listen()<\/strong>, omdat de kernel dit via `net.core.somaxconn` strikt begrenst. Daarnaast regelt `net.ipv4.tcp_max_syn_backlog` het aantal halfopen handshakes, wat vooral bij piekbelastingen of DDoS-achtige patronen van cruciaal belang is. In de praktijk geldt de eenvoudige regel: effectieve backlog = min(backlog, somaxconn), iets wat ik bij elke aanpassing in gedachten houd. Conservatieve standaardinstellingen bleken in het verleden aan de lage kant, waardoor moderne web- en API-diensten snel in knelpunten terechtkomen. Ik stel somaxconn daarom zo in dat geaccepteerde verbindingen voldoende bufferruimte hebben, en ik pas tcp_max_syn_backlog dienovereenkomstig aan, zodat handshakes niet overlopen en legitieme clients snel door kunnen komen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parameters<\/th>\n      <th>Doel<\/th>\n      <th>Controleren<\/th>\n      <th>Standaard beginwaarden<\/th>\n      <th>Tip<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>net.core.somaxconn<\/strong><\/td>\n      <td>Bovengrens voor de Accept-wachtrij en daarmee voor de backlog van `listen()`<\/td>\n      <td>sysctl net.core.somaxconn<\/td>\n      <td>128 tot 4096+, afhankelijk van de kernel<\/td>\n      <td>Effectieve backlog = min(app-backlog, somaxconn)<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.ipv4.tcp_max_syn_backlog<\/strong><\/td>\n      <td>Limiet voor halfopen verbindingen (SYN-wachtrij)<\/td>\n      <td>sysctl net.ipv4.tcp_max_syn_backlog<\/td>\n      <td>256 tot 8192+, afhankelijk van de toepassing<\/td>\n      <td>Combineren met SYN-cookies om pieken op te vangen<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.core.netdev_max_backlog<\/strong><\/td>\n      <td>Buffer voor inkomende pakketten in het SoftIRQ-pad<\/td>\n      <td>sysctl net.core.netdev_max_backlog<\/td>\n      <td>1000 tot 5000+, afhankelijk van NIC\/IRQ<\/td>\n      <td>Samen met de ontvangst- en verzendbuffers beoordelen<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Richtwaarden op basis van het belastingsprofiel en de latentie<\/h2>\n\n<p>Ik bepaal de omvang van de accept-wachtrij op basis van de verwachte <strong>lastprofiel<\/strong> en de gemiddelde verwerkingstijd van de applicatie. Voor diensten met een gemiddeld verkeer volstaan vaak waarden tussen 256 en 1024, terwijl drukbezochte API\u2019s of webwinkels baat hebben bij waarden tussen 2048 en 8192, mits de hardware en de webserverarchitectuur dit aankunnen. Veel korte verzoeken pleiten voor hogere waarden, omdat meer verbindingen kortstondig wachten en toch snel worden doorgegeven. Langdurige sessies hebben eerder een geoptimaliseerd aantal workers en IO-paden nodig in plaats van steeds grotere wachtrijen. Ik houd de interactie met CPU-schedulers, IRQ-verdeling en het userspace-accept-pad in de gaten, zodat de wachtrij niet als enige middel hoeft te dienen.<\/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>De huidige toestand meten en knelpunten opsporen<\/h2>\n\n<p>Voordat ik waarden wijzig, meet ik het gebruik van de wachtrij met <strong>ss<\/strong> of netstat en controleer de Recv-\/Send-wachtrijen op afwijkingen. Kernelstatistieken en dmesg-meldingen geven inzicht in lijstoverflows, drops of backlog-verliezen, die ik in de tijd in verband breng met piekbelastingen. Ik analyseer de logbestanden van de webserver en de upstream-proxy\u2019s om foutpercentages bij het tot stand brengen van verbindingen en herhalingspogingen te identificeren. Tegelijkertijd houd ik de CPU-belasting, de IRQ-balans en het gedrag van de scheduler in de gaten, zodat ik geen knelpunten in andere lagen over het hoofd zie. Pas als ik de situatie begrijp, plan ik de volgende stappen voor een doelgerichte <strong>Afstemmen<\/strong>.<\/p>\n\n<h2>Uitgebreide meting: kengetallen, foutpatronen en diagnosetraject<\/h2>\n<p>Voor een nauwkeurige diagnose bekijk ik de kernel-tellers onder \/proc\/net\/netstat. In de regel TcpExt ben ik vooral ge\u00efnteresseerd in ListenOverflows en ListenDrops (Accept-wachtrij) en in SyncookiesSent\/SyncookiesRecv (SYN-fase). Als ListenOverflows toenemen, is de Accept-wachtrij te klein of accepteert de app te traag. Als de Syncookies-tellers stijgen, is de SYN-wachtrij vol of worden er agressieve patronen op de dienst gericht. Met ss -ltn controleer ik per poort de momenteel geconfigureerde backlog en zie ik of de toepassing de gewenste waarde daadwerkelijk aan de kernel doorgeeft. Dmesg-meldingen zoals \u201eTCP: request_sock_queue is full\u201c duiden op een overlopende SYN-wachtrij, terwijl \u201eTCP: listen overflow\u201c verwijst naar de Accept-wachtrij. Ik houd deze indicatoren synchroon met statistieken uit de monitoring (latenties, foutpercentages, herpogingen), zodat ik doelgericht kan ingrijpen.<\/p>\n<p>Bij kortstondige pieken maak ik tijdreeksen met een hoge resolutie. Ik breng de maximale vullingsgraad van de Accept-wachtrij in verband met de Accept-latentie in de gebruikersruimte. Optioneel gebruik ik op eBPF gebaseerde traces om Accept-wachttijden en wake-ups te profileren. Dit is vooral nuttig wanneer er veel listeners, procesaffiniteiten of lock-contention een rol spelen en effecten niet uitsluitend via counters kunnen worden verklaard.<\/p>\n\n<h2>Stapsgewijze optimalisatie met meetlussen<\/h2>\n\n<p>Ik begin met het in kaart brengen van de huidige situatie, noteer de bestaande standaardinstellingen en de huidige belastingskarakteristiek in <strong>spitsuren<\/strong>. Daarna verhoog ik somaxconn en de applicatie-backlog geleidelijk, in ongeveer twee tot drie stappen, en houd ik telkens de foutpercentages, latenties en accept-tijden in de gaten. Vervolgens controleer ik tcp_max_syn_backlog en SYN-cookies, voor het geval handshakes al v\u00f3\u00f3r de accept-wachtrij mislukken. Voor elke stap voer ik reproduceerbare belastingstests uit en baseer ik me op vaste meetwaarden in plaats van op mijn intu\u00eftie. De beste instelling komt tot stand in een meetcyclus, waarbij ik feedback uit monitoring en app-profilering consequent verwerk in de volgende <strong>Aanpassing<\/strong> overtuig.<\/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>Toepassingsconfiguratie en acceptatiestrategie<\/h2>\n\n<p>Ik controleer de backlog-instellingen van de serverservices, zoals Apache, NGINX of applicatieservers, om te voorkomen dat een te lage standaardwaarde de gehele <strong>wachtrij<\/strong> beperkt. Sommige frameworks stellen hun eigen waarden in of negeren hoge parameters totdat een optie expliciet is ingesteld. Wanneer er veel CPU-kernen beschikbaar zijn, breid ik het concept uit via <a href=\"https:\/\/webhosting.de\/nl\/zo-reuseport-linux-webserver-prestatieoptimalisatie-core\/\">SO_REUSEPORT<\/a>, zodat meerdere listeners tegelijkertijd `accept()` op dezelfde poort kunnen uitvoeren. Hierdoor verkort ik de acceptatietijd aanzienlijk, wat de gemiddelde verblijftijd in de accept-wachtrij vermindert. Het blijft belangrijk dat ik eventuele limieten voor open bestandsdescriptoren en werkprocessen hierop afstem, zodat er geen nieuwe bottleneck in de gebruikersruimte ontstaat.<\/p>\n\n<h2>Toepassing in gangbare servers en frameworks<\/h2>\n<p>In de praktijk controleer ik de effectieve backlog per dienst: NGINX staat in het `listen`-blok een `backlog`-instelling toe; daarnaast zijn er `accept_mutex` en `worker_processes`, die de acceptatiesnelheid bepalen. Bij Apache stel ik ListenBacklog in (per vHost\/Bind) en zorg ik ervoor dat de MPM (bijv. event) voldoende workers beschikbaar heeft. In HAProxy bepaal ik de backlog via bind-opties en pas ik tegelijkertijd tune.maxaccept en het aantal processen\/threads aan. In Java-stacks (Netty, Undertow, Tomcat) is meestal een soBacklog-eigenschap aanwezig; Node.js\/Libuv accepteert een backlog-parameter in server.listen(), die zonder expliciete instelling vaak lager ligt dan somaxconn. In Go gebruiken net.Listen of http.Server de standaardinstellingen van het besturingssysteem; hier let ik extra op een voldoende hoge somaxconn, omdat de app-laag zelden een eigen backlog instelt.<\/p>\n<p>Ik test elke dienst met korte, intensieve reeksen verbindingen (bijvoorbeeld zonder Keep-Alive) om de veerkracht bij een backlog te controleren. Pas als de prestaties ook onder piekbelasting constant blijven, sta ik in het dagelijks gebruik weer langere Keep-Alive-tijden en het hergebruik van verbindingen toe om middelen te sparen.<\/p>\n\n<h2>SO_REUSEPORT: Parallelisatie zonder concurrentieproblemen<\/h2>\n<p>Met SO_REUSEPORT verdeel ik inkomende verbindingen over meerdere listener-sockets, doorgaans \u00e9\u00e9n per worker\/CPU-kern. Elke socket heeft zijn eigen accept-wachtrij met een eigen backlog, waardoor de totale capaciteit effectief wordt verveelvoudigd. Het is cruciaal dat alle listener-sockets identiek zijn geconfigureerd (dezelfde backlog-waarden, dezelfde prioriteiten), zodat de kernel de verbinding eerlijk verdeelt en er geen onevenwichtigheid ontstaat. Ik houd in de gaten of afzonderlijke workers over- of onderbelast zijn en pas het aantal processen of de CPU-affiniteit aan. In de praktijk vermindert deze strategie de lock-contention in het Accept-pad aanzienlijk en vermindert het wakeup-storms, wat de latentie afvlakt.<\/p>\n\n<h2>TCP_DEFER_ACCEPT, vroege gegevens en het tijdstip van acceptatie<\/h2>\n<p>Met TCP_DEFER_ACCEPT kan ik instellen dat de kernel accept() pas activeert als er al gebruiksgegevens zijn binnengekomen. Hierdoor neemt het aantal nutteloze wake-ups (clients die verbinding maken maar niets verzenden) af, en lijkt de verblijftijd in de accept-wachtrij korter. Ik gebruik deze instelling voorzichtig, omdat time-outs op applicatieniveau, het gedrag van middleboxes en clientstacks hierop van invloed kunnen zijn. Passieve workloads (bijv. protocollen die in eerste instantie servergegevens verzenden) profiteren hier minder van; omgekeerd kunnen \u2018chatty\u2019-protocollen, waarbij clients onmiddellijk gegevens verzenden, hierdoor worden ontlast. Ik controleer daarom altijd hoe DEFER_ACCEPT van invloed is op herhalingspogingen, time-outs en totale latenties, voordat ik deze optie permanent activeer. Daarnaast plan ik TCP_FASTOPEN alleen in als de handshake-kosten de overhand hebben en de infrastructuur hier stabiel mee omgaat.<\/p>\n\n<h2>Veiligheid bij piekbelastingen en SYN-overstromingen<\/h2>\n\n<p>Hoge waarden in de SYN-wachtrij vang ik op met <strong>SYN-cookies<\/strong> die de handshakes draaglijker maken wanneer er veel halfvoltooide verbindingen aankloppen. Bij afwijkingen in de ingangsfase verhoog ik `tcp_max_syn_backlog` in gematigde stappen en kijk ik of legitieme clients weer snel binnenkomen. Ik vul dit aan met rate-limits, backoff-strategie\u00ebn en nette retransmissieparameters, zodat ongunstige patronen geen domino-effecten veroorzaken. Gedetailleerde aanwijzingen voor het netjes afweren van terugkerende patronen vat ik in de context samen <a href=\"https:\/\/webhosting.de\/nl\/syn-flood-bescherming-socket-afhandeling-server-verdediging\/\">SYN-Flood-bescherming<\/a> samen. Beveiligingsfuncties zijn het meest effectief als ik ze afstem op de omvang van de backlog, pakketbuffers en de prestaties van App Accept, en ze regelmatig toets aan realistische testprofielen.<\/p>\n\n<h2>Backlog-optimalisatie in de dagelijkse hostingpraktijk<\/h2>\n\n<p>Bij professionele hosting controleer ik de backlog-waarden altijd samen met <strong>somaxconn<\/strong>, tcp_max_syn_backlog, netdev-backlog en applicatieworkers. Zo zorg ik ervoor dat de beloofde responstijden ook bij schommelingen in het verkeer haalbaar blijven. Ik documenteer alle kernel- en serviceparameters, zodat audits, SRE-routines en overdrachten snel duidelijkheid bieden. De monitoring geeft waarschuwingen bij wachtrijvullingen, ontvangstfouten en herpogingen, wat latere fijnafstemmingen versnelt. Wie hostingpakketten vergelijkt, moet naast CPU en RAM ook deze netwerkdetails beoordelen, omdat ze een merkbare invloed hebben op de kosten, de time-to-first-byte en het succes van <strong>Sessies<\/strong> hebben.<\/p>\n\n<h2>Typische fouten vermijden<\/h2>\n\n<p>Een veelvoorkomende misvatting: ik vergroot alleen de backlog van de toepassingen, maar laat <strong>somaxconn<\/strong> te klein, waardoor de effectieve bovengrens ongewijzigd blijft. Even verraderlijk is het door elkaar halen van de Accept- en SYN-wachtrij, wat tot onjuiste correcties leidt. Extreem hoge waarden zonder onderbouwing verhullen zwakke punten in de applicatie, verbruiken geheugen en bemoeilijken de oorzaakanalyse. Als accept() de verbindingen niet snel genoeg overneemt, blijft de wachtrij ondanks grote getallen vol en blijven clients wachten. Daarom controleer ik eerst het userspace-pad, minimaliseer ik lock-contention, verdeel ik het werk over de kerns en kalibreer ik vervolgens de backlog-groottes <strong>Gericht<\/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>Containers, VM's en orkestratie<\/h2>\n<p>In gevirtualiseerde omgevingen en containers geldt het volgende: de effectieve backlog is afhankelijk van de host-kernel. Als ik somaxconn in de container instel, moet de host dit toestaan en opslaan. In Kubernetes schakel ik de benodigde sysctls expliciet in en zorg ik ervoor dat het beveiligingsbeleid dit toestaat. Daarnaast controleer ik de ulimit-waarden (nofile) en cgroup-limieten, zodat er \u00fcberhaupt veel gelijktijdige sockets kunnen worden geopend. Als er een Ingress-controller of een NodePort voor zit, dimensioner ik de listen-backlog daarvan net als die van de eigenlijke app, zodat de eerste hop geen bottleneck blijft. Hetzelfde geldt voor L3\/4-loadbalancers of proxys: elk niveau heeft zijn eigen wachtrijen, die ik als een geheel beschouw.<\/p>\n\n<h2>Capaciteitsplanning: rekenvoorbeelden voor de omvang van de achterstand<\/h2>\n<p>Ik bepaal de benodigde capaciteit in drie stappen: (1) de maximale aankomstfrequentie (Conn\/s) tijdens pieken vaststellen, (2) de gemiddelde accept-latentie van de applicatie meten, (3) een veiligheidsmarge inbouwen. Voorbeeld: als er een piek van 10.000 verbindingen per seconde binnenkomt en de gemiddelde tijd tussen het binnenkomen en de `accept()`-oproep 3 ms bedraagt, dan moeten er op korte termijn gemiddeld 10.000 \u00d7 0,003 = 30 verbindingen worden gebufferd. Voor pieken en schommelingen in de verdeling kies ik een factor 5\u201310, dus 150\u2013300. Als ik bovendien meerdere listeners via SO_REUSEPORT plan, schaalt de capaciteit mee met het aantal listeners. Voor zeer korte verzoeken (bijv. 5\u201320 ms) hanteer ik een conservatievere berekening, omdat statistische schommelingen de overhand hebben. Bij langdurige sessies geef ik voorrang aan het aantal workers, epoll-schaalbaarheid en IO-paden, voordat ik de backlogs verder vergroot.<\/p>\n<p>Ik bereken bovendien de benodigde opslagruimte: elke vermelding in de Accept-wachtrij houdt kernelstructuren in stand. Zeer hoge waarden zijn daarom alleen zinvol als ook het RAM-budget, de bestandsdescriptoren en de userspace-workers dit aankunnen. Het doel is niet een zo groot mogelijke, maar een voldoende grote buffer die pieken afvlakt zonder andere bronnen te overbelasten.<\/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>Wijzigingsbeheer, persistentie en rollback<\/h2>\n<p>Ik houd tests gescheiden van de productie: eerst afstemmen in een staging-omgeving met representatieve belastingprofielen, daarna stapsgewijs uitrollen naar de productieomgeving. Kernelparameters schrijf ik in speciale sysctl.d-bestanden, documenteer ze met het doel en de datum en controleer na de reboot of ze werken. Dienst-backlogs stel ik in het betreffende configuratiebestand in en verzegel ze met configuratiebeheer, zodat er geen drift ontstaat. Voor kritieke systemen stel ik een rollback-venster in en houd ik na de uitrol nauwlettend lijnoverflows, accept-latenties en foutpercentages in de gaten. Als er bijwerkingen zichtbaar worden (bijv. verhoogde geheugenbelasting of threadverzadiging), ga ik een stap terug en pak ik eerst het nieuwe knelpunt aan.<\/p>\n\n<h2>Gereedschappen en bedrijfsroutines<\/h2>\n<p>In mijn dagelijkse werkprocedures heb ik een kleine set betrouwbare tools bij de hand: ss\/netstat om listening-sockets en actuele backlog-waarden te bekijken, sysctl voor het instellen van parameters, journalctl\/dmesg voor kernelmeldingen, en een belastingstool die kortstondige, herhaalbare en meetbare pieken kan genereren. Daarnaast gebruik ik proces-exporters die de accept-tijd en wachtrijvullingen registreren, evenals systeemprofielen (perf, eBPF) om indien nodig in te zoomen op het accept-pad. De monitoring verzamelt histogrammen voor de latentie bij het tot stand brengen van verbindingen, zodat ik niet alleen gemiddelden zie, maar ook verdelingen en P95\/P99 \u2013 precies daar gaan de symptomen van te kleine wachtrijen schuil.<\/p>\n\n<h2>Checklist voor de uitvoering<\/h2>\n<ul>\n  <li>Belastingsprofiel vaststellen: Conn\/s, burst-amplitude, accept-latentie, keep-alive-percentage.<\/li>\n  <li>Actuele waarden vastleggen: somaxconn, tcp_max_syn_backlog, netdev-backlog, service-backlogs, nofile.<\/li>\n  <li>Kernel-tellers controleren: ListenOverflows\/Drops, Syncookies-tellers, dmesg-meldingen.<\/li>\n  <li>De backlog stapsgewijs vergroten: toepassing en somaxconn synchroon, meetlussen per fase.<\/li>\n  <li>SYN-fase beveiligen: tcp_max_syn_backlog licht verhogen, SYN-cookies inschakelen en de situatie in de gaten houden.<\/li>\n  <li>Parallelisatie: SO_REUSEPORT gebruiken, workers en affiniteiten afstemmen.<\/li>\n  <li>Het pakkettraject in beeld: netdev-backlog, IRQ-balans, ontvangst-\/verzendbuffers afstemmen.<\/li>\n  <li>Persistentie &amp; rollback: sysctl.d, versiebeheer, gefaseerde uitrol, telemetrie in de gaten houden.<\/li>\n<\/ul>\n\n<h2>Samenvatting voor snelle implementatie<\/h2>\n\n<p>Ik bepaal de omvang van de backlog op pragmatische wijze: eerst meten, dan <strong>aanpassen<\/strong>, daarna opnieuw meten. Voor veel web- en API-servers vormen waarden tussen 2048 en 8192 voor `somaxconn`, in combinatie met de juiste app-instellingen, een haalbaar startniveau, dat ik via een belastingstest controleer. Bij handshake-pieken verhoog ik tcp_max_syn_backlog stapsgewijs en activeer ik SYN-cookies, zodat legitieme clients niet worden afgeremd. Tegelijkertijd zorg ik voor de netdev-backlog, de ontvangst- en verzendbuffers, de IRQ-balans en de acceptatiestrategie in de gebruikersruimte. Zo houd ik het tot stand brengen van verbindingen, de responstijd en de foutpercentages onder controle en maak ik gebruik van de <strong>Linux-achterstand<\/strong> als een doeltreffend middel om constante netwerkprestaties te waarborgen.<\/p>","protected":false},"excerpt":{"rendered":"<p>Leer hoe je de Linux-socket-backlog op de juiste manier kunt dimensioneren en hoe je met gerichte TCP-tuning de netwerkprestaties van je servers duurzaam kunt verbeteren.<\/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":"149","_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\/nl\/wp-json\/wp\/v2\/posts\/21143","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=21143"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21143\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21136"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21143"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21143"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21143"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}