{"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":"korrekt-dimensionering-af-linux-socket-backlog-tcp-tuning-netvaerksoptimering","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/linux-socket-backlog-richtig-dimensionieren-tcp-tuning-netzwerkoptimierung\/","title":{"rendered":"Korrekt dimensionering af Linux-socket-backlog for maksimal netv\u00e6rksydeevne"},"content":{"rendered":"<p>Jeg viser dig konkret, hvordan du <strong>Linux-backlog<\/strong> dimensioneres korrekt, s\u00e5 indg\u00e5ende forbindelser bufferes ordentligt og modtages hurtigt. P\u00e5 den m\u00e5de opn\u00e5r du en <strong>konstant<\/strong> Netv\u00e6rksydelse selv ved spidsbelastninger, uden at foresp\u00f8rgsler h\u00e6nger sig fast eller afvises.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<p>Jeg vil sammenfatte f\u00f8lgende punkter som udgangspunkt, inden jeg g\u00e5r mere i dybden.<\/p>\n<ul>\n  <li><strong>Accept-Queue<\/strong> Dimensioner m\u00e5lrettet, og s\u00f8rg for ikke at forveksle SYN-k\u00f8en.<\/li>\n  <li><strong>somaxconn<\/strong> fasts\u00e6tter den strenge \u00f8vre gr\u00e6nse for listen()-backlog.<\/li>\n  <li><strong>tcp_max_syn_backlog<\/strong> beskytter h\u00e5ndtryk i tilf\u00e6lde af stor tilstr\u00f8mning.<\/li>\n  <li><strong>min(backlog, somaxconn)<\/strong> bestemmer den effektive v\u00e6rdi.<\/li>\n  <li><strong>Overv\u00e5gning<\/strong> og belastningstests er afg\u00f8rende for enhver tilpasning.<\/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>S\u00e5dan fungerer Linux-socket-backloggen<\/h2>\n\n<p>En serversocket skifter med <strong>listen()<\/strong> g\u00e5r i lytte-tilstand og modtager i den forbindelse en backlog-v\u00e6rdi, der bufferer allerede oprettede forbindelser, indtil applikationen henter dem via <strong>accept()<\/strong> overtager. Moderne Linux-kerner bruger denne v\u00e6rdi udelukkende til Accept-k\u00f8en, mens halv\u00e5bne forbindelser under h\u00e5ndtrykket havner i SYN-k\u00f8en. Jeg adskiller disse to k\u00f8er strengt, s\u00e5 jeg kan tilordne \u00e5rsag og virkning korrekt og undg\u00e5r at justere de forkerte parametre. Accept-k\u00f8en forhindrer kortvarige overl\u00f8b, n\u00e5r appen ikke accepterer forbindelser med det samme, mens SYN-k\u00f8en h\u00e5ndterer h\u00e5ndtryk i et kort tidsvindue. Den, der ser bort fra denne semantik, optimerer ved <strong>falsk<\/strong> Sted og spilder v\u00e6rdifulde reserver.<\/p>\n\n<h2>Hvorfor den rigtige st\u00f8rrelse giver direkte ydeevne<\/h2>\n\n<p>St\u00f8rrelsen p\u00e5 backloggen bestemmer, hvor mange fuldt etablerede sessioner der m\u00e5 vente p\u00e5 at blive accepteret, hvilket <strong>Svartid<\/strong> p\u00e5virker oprettelsen af forbindelser. Hvis Accept-k\u00f8en er fuld, afviser kernen nye fors\u00f8g eller forsinker dem m\u00e6rkbart, hvilket viser sig som sporadiske fejl og langsomme forbindelsesoprettelser. Som en simpel tiln\u00e6rmelse g\u00e6lder: maksimal acceptfrekvens \u2248 k\u00f8st\u00f8rrelse divideret med den gennemsnitlige opholdstid pr. post. Hvis anmodninger behandles meget hurtigt og i store m\u00e6ngder, bliver det endnu vigtigere at have en Accept-k\u00f8, der er dimensioneret tilstr\u00e6kkeligt. Hvad ang\u00e5r pakkesiden, er det v\u00e6rd at se n\u00e6rmere p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/serverpakkekoer-netvaerksstabilitet-hostingoptimering-latenstid\/\">Serverpakkek\u00f8er<\/a>, fordi det er der, det n\u00e6ste bufferniveau befinder sig, som jeg inddrager i tuningen og afstemmer med backlog-strategien.<\/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>Kernelparametre: somaxconn og tcp_max_syn_backlog<\/h2>\n\n<p>For den effektive ordrebeholdning t\u00e6ller ikke kun v\u00e6rdien i <strong>listen()<\/strong>, da kernen s\u00e6tter en fast \u00f8vre gr\u00e6nse for den via net.core.somaxconn. Derudover styrer net.ipv4.tcp_max_syn_backlog antallet af halv\u00e5bne handshakes, hvilket er afg\u00f8rende is\u00e6r ved belastningsspidser eller DDoS-lignende m\u00f8nstre. I praksis g\u00e6lder den enkle regel: effektiv backlog = min(backlog, somaxconn), hvilket jeg holder i baghovedet ved hver justering. Konservative standardv\u00e6rdier har historisk set v\u00e6ret lave, hvilket hurtigt kan f\u00f8re til flaskehalse i moderne web- og API-tjenester. Jeg v\u00e6lger derfor somaxconn s\u00e5ledes, at accepterede forbindelser har tilstr\u00e6kkelig buffer, og jeg justerer tcp_max_syn_backlog i overensstemmelse hermed, s\u00e5 h\u00e5ndtryk ikke l\u00f8ber over, og legitime klienter kommer hurtigt igennem.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametre<\/th>\n      <th>Form\u00e5l<\/th>\n      <th>Kontrollere<\/th>\n      <th>Standardindstillinger<\/th>\n      <th>Hint<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>net.core.somaxconn<\/strong><\/td>\n      <td>\u00d8vre gr\u00e6nse for Accept-k\u00f8en og dermed for listen()-backlog<\/td>\n      <td>sysctl net.core.somaxconn<\/td>\n      <td>128 til 4096+ afh\u00e6ngigt af kernen<\/td>\n      <td>Effektiv backlog = min(app-backlog, somaxconn)<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.ipv4.tcp_max_syn_backlog<\/strong><\/td>\n      <td>Begr\u00e6nsning for halv\u00e5bne forbindelser (SYN-k\u00f8)<\/td>\n      <td>sysctl net.ipv4.tcp_max_syn_backlog<\/td>\n      <td>256 til 8192+ afh\u00e6ngigt af anvendelsen<\/td>\n      <td>Kombiner med SYN-cookies for at afb\u00f8de trafikspidser<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.core.netdev_max_backlog<\/strong><\/td>\n      <td>Buffer til indg\u00e5ende pakker i SoftIRQ-stien<\/td>\n      <td>sysctl net.core.netdev_max_backlog<\/td>\n      <td>1000 til 5000+ afh\u00e6ngigt af NIC\/IRQ<\/td>\n      <td>Vurderes sammen med modtage-\/sendebuffere<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Vejledende v\u00e6rdier baseret p\u00e5 belastningsprofil og latenstid<\/h2>\n\n<p>Jeg dimensionerer Accept-k\u00f8en ud fra det forventede <strong>lastprofil<\/strong> og applikationens gennemsnitlige behandlingstid. For tjenester med moderat belastning er 256 til 1024 ofte tilstr\u00e6kkeligt, mens API\u2019er eller webshops med h\u00f8j trafik har gavn af 2048 til 8192, forudsat at hardware og webserverarkitekturen kan klare det. Mange korte anmodninger taler for h\u00f8jere v\u00e6rdier, fordi flere forbindelser venter kortvarigt og alligevel hurtigt videresendes. Langvarige sessioner har snarere brug for et optimeret antal arbejdsprocesser og IO-veje i stedet for stadig st\u00f8rre k\u00f8er. Jeg holder \u00f8je med samspillet med CPU-schedulere, IRQ-fordeling og userspace-accept-stien, s\u00e5 k\u00f8en ikke bliver den eneste l\u00f8sning.<\/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>M\u00e5ling af den aktuelle tilstand og identifikation af flaskehalse<\/h2>\n\n<p>Inden jeg \u00e6ndrer v\u00e6rdierne, m\u00e5ler jeg k\u00f8ens udnyttelse med <strong>ss<\/strong> eller netstat og tjekker Recv-\/Send-k\u00f8er for afvigelser. Kernelstatistikker og dmesg-meddelelser giver indsigt i listeoverl\u00f8b, tabte pakker eller backlog-tab, som jeg sammenholder tidsm\u00e6ssigt med belastningstoppe. Jeg analyserer logfiler fra webserveren og upstream-proxyerne for at identificere fejlrater ved oprettelse af forbindelser og gentagne fors\u00f8g. Sidel\u00f8bende overv\u00e5ger jeg CPU-belastning, IRQ-balance og scheduler-adf\u00e6rd, s\u00e5 jeg ikke overser flaskehalse i andre lag. F\u00f8rst n\u00e5r jeg har forst\u00e5et situationen, planl\u00e6gger jeg de n\u00e6ste trin for en m\u00e5lrettet <strong>Indstilling<\/strong>.<\/p>\n\n<h2>Dybdeg\u00e5ende m\u00e5ling: N\u00f8gletal, fejlm\u00f8nstre og diagnoseforl\u00f8b<\/h2>\n<p>For at stille en pr\u00e6cis diagnose tjekker jeg kernelt\u00e6llerne under \/proc\/net\/netstat. I linjen TcpExt er jeg is\u00e6r interesseret i ListenOverflows og ListenDrops (Accept-k\u00f8en) samt SyncookiesSent\/SyncookiesRecv (SYN-fasen). Hvis ListenOverflows stiger, er Accept-k\u00f8en for lille, eller ogs\u00e5 accepterer applikationen for langsomt. Hvis Syncookies-t\u00e6llerne stiger, er SYN-k\u00f8en overbelastet, eller tjenesten uds\u00e6ttes for aggressive m\u00f8nstre. Med kommandoen `ss -ltn` tjekker jeg den aktuelt konfigurerede backlog pr. port og kan se, om applikationen rent faktisk overf\u00f8rer den \u00f8nskede v\u00e6rdi til kernen. Dmesg-meddelelser som \u201eTCP: request_sock_queue is full\u201c tyder p\u00e5 en overfyldt SYN-k\u00f8, mens \u201eTCP: listen overflow\u201c peger p\u00e5 Accept-k\u00f8en. Jeg sammenholder disse indikatorer med m\u00e5linger fra overv\u00e5gningen (latens, fejlrater, gentagelser), s\u00e5 jeg kan s\u00e6tte ind pr\u00e6cist.<\/p>\n<p>Ved kortvarige spidsbelastninger opretter jeg tidsserier med h\u00f8j opl\u00f8sning. Jeg korrelerer den maksimale fyldningsgrad i Accept-k\u00f8en med Accept-latensen i brugerrummet. Eventuelt bruger jeg eBPF-baserede sporinger til at profilere Accept-ventetider og wakeups. Dette er is\u00e6r nyttigt, n\u00e5r der er mange lyttere, procesaffiniteter eller lock-contention, og effekterne ikke alene kan forklares ved hj\u00e6lp af t\u00e6llere.<\/p>\n\n<h2>Trinvis optimering med m\u00e5lesl\u00f8jfer<\/h2>\n\n<p>Jeg begynder med at dokumentere status quo, noterer de eksisterende standardindstillinger og den aktuelle belastningskarakteristik i <strong>myldretid<\/strong>. Derefter \u00f8ger jeg somaxconn og applikations-backloggen moderat, i cirka to til tre trin, og overv\u00e5ger hver gang fejlrater, latenstider og accept-tider. Derefter tjekker jeg tcp_max_syn_backlog og SYN-cookies, hvis h\u00e5ndtryk allerede fejler f\u00f8r Accept-k\u00f8en. For hvert trin udf\u00f8rer jeg reproducerbare belastningstests og stoler p\u00e5 faste m\u00e5linger frem for mavefornemmelse. Den bedste indstilling opn\u00e5s i en m\u00e5lesl\u00f8jfe, hvor jeg konsekvent inddrager feedback fra overv\u00e5gning og app-profilering i den n\u00e6ste <strong>Tilpasning<\/strong> overbeviser.<\/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>Applikationskonfiguration og acceptstrategi<\/h2>\n\n<p>Jeg kontrollerer backlog-indstillingerne for servertjenesterne, s\u00e5som Apache, NGINX eller applikationsservere, for at sikre, at en for lav standardv\u00e6rdi ikke p\u00e5virker hele <strong>k\u00f8<\/strong> begr\u00e6nser. Nogle frameworks indstiller deres egne v\u00e6rdier eller ignorerer h\u00f8je parametre, indtil en indstilling er blevet angivet eksplicit. N\u00e5r der er mange CPU-kerner til r\u00e5dighed, udvider jeg konceptet ved hj\u00e6lp af <a href=\"https:\/\/webhosting.de\/da\/so-reuseport-linux-webserver-ydeevneoptimering-kerne\/\">SO_REUSEPORT<\/a>, s\u00e5 flere lyttere kan udf\u00f8re accept() parallelt p\u00e5 den samme port. Dermed forkorter jeg ventetiden m\u00e6rkbart, hvilket reducerer den gennemsnitlige opholdstid i accept-k\u00f8en. Det er dog vigtigt, at jeg s\u00f8rger for, at eventuelle begr\u00e6nsninger for \u00e5bne filbeskrivere og arbejdsprocesser tilpasses synkront, s\u00e5 der ikke opst\u00e5r en ny flaskehals i brugerrummet.<\/p>\n\n<h2>Anvendelse i g\u00e6ngse servere og rammev\u00e6rker<\/h2>\n<p>I praksis kontrollerer jeg den effektive backlog pr. tjeneste: NGINX tillader en backlog-angivelse i listen-blokken; derudover findes accept_mutex og worker_processes, som bestemmer modtagelseshastigheden. I Apache indstiller jeg `ListenBacklog` (pr. vHost\/bind) og sikrer, at MPM\u2019en (f.eks. `event`) har tilstr\u00e6kkeligt med arbejdsprocesser til r\u00e5dighed. I HAProxy fastl\u00e6gger jeg backloggen via `bind`-indstillinger og justerer samtidig `tune.maxaccept` samt antallet af processer\/tr\u00e5de. I Java-stacks (Netty, Undertow, Tomcat) findes der som regel en soBacklog-egenskab; Node.js\/Libuv accepterer en backlog-parameter i server.listen(), som uden eksplicit angivelse ofte ligger under somaxconn. I Go bruger net.Listen henholdsvis http.Server operativsystemets standardindstillinger; her er jeg ekstra opm\u00e6rksom p\u00e5, at somaxconn er tilstr\u00e6kkelig, da app-laget sj\u00e6ldent angiver sin egen backlog.<\/p>\n<p>Jeg tester hver tjeneste med korte, intensive forbindelsesserier (f.eks. uden Keep-Alive) for at verificere modstandsdygtigheden over for backlog. F\u00f8rst n\u00e5r ydeevnen forbliver konstant selv under burst-forhold, tillader jeg igen l\u00e6ngere Keep-Alive-tider og genbrug af forbindelser i den daglige drift for at spare p\u00e5 ressourcerne.<\/p>\n\n<h2>SO_REUSEPORT: Parallelisering uden konkurrence om ressourcer<\/h2>\n<p>Med SO_REUSEPORT fordeler jeg indg\u00e5ende forbindelser p\u00e5 flere listener-sockets, typisk \u00e9n pr. worker\/CPU-kerne. Hver socket har sin egen accept-k\u00f8 med eget backlog, hvilket effektivt mangedobler den samlede kapacitet. Det er afg\u00f8rende, at alle lyttere er konfigureret ens (samme backlog-v\u00e6rdier, samme prioriteter), s\u00e5 kernen fordeler foresp\u00f8rgslerne retf\u00e6rdigt, og der ikke opst\u00e5r ubalance. Jeg overv\u00e5ger, om enkelte arbejdsprocesser er over- eller underbelastede, og justerer antallet af processer eller CPU-affinitet. I praksis mindsker denne strategi lock-contention i accept-stien markant og reducerer wakeup-storms, hvilket udj\u00e6vner latenstiderne.<\/p>\n\n<h2>TCP_DEFER_ACCEPT, tidlige data og tidspunktet for accept<\/h2>\n<p>Med TCP_DEFER_ACCEPT kan jeg indstille, at kernen f\u00f8rst aktiverer accept(), n\u00e5r der allerede er modtaget brugerdata. Dermed reduceres antallet af un\u00f8dvendige aktiveringer (klienter, der opretter forbindelse, men ikke sender noget), og opholdstiden i accept-k\u00f8en virker kortere. Jeg bruger denne indstilling med forsigtighed, da timeouts p\u00e5 applikationsniveau, middlebox-adf\u00e6rd og klientstakke kan p\u00e5virke hinanden. Passive arbejdsbelastninger (f.eks. protokoller, der indledningsvis sender serverdata) drager mindre fordel heraf; omvendt kan \u00bbchatty\u00ab-protokoller, hvor klienten sender data med det samme, aflastes. Derfor tjekker jeg altid, hvordan DEFER_ACCEPT p\u00e5virker gentagelsesfors\u00f8g, timeouts og den samlede latenstid, f\u00f8r jeg aktiverer den permanent. Derudover planl\u00e6gger jeg kun at bruge TCP_FASTOPEN, hvis h\u00e5ndtryksomkostningerne dominerer, og infrastrukturen kan h\u00e5ndtere det stabilt.<\/p>\n\n<h2>Sikkerhed ved belastningsspidser og SYN-oversv\u00f8mmelser<\/h2>\n\n<p>H\u00f8je v\u00e6rdier i SYN-k\u00f8en opfanger jeg med <strong>SYN-cookies<\/strong> der g\u00f8r h\u00e5ndtrykene mere t\u00e5lelige, n\u00e5r der er mange halvf\u00e6rdige forbindelser, der banker p\u00e5. Hvis der opst\u00e5r uregelm\u00e6ssigheder i indgangstrinnet, \u00f8ger jeg tcp_max_syn_backlog i moderate trin og observerer, om legitime klienter igen kommer hurtigt igennem. Jeg supplerer dette med hastighedsbegr\u00e6nsninger, backoff-strategier og korrekte retransmissionsparametre, s\u00e5 ugunstige m\u00f8nstre ikke skaber dominoeffekter. Detaljerede anvisninger til korrekt afv\u00e6rgelse af tilbagevendende m\u00f8nstre sammenfatter jeg i den relevante sammenh\u00e6ng <a href=\"https:\/\/webhosting.de\/da\/syn-beskyttelse-mod-oversvommelse-socket-handtering-serverforsvar\/\">SYN-Flood-beskyttelse<\/a> sammen. Sikkerhedsfunktioner er mest effektive, n\u00e5r jeg tilpasser dem i forhold til backlog-st\u00f8rrelser, pakkebuffere og app-accept-ydeevne og regelm\u00e6ssigt sammenligner dem med realistiske testprofiler.<\/p>\n\n<h2>Optimering af backlog i den daglige hostingdrift<\/h2>\n\n<p>N\u00e5r det g\u00e6lder professionel hosting, gennemg\u00e5r jeg altid backlog-v\u00e6rdierne sammen med <strong>somaxconn<\/strong>, tcp_max_syn_backlog, netdev-backlog og applikations-workere. P\u00e5 den m\u00e5de sikrer jeg, at de lovede svartider fortsat kan overholdes, selv n\u00e5r trafikken svinger. Jeg dokumenterer alle kerne- og tjenesteparametre, s\u00e5 revisioner, SRE-rutiner og overdragelser hurtigt skaber klarhed. Overv\u00e5gningen alarmerer ved k\u00f8fyldningsniveauer, modtagelsesfejl og gentagne fors\u00f8g, hvilket fremskynder senere finjusteringer. N\u00e5r man sammenligner hostingpakker, b\u00f8r man ud over CPU og RAM ogs\u00e5 vurdere disse netv\u00e6rksdetaljer, da de har en m\u00e6rkbar indvirkning p\u00e5 omkostninger, time-to-first-byte og succesfulde <strong>Sessioner<\/strong> har.<\/p>\n\n<h2>Undg\u00e5 typiske fejl<\/h2>\n\n<p>En almindelig misforst\u00e5else: Jeg \u00f8ger blot anvendelses-backloggen, men lader <strong>somaxconn<\/strong> for lille, hvilket betyder, at den effektive \u00f8vre gr\u00e6nse forbliver u\u00e6ndret. Lige s\u00e5 farligt er det at forveksle Accept- og SYN-k\u00f8en, hvilket f\u00f8rer til forkerte korrektioner. Ekstremt h\u00f8je v\u00e6rdier uden en klar strategi skjuler svagheder i applikationen, bruger hukommelse og g\u00f8r det sv\u00e6rere at analysere \u00e5rsagerne. Hvis accept() ikke overtager forbindelserne hurtigt nok, forbliver k\u00f8en fuld p\u00e5 trods af store tal, og klienterne venter fortsat. Jeg tjekker derfor f\u00f8rst brugerrumsstien, minimerer lock-contention, fordeler arbejdet p\u00e5 kerner og kalibrerer derefter backlog-st\u00f8rrelserne <strong>M\u00e5lrettet<\/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>Containere, virtuelle maskiner og orkestrering<\/h2>\n<p>I virtualiserede milj\u00f8er og containere g\u00e6lder f\u00f8lgende: Den effektive backlog afh\u00e6nger af v\u00e6rtskernel. Hvis jeg indstiller somaxconn i containeren, skal v\u00e6rten tillade dette og sikre, at indstillingen bevares. I Kubernetes aktiverer jeg de n\u00f8dvendige sysctl'er eksplicit og sikrer mig, at sikkerhedspolitikkerne tillader det. Jeg tjekker desuden ulimit-v\u00e6rdier (nofile) og cgroup-gr\u00e6nser, s\u00e5 der overhovedet kan \u00e5bnes mange samtidige sockets. Hvis der er en Ingress-controller eller en NodePort foran, dimensionerer jeg dens listen-backlog p\u00e5 samme m\u00e5de som den egentlige apps, s\u00e5 det f\u00f8rste hop ikke bliver flaskehalsen. Det samme g\u00e6lder for L3\/4-load-balancere eller proxyer: Hvert trin har sine egne k\u00f8er, som jeg betragter samlet.<\/p>\n\n<h2>Kapacitetsplanl\u00e6gning: Beregningseksempler for st\u00f8rrelsen af ordrereserven<\/h2>\n<p>Jeg dimensionerer i tre trin: (1) Bestemme den maksimale ankomsthastighed (Conn\/s) i spidsbelastninger, (2) m\u00e5le applikationens gennemsnitlige accept-latens, (3) indregne en sikkerhedsmargen. Eksempel: Hvis der indtr\u00e6ffer en spidsbelastning p\u00e5 10.000 forbindelser pr. sekund, og den gennemsnitlige tid fra ankomst til accept() er 3 ms, skal der kortvarigt bufferes 10.000 \u00d7 0,003 = 30 forbindelser i gennemsnit. For bursts og udsving i fordelingen v\u00e6lger jeg en faktor p\u00e5 5\u201310, alts\u00e5 150\u2013300. Hvis jeg desuden planl\u00e6gger flere lyttere via SO_REUSEPORT, skaleres kapaciteten i takt med antallet af lyttere. For meget korte anmodninger (f.eks. 5\u201320 ms) regner jeg mere konservativt, fordi statistiske udsving dominerer. Ved langvarige sessioner prioriterer jeg antallet af arbejdere, epoll-skalering og IO-veje, f\u00f8r jeg \u00f8ger backlogs yderligere.<\/p>\n<p>Jeg beregner desuden lagerbehovet: Hver post i Accept-k\u00f8en reserverer plads i kernelstrukturerne. Meget h\u00f8je v\u00e6rdier giver derfor kun mening, hvis RAM-budgettet, filbeskrivelserne og brugerrum-arbejderne ogs\u00e5 kan f\u00f8lge med. M\u00e5let er ikke en s\u00e5 stor buffer som muligt, men en tilstr\u00e6kkelig stor buffer, der udj\u00e6vner spidsbelastninger uden at overbelaste andre ressourcer.<\/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>\u00c6ndringsstyring, persistens og tilbagef\u00f8rsel<\/h2>\n<p>Jeg adskiller test fra drift: F\u00f8rst foretager jeg justeringer i et staging-milj\u00f8 med repr\u00e6sentative belastningsprofiler, derefter ruller jeg det gradvist ud i produktionsmilj\u00f8et. Kernelparametre skriver jeg i dedikerede sysctl.d-filer, dokumenterer dem med form\u00e5l og dato og kontrollerer effektiviteten efter genstart. Tjenestebacklogs angiver jeg i den respektive konfigurationsfil og forsegler dem med konfigurationsstyring, s\u00e5 der ikke opst\u00e5r afvigelser. For kritiske systemer etablerer jeg et rollback-vindue og overv\u00e5ger n\u00f8je listenoverflows, accept-latenser og fejlrater efter udrulningen. Hvis der opst\u00e5r bivirkninger (f.eks. \u00f8get hukommelsesbelastning eller tr\u00e5dm\u00e6tning), tager jeg et skridt tilbage og l\u00f8ser f\u00f8rst det nye flaskehalsproblem.<\/p>\n\n<h2>V\u00e6rkt\u00f8jer og driftsrutiner<\/h2>\n<p>I mine driftsrutiner har jeg et lille s\u00e6t p\u00e5lidelige v\u00e6rkt\u00f8jer klar: ss\/netstat til at f\u00e5 overblik over lyttende sockets og aktuelle backlog-v\u00e6rdier, sysctl til parameterindstilling, journalctl\/dmesg til kernel-meddelelser samt et belastningstestv\u00e6rkt\u00f8j, der hurtigt kan generere gentagelige og m\u00e5lbare spidsbelastninger. Derudover bruger jeg proceseksport\u00f8rer, der registrerer accepttid og k\u00f8fyldningsniveauer, samt systemprofiler (perf, eBPF) for at kunne zoome ind p\u00e5 acceptstien, n\u00e5r det er n\u00f8dvendigt. Overv\u00e5gningen indsamler histogrammer for latenstider ved forbindelsesoprettelse, s\u00e5 jeg ikke kun ser gennemsnitsv\u00e6rdier, men ogs\u00e5 fordelinger og P95\/P99 \u2013 det er netop d\u00e9r, symptomerne p\u00e5 for sm\u00e5 k\u00f8er gemmer sig.<\/p>\n\n<h2>Tjekliste til implementering<\/h2>\n<ul>\n  <li>M\u00e5ling af belastningsprofil: Conn\/s, burst-amplitude, accept-latens, keep-alive-procent.<\/li>\n  <li>Dokumenter aktuelle v\u00e6rdier: somaxconn, tcp_max_syn_backlog, netdev-backlog, tjeneste-backlogs, nofile.<\/li>\n  <li>Kontroller kerne-t\u00e6llere: ListenOverflows\/Drops, Syncookies-t\u00e6llere, dmesg-meddelelser.<\/li>\n  <li>Trinvis for\u00f8gelse af backlog: Synkron anvendelse af Application og somaxconn, m\u00e5lesl\u00f8jfer for hvert trin.<\/li>\n  <li>Beskyttelse mod SYN-angreb: For\u00f8g tcp_max_syn_backlog moderat, aktiver SYN-cookies og hold \u00f8je med situationen.<\/li>\n  <li>Parallelisering: Anvend SO_REUSEPORT, kalibrer arbejdsprocesser og affiniteter.<\/li>\n  <li>Overblik over pakkeruten: Juster netdev-backlog, IRQ-balance og modtage-\/sendebuffere.<\/li>\n  <li>Persistens og rollback: sysctl.d, versionsstyring, gradvis udrulning, med fokus p\u00e5 telemetri.<\/li>\n<\/ul>\n\n<h2>Resum\u00e9 til hurtig implementering<\/h2>\n\n<p>Jeg fastl\u00e6gger omfanget af backloggen p\u00e5 en pragmatisk m\u00e5de: f\u00f8rst m\u00e5le, derefter <strong>Tilpas<\/strong>, og derefter m\u00e5le igen. For mange web- og API-servere udg\u00f8r v\u00e6rdier mellem 2048 og 8192 for \u00bbsomaxconn\u00ab sammen med en passende app-indstilling et holdbart udgangspunkt, som jeg tester ved hj\u00e6lp af en belastningstest. Ved h\u00e5ndtryksangreb \u00f8ger jeg tcp_max_syn_backlog trinvist og aktiverer SYN-cookies, s\u00e5 legitime klienter ikke bliver bremset. Samtidig tager jeg mig af netdev-backlog, modtage-\/sendebuffer, IRQ-balance og acceptstrategien i brugerrummet. P\u00e5 den m\u00e5de holder jeg forbindelsesoprettelse, svartid og fejlrater under kontrol og udnytter <strong>Linux-backlog<\/strong> som et effektivt redskab til at sikre en konstant netv\u00e6rksydeevne.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan du dimensionerer Linux-socket-backloggen korrekt og ved hj\u00e6lp af m\u00e5lrettet TCP-tuning forbedrer dine serveres netv\u00e6rksydelse p\u00e5 lang sigt.<\/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\/da\/wp-json\/wp\/v2\/posts\/21143","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=21143"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21143\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21136"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21143"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21143"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21143"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}