{"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-av-linux-sockets-backlog-tcp-optimering-naetverksoptimering","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/linux-socket-backlog-richtig-dimensionieren-tcp-tuning-netzwerkoptimierung\/","title":{"rendered":"Dimensionera Linux-socklarnas backlog korrekt f\u00f6r maximal n\u00e4tverksprestanda"},"content":{"rendered":"<p>Jag visar konkret hur du kan <strong>Linux-efterfr\u00e5gan<\/strong> dimensioneras korrekt s\u00e5 att inkommande anslutningar buffras smidigt och hanteras snabbt. P\u00e5 s\u00e5 s\u00e4tt uppn\u00e5r du en <strong>konstant<\/strong> N\u00e4tverksprestanda \u00e4ven vid belastningstoppar, utan att f\u00f6rfr\u00e5gningar fastnar eller avvisas.<\/p>\n\n<h2>Centrala punkter<\/h2>\n\n<p>Jag sammanfattar f\u00f6ljande punkter som utg\u00e5ngspunkt innan jag g\u00e5r in p\u00e5 detaljerna.<\/p>\n<ul>\n  <li><strong>Accept-Queue<\/strong> Dimensionera m\u00e5lmedvetet, se till att inte blanda ihop SYN-k\u00f6n.<\/li>\n  <li><strong>somaxconn<\/strong> st\u00e4ller in den strikta \u00f6vre gr\u00e4nsen f\u00f6r backloggen f\u00f6r listen().<\/li>\n  <li><strong>tcp_max_syn_backlog<\/strong> skyddar handskakningar vid stor p\u00e5str\u00f6mning.<\/li>\n  <li><strong>min(backlog, somaxconn)<\/strong> best\u00e4mmer det effektiva v\u00e4rdet.<\/li>\n  <li><strong>\u00d6vervakning<\/strong> och belastningstester styr varje justering.<\/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>Hur Linux-sockelbackloggen fungerar<\/h2>\n\n<p>En serversockel byter med <strong>listen()<\/strong> g\u00e5r in i lyssningsl\u00e4ge och f\u00e5r d\u00e5 ett backlog-v\u00e4rde som buffrar redan uppr\u00e4ttade anslutningar tills applikationen avslutar dem via <strong>accept()<\/strong> tar \u00f6ver. Moderna Linux-k\u00e4rnor anv\u00e4nder detta v\u00e4rde uteslutande f\u00f6r Accept-k\u00f6n, medan halv\u00f6ppna anslutningar hamnar i SYN-k\u00f6n under handskakningen. Jag h\u00e5ller dessa tv\u00e5 k\u00f6er strikt \u00e5tskilda f\u00f6r att kunna koppla orsak och verkan korrekt och inte justera fel parametrar. Accept-k\u00f6n f\u00f6rhindrar kortvariga \u00f6verfl\u00f6d n\u00e4r appen inte accepterar anslutningar omedelbart, medan SYN-k\u00f6n hanterar handskakningar under ett kort tidsf\u00f6nster. Den som bortser fr\u00e5n denna semantik optimerar p\u00e5 <strong>falska<\/strong> Plats och sl\u00f6sar bort v\u00e4rdefulla reserver.<\/p>\n\n<h2>Varf\u00f6r r\u00e4tt storlek ger omedelbar prestanda<\/h2>\n\n<p>Storleken p\u00e5 backloggen avg\u00f6r hur m\u00e5nga fullt etablerade sessioner som f\u00e5r v\u00e4nta p\u00e5 godk\u00e4nnande, vilket <strong>Svarstid<\/strong> p\u00e5verkar uppr\u00e4ttandet av anslutningar. Om Accept-k\u00f6n \u00e4r full avvisar k\u00e4rnan nya f\u00f6rs\u00f6k eller f\u00f6rdr\u00f6jer dem m\u00e4rkbart, vilket visar sig i form av sporadiska fel och tr\u00f6ga anslutningsstartar. En enkel n\u00e4rmning \u00e4r att den maximala mottagningshastigheten \u2248 k\u00f6storleken dividerad med den genomsnittliga uppeh\u00e5llstiden per post. Om f\u00f6rfr\u00e5gningar hanteras mycket snabbt och i stora m\u00e4ngder blir det allt viktigare att ha en tillr\u00e4ckligt stor Accept-k\u00f6. N\u00e4r det g\u00e4ller paketsidan \u00e4r det v\u00e4rt att titta p\u00e5 <a href=\"https:\/\/webhosting.de\/sv\/server-paketkoeer-naetverksstabilitet-hostingoptimering-latens\/\">Serverpaketk\u00f6er<\/a>, eftersom det \u00e4r d\u00e4r n\u00e4sta buffertniv\u00e5 finns, som jag tar med i min optimering och anpassar efter backlog-strategin.<\/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>K\u00e4rnparametrar: somaxconn och tcp_max_syn_backlog<\/h2>\n\n<p>F\u00f6r den effektiva orderstocken \u00e4r det inte enbart v\u00e4rdet i <strong>listen()<\/strong>, eftersom k\u00e4rnan s\u00e4tter en strikt \u00f6vre gr\u00e4ns f\u00f6r den via net.core.somaxconn. Dessutom styr net.ipv4.tcp_max_syn_backlog antalet halv\u00f6ppna handskakningar, vilket \u00e4r avg\u00f6rande s\u00e4rskilt vid belastningstoppar eller DDoS-liknande m\u00f6nster. I praktiken g\u00e4ller den enkla regeln: effektiv backlog = min(backlog, somaxconn), vilket jag har i \u00e5tanke vid varje justering. De konservativa standardv\u00e4rdena har historiskt sett varit l\u00e5ga, vilket g\u00f6r att moderna webb- och API-tj\u00e4nster snabbt hamnar i flaskhalsar. Jag v\u00e4ljer d\u00e4rf\u00f6r somaxconn s\u00e5 att accepterade anslutningar har tillr\u00e4cklig buffert, och jag justerar tcp_max_syn_backlog d\u00e4refter s\u00e5 att handskakningarna inte \u00f6verbelastas och legitima klienter kommer igenom snabbt.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametrar<\/th>\n      <th>Syfte<\/th>\n      <th>Kontrollera<\/th>\n      <th>Vanliga startv\u00e4rden<\/th>\n      <th>Ledtr\u00e5d<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>net.core.somaxconn<\/strong><\/td>\n      <td>\u00d6vre gr\u00e4ns f\u00f6r Accept-k\u00f6 och d\u00e4rmed f\u00f6r backloggen i listen()<\/td>\n      <td>sysctl net.core.somaxconn<\/td>\n      <td>128 till 4096+ beroende p\u00e5 k\u00e4rnan<\/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>Gr\u00e4ns f\u00f6r halv\u00f6ppna anslutningar (SYN-k\u00f6)<\/td>\n      <td>sysctl net.ipv4.tcp_max_syn_backlog<\/td>\n      <td>256 till 8192+ beroende p\u00e5 anv\u00e4ndningsomr\u00e5de<\/td>\n      <td>Kombinera med SYN-cookies f\u00f6r att d\u00e4mpa trafikspikar<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.core.netdev_max_backlog<\/strong><\/td>\n      <td>Buffert f\u00f6r inkommande paket i SoftIRQ-v\u00e4gen<\/td>\n      <td>sysctl net.core.netdev_max_backlog<\/td>\n      <td>1 000 till 5 000+ beroende p\u00e5 NIC\/IRQ<\/td>\n      <td>Utv\u00e4rdera tillsammans med mottagnings- och s\u00e4ndningsbuffertar<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Riktv\u00e4rden baserade p\u00e5 belastningsprofil och latens<\/h2>\n\n<p>Jag dimensionerar Accept-k\u00f6n utifr\u00e5n den f\u00f6rv\u00e4ntade <strong>lastprofil<\/strong> och applikationens genomsnittliga handl\u00e4ggningstid. F\u00f6r tj\u00e4nster med m\u00e5ttlig belastning r\u00e4cker ofta 256 till 1024, medan h\u00f6gtrafikerade API:er eller webbutiker har nytta av 2048 till 8192, f\u00f6rutsatt att h\u00e5rdvaran och webbserverarkitekturen klarar det. M\u00e5nga korta f\u00f6rfr\u00e5gningar talar f\u00f6r h\u00f6gre v\u00e4rden, eftersom fler anslutningar v\u00e4ntar en kort stund och \u00e4nd\u00e5 vidarebefordras snabbt. L\u00e5ngvariga sessioner kr\u00e4ver snarare ett optimerat antal arbetare och IO-v\u00e4gar \u00e4n allt st\u00f6rre k\u00f6er. Jag h\u00e5ller ett \u00f6ga p\u00e5 samspelet med CPU-schemal\u00e4ggare, IRQ-f\u00f6rdelning och accept-v\u00e4gen i anv\u00e4ndarutrymmet, s\u00e5 att k\u00f6n inte blir det enda alternativet.<\/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\u00e4ta nuvarande l\u00e4ge och identifiera flaskhalsar<\/h2>\n\n<p>Innan jag \u00e4ndrar v\u00e4rdena m\u00e4ter jag k\u00f6anv\u00e4ndningen med <strong>ss<\/strong> eller netstat och kontrollerar om det finns avvikelser i Recv- och Send-k\u00f6erna. K\u00e4rnstatistik och dmesg-meddelanden ger information om list\u00f6verfl\u00f6d, bortfall eller f\u00f6rluster i backloggen, vilket jag korrelerar tidsm\u00e4ssigt med belastningstoppar. Jag analyserar loggar fr\u00e5n webbservern och uppstr\u00f6msproxyservrarna f\u00f6r att identifiera felfrekvenser vid anslutningsuppr\u00e4ttande och omf\u00f6rs\u00f6k. Samtidigt \u00f6vervakar jag CPU-belastning, IRQ-balans och schemal\u00e4ggarens beteende f\u00f6r att inte f\u00f6rbise flaskhalsar i andra lager. F\u00f6rst n\u00e4r jag har f\u00f6rst\u00e5tt situationen planerar jag n\u00e4sta steg f\u00f6r en m\u00e5linriktad <strong>Tuning<\/strong>.<\/p>\n\n<h2>F\u00f6rdjupad m\u00e4tning: nyckeltal, felm\u00f6nster och diagnostikfl\u00f6de<\/h2>\n<p>F\u00f6r att st\u00e4lla en exakt diagnos tittar jag p\u00e5 k\u00e4rnr\u00e4knarna under \/proc\/net\/netstat. I raden TcpExt \u00e4r jag s\u00e4rskilt intresserad av ListenOverflows och ListenDrops (Accept-k\u00f6) samt SyncookiesSent\/SyncookiesRecv (SYN-niv\u00e5). Om ListenOverflows \u00f6kar \u00e4r Accept-k\u00f6n f\u00f6r liten eller s\u00e5 tar appen emot f\u00f6r l\u00e5ngsamt. Om Syncookies-r\u00e4knarna \u00f6kar \u00e4r SYN-k\u00f6n full eller s\u00e5 uts\u00e4tts tj\u00e4nsten f\u00f6r aggressiva m\u00f6nster. Med ss -ltn kontrollerar jag den aktuella konfigurerade backloggen per port och ser om applikationen verkligen \u00f6verf\u00f6r det \u00f6nskade v\u00e4rdet till k\u00e4rnan. Dmesg-meddelanden som \u201eTCP: request_sock_queue is full\u201c tyder p\u00e5 en \u00f6verfylld SYN-k\u00f6, medan \u201eTCP: listen overflow\u201c pekar p\u00e5 Accept-k\u00f6n. Jag j\u00e4mf\u00f6r dessa indikatorer med m\u00e4tv\u00e4rden fr\u00e5n \u00f6vervakningen (f\u00f6rdr\u00f6jningar, felfrekvenser, omf\u00f6rs\u00f6k) f\u00f6r att kunna vidta riktade \u00e5tg\u00e4rder.<\/p>\n<p>Vid kortvariga toppar skapar jag tidsserier med h\u00f6g uppl\u00f6sning. Jag korrelerar den maximala fyllnadsniv\u00e5n i Accept-k\u00f6n med Accept-latensen i anv\u00e4ndarutrymmet. I vissa fall anv\u00e4nder jag eBPF-baserade sp\u00e5rningar f\u00f6r att profilera Accept-v\u00e4ntetider och wakeups. Detta \u00e4r s\u00e4rskilt anv\u00e4ndbart n\u00e4r m\u00e5nga lyssnare, processaffiniteter eller l\u00e5skonflikter spelar en roll och effekterna inte kan f\u00f6rklaras enbart med hj\u00e4lp av r\u00e4knare.<\/p>\n\n<h2>Stegvis optimering med m\u00e4tslingor<\/h2>\n\n<p>Jag b\u00f6rjar med att dokumentera nul\u00e4get, noterar de befintliga standardinst\u00e4llningarna och den aktuella belastningskarakteristiken i <strong>rusningstider<\/strong>. D\u00e4refter \u00f6kar jag somaxconn och applikationsbackloggen n\u00e5got, i ungef\u00e4r tv\u00e5 till tre steg, och \u00f6vervakar varje g\u00e5ng felfrekvenser, latenser och accept-tider. D\u00e4refter kontrollerar jag tcp_max_syn_backlog och SYN-cookies, om handskakningarna misslyckas redan f\u00f6re acceptk\u00f6n. F\u00f6r varje steg k\u00f6r jag reproducerbara belastningstester och f\u00f6rlitar mig p\u00e5 fasta m\u00e4tv\u00e4rden ist\u00e4llet f\u00f6r magk\u00e4nsla. Den b\u00e4sta inst\u00e4llningen uppn\u00e5s i en m\u00e4tslinga d\u00e4r jag konsekvent anv\u00e4nder feedback fr\u00e5n \u00f6vervakning och appprofilering i n\u00e4sta <strong>Anpassning<\/strong> \u00f6verf\u00f6r.<\/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 och acceptansstrategi<\/h2>\n\n<p>Jag kontrollerar backlog-inst\u00e4llningarna f\u00f6r servertj\u00e4nsterna, till exempel Apache, NGINX eller applikationsservrar, s\u00e5 att ett f\u00f6r l\u00e5gt standardv\u00e4rde inte p\u00e5verkar hela <strong>k\u00f6<\/strong> begr\u00e4nsar. Vissa ramverk anv\u00e4nder egna v\u00e4rden eller ignorerar h\u00f6ga parametrar tills en alternativinst\u00e4llning har angetts uttryckligen. N\u00e4r det finns m\u00e5nga CPU-k\u00e4rnor kompletterar jag konceptet genom att <a href=\"https:\/\/webhosting.de\/sv\/sa-reuseport-linux-webbserver-prestandaoptimering-kaerna\/\">SO_REUSEPORT<\/a>, s\u00e5 att flera lyssnare parallellt kan utf\u00f6ra accept() p\u00e5 samma port. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rkortar jag mottagningstiden m\u00e4rkbart, vilket minskar den genomsnittliga v\u00e4ntetiden i accept-k\u00f6n. Det \u00e4r viktigt att jag samtidigt justerar eventuella gr\u00e4nser f\u00f6r \u00f6ppna filbeskrivare och arbetsprocesser, s\u00e5 att det inte uppst\u00e5r n\u00e5gon ny flaskhals i anv\u00e4ndarutrymmet.<\/p>\n\n<h2>Till\u00e4mpning i vanliga servrar och ramverk<\/h2>\n<p>I praktiken kontrollerar jag den faktiska backloggen per tj\u00e4nst: NGINX till\u00e5ter en backlog-angivelse i listen-blocket; dessutom finns accept_mutex och worker_processes, som p\u00e5verkar antagningshastigheten. I Apache st\u00e4ller jag in ListenBacklog (per vHost\/bind) och ser till att MPM (t.ex. event) har tillr\u00e4ckligt m\u00e5nga arbetare tillg\u00e4ngliga. I HAProxy best\u00e4mmer jag backloggen via bind-alternativ och justerar samtidigt tune.maxaccept och antalet processer\/tr\u00e5dar. I Java-stackar (Netty, Undertow, Tomcat) finns oftast en soBacklog-egenskap; Node.js\/Libuv accepterar en backlog-parameter i server.listen(), som utan explicit angivelse ofta ligger under somaxconn. I Go anv\u00e4nder net.Listen respektive http.Server operativsystemets standardv\u00e4rden; h\u00e4r l\u00e4gger jag extra stor vikt vid att somaxconn \u00e4r tillr\u00e4ckligt stort, eftersom applikationslagret s\u00e4llan anger en egen backlog.<\/p>\n<p>Jag testar varje tj\u00e4nst med korta, intensiva anslutningsserier (t.ex. utan Keep-Alive) f\u00f6r att verifiera motst\u00e5ndskraften mot backlog. F\u00f6rst n\u00e4r mottagningen f\u00f6rblir stabil \u00e4ven under burst-f\u00f6rh\u00e5llanden till\u00e5ter jag \u00e5terigen l\u00e4ngre Keep-Alive-tider och \u00e5teranv\u00e4ndning av anslutningar i den dagliga driften f\u00f6r att spara p\u00e5 resurserna.<\/p>\n\n<h2>SO_REUSEPORT: Parallellisering utan konkurrens om resurser<\/h2>\n<p>Med SO_REUSEPORT f\u00f6rdelar jag inkommande anslutningar p\u00e5 flera lyssnar-socklar, vanligtvis en per arbetsprocess\/CPU-k\u00e4rna. Varje socket har sin egen accept-k\u00f6 med eget backlog, vilket effektivt m\u00e5ngdubblar den totala kapaciteten. Det \u00e4r avg\u00f6rande att alla lyssnare \u00e4r identiskt konfigurerade (samma backlog-v\u00e4rden, samma prioriteringar) s\u00e5 att k\u00e4rnan f\u00f6rdelar belastningen r\u00e4ttvist och ingen obalans uppst\u00e5r. Jag \u00f6vervakar om enskilda arbetare \u00e4r \u00f6ver- eller underbelastade och justerar antalet processer eller CPU-affinitet. I praktiken minskar denna strategi l\u00e5skonflikter i Accept-v\u00e4gen avsev\u00e4rt och reducerar v\u00e4ckningsstormar, vilket j\u00e4mnar ut latenserna.<\/p>\n\n<h2>TCP_DEFER_ACCEPT, tidiga data och tidpunkt f\u00f6r accept<\/h2>\n<p>Med hj\u00e4lp av TCP_DEFER_ACCEPT kan jag st\u00e4lla in s\u00e5 att k\u00e4rnan f\u00f6rst v\u00e4cker accept() n\u00e4r anv\u00e4ndardata redan har anl\u00e4nt. Detta minskar antalet on\u00f6diga v\u00e4ckningar (klienter som ansluter men inte skickar n\u00e5got), och v\u00e4ntetiden i accept-k\u00f6n upplevs som kortare. Jag anv\u00e4nder denna inst\u00e4llning med f\u00f6rsiktighet, eftersom timeouts p\u00e5 applikationsniv\u00e5, middlebox-beteende och klientstackar kan p\u00e5verka varandra. Passiva arbetsbelastningar (t.ex. protokoll som inledningsvis skickar serverdata) drar mindre nytta av detta; omv\u00e4nt kan \u201dchatty\u201d-protokoll avlastas genom att klienterna skickar data omedelbart. D\u00e4rf\u00f6r kontrollerar jag alltid hur DEFER_ACCEPT p\u00e5verkar omf\u00f6rs\u00f6k, tidsgr\u00e4nser och total latens innan jag aktiverar det permanent. Dessutom planerar jag endast att anv\u00e4nda TCP_FASTOPEN om handskakningskostnaderna dominerar och infrastrukturen hanterar det p\u00e5 ett stabilt s\u00e4tt.<\/p>\n\n<h2>S\u00e4kerhet vid belastningstoppar och SYN-\u00f6versv\u00e4mningar<\/h2>\n\n<p>H\u00f6ga v\u00e4rden i SYN-k\u00f6n hanterar jag med <strong>SYN-cookies<\/strong> som g\u00f6r handskakningarna mer hanterbara n\u00e4r m\u00e5nga halvf\u00e4rdiga anslutningar knackar p\u00e5. Om jag uppt\u00e4cker avvikelser i ing\u00e5ngssteget h\u00f6jer jag tcp_max_syn_backlog i m\u00e5ttliga steg och observerar om legitima klienter \u00e5terigen ansluter snabbt. Jag kompletterar detta med hastighetsbegr\u00e4nsningar, backoff-strategier och korrekta parametrar f\u00f6r \u00e5teruts\u00e4ndning, s\u00e5 att ogynnsamma m\u00f6nster inte skapar dominoeffekter. Detaljerade anvisningar f\u00f6r att p\u00e5 ett korrekt s\u00e4tt avv\u00e4rja \u00e5terkommande m\u00f6nster sammanfattar jag i sammanhanget <a href=\"https:\/\/webhosting.de\/sv\/syn-oeversvaemningsskydd-uttagshantering-serverfoersvar\/\">SYN-Flood-skydd<\/a> tillsammans. S\u00e4kerhetsfunktionerna ger st\u00f6rst nytta n\u00e4r jag anpassar dem efter backlogstorlekar, paketbuffertar och app-acceptansprestanda och regelbundet j\u00e4mf\u00f6r dem med realistiska testprofiler.<\/p>\n\n<h2>Optimering av orderstocken i den dagliga driften av webbhotell<\/h2>\n\n<p>N\u00e4r det g\u00e4ller professionell hosting granskar jag alltid backlog-v\u00e4rdena tillsammans med <strong>somaxconn<\/strong>, tcp_max_syn_backlog, netdev-backlog och applikationsarbetare. P\u00e5 s\u00e5 s\u00e4tt s\u00e4kerst\u00e4ller jag att utlovade svarstider kan uppr\u00e4tth\u00e5llas \u00e4ven vid trafikfluktuationer. Jag dokumenterar alla k\u00e4rn- och tj\u00e4nsteparametrar s\u00e5 att revisioner, SRE-rutiner och \u00f6verl\u00e4mningar snabbt skapar klarhet. \u00d6vervakningen varnar vid k\u00f6fyllnadsniv\u00e5er, mottagningsfel och omf\u00f6rs\u00f6k, vilket p\u00e5skyndar senare finjusteringar. Den som j\u00e4mf\u00f6r webbhotellspaket b\u00f6r, f\u00f6rutom CPU och RAM, \u00e4ven utv\u00e4rdera dessa n\u00e4tverksdetaljer, eftersom de har m\u00e4rkbar inverkan p\u00e5 kostnader, Time-to-First-Byte och framg\u00e5ngsrika <strong>Sessioner<\/strong> har.<\/p>\n\n<h2>Undvik typiska misstag<\/h2>\n\n<p>En vanlig missuppfattning: Jag \u00f6kar bara backloggen f\u00f6r anv\u00e4ndningen, men l\u00e5ter <strong>somaxconn<\/strong> f\u00f6r liten, vilket inneb\u00e4r att den effektiva \u00f6vre gr\u00e4nsen f\u00f6rblir of\u00f6r\u00e4ndrad. Lika f\u00f6rr\u00e4diskt \u00e4r det att blanda ihop Accept- och SYN-k\u00f6erna, vilket leder till felaktiga korrigeringar. Extremt h\u00f6ga v\u00e4rden utan n\u00e5gon strategi d\u00f6ljer svagheter i applikationen, f\u00f6rbrukar minne och f\u00f6rsv\u00e5rar orsaksanalysen. Om accept() inte tar emot anslutningarna tillr\u00e4ckligt snabbt f\u00f6rblir k\u00f6n full trots stora siffror och klienterna forts\u00e4tter att v\u00e4nta. Jag kontrollerar d\u00e4rf\u00f6r f\u00f6rst anv\u00e4ndarutrymmesv\u00e4gen, minimerar l\u00e5skonflikter, f\u00f6rdelar arbetet p\u00e5 k\u00e4rnorna och kalibrerar d\u00e4refter backlog-storlekarna <strong>Riktad<\/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>Containrar, virtuella maskiner och orkestrering<\/h2>\n<p>I virtualiserade milj\u00f6er och containrar g\u00e4ller f\u00f6ljande: Den faktiska backloggen beror p\u00e5 v\u00e4rdkerneln. Om jag st\u00e4ller in somaxconn i containern m\u00e5ste v\u00e4rden till\u00e5ta detta och se till att inst\u00e4llningen bevaras. I Kubernetes aktiverar jag n\u00f6dv\u00e4ndiga sysctl-inst\u00e4llningar explicit och ser till att s\u00e4kerhetsriktlinjerna till\u00e5ter detta. Jag kontrollerar dessutom ulimit-v\u00e4rden (nofile) och cgroup-gr\u00e4nser s\u00e5 att m\u00e5nga samtidiga socklar \u00f6verhuvudtaget kan \u00f6ppnas. Om en Ingress-kontroller eller en NodePort ligger f\u00f6re dimensionerar jag dess listen-backlog p\u00e5 samma s\u00e4tt som den f\u00f6r sj\u00e4lva appen, s\u00e5 att inte det f\u00f6rsta hoppet f\u00f6rblir flaskhalsen. Detsamma g\u00e4ller f\u00f6r L3\/4-lastbalanserare eller proxyservrar: Varje niv\u00e5 har sina egna k\u00f6er, som jag betraktar som en helhet.<\/p>\n\n<h2>Kapacitetsplanering: Ber\u00e4knings exempel f\u00f6r orderstocken<\/h2>\n<p>Jag dimensionerar i tre steg: (1) Best\u00e4mma maximal ankomstfrekvens (Conn\/s) vid toppar, (2) m\u00e4ta applikationens genomsnittliga accept-latens, (3) planera in en s\u00e4kerhetsmarginal. Exempel: Om en topp p\u00e5 10 000 anslutningar per sekund intr\u00e4ffar och den genomsnittliga tiden fr\u00e5n ankomst till accept() \u00e4r 3 ms, m\u00e5ste i genomsnitt 10 000 \u00d7 0,003 = 30 anslutningar buffras under en kort tid. F\u00f6r burstar och fluktuationer i f\u00f6rdelningen v\u00e4ljer jag en faktor p\u00e5 5\u201310, allts\u00e5 150\u2013300. Om jag dessutom planerar flera lyssnare via SO_REUSEPORT skalar kapaciteten i takt med antalet lyssnare. F\u00f6r mycket korta f\u00f6rfr\u00e5gningar (t.ex. 5\u201320 ms) g\u00f6r jag en mer konservativ ber\u00e4kning, eftersom statistiska fluktuationer dominerar. Vid l\u00e5ngvariga sessioner prioriterar jag antalet arbetare, epoll-skalning och IO-v\u00e4gar innan jag \u00f6kar backloggarna ytterligare.<\/p>\n<p>Jag ber\u00e4knar dessutom minnesbehovet: Varje post i Accept-k\u00f6n reserverar utrymme i k\u00e4rnstrukturerna. Mycket h\u00f6ga v\u00e4rden \u00e4r d\u00e4rf\u00f6r endast meningsfulla om RAM-budgeten, filbeskrivarna och anv\u00e4ndarutrymmets arbetsprocesser klarar av belastningen. M\u00e5let \u00e4r inte en s\u00e5 stor buffert som m\u00f6jligt, utan en tillr\u00e4ckligt stor buffert som j\u00e4mnar ut toppar utan att \u00f6verbelasta andra resurser.<\/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>\u00c4ndringshantering, persistens och \u00e5terst\u00e4llning<\/h2>\n<p>Jag h\u00e5ller is\u00e4r tester och drift: F\u00f6rst finjusterar jag i en staging-milj\u00f6 med representativa belastningsprofiler, sedan rullar jag ut det stegvis i produktionsmilj\u00f6n. K\u00e4rnparametrar skriver jag in i s\u00e4rskilda sysctl.d-filer, dokumenterar dem med syfte och datum och kontrollerar effekten efter omstarten. Tj\u00e4nstebackloggar st\u00e4ller jag in i respektive konfigurationsfil och l\u00e5ser dem med konfigurationshantering s\u00e5 att inga avvikelser uppst\u00e5r. F\u00f6r kritiska system etablerar jag ett \u00e5terst\u00e4llningsf\u00f6nster och \u00f6vervakar noggrant list\u00f6verfl\u00f6d, acceptansf\u00f6rdr\u00f6jningar och felfrekvenser efter lanseringen. Om biverkningar uppst\u00e5r (t.ex. \u00f6kad minnesbelastning eller tr\u00e5dm\u00e4ttnad) g\u00e5r jag ett steg tillbaka och \u00e5tg\u00e4rdar f\u00f6rst den nya flaskhalsen.<\/p>\n\n<h2>Verktyg och arbetsrutiner<\/h2>\n<p>I mina driftsrutiner har jag en liten upps\u00e4ttning p\u00e5litliga verktyg till hands: ss\/netstat f\u00f6r att \u00f6vervaka lyssnande socklar och aktuella backlog-v\u00e4rden, sysctl f\u00f6r parameterinst\u00e4llningar, journalctl\/dmesg f\u00f6r kernelmeddelanden samt ett belastningstestverktyg som kan generera korta, repeterbara och m\u00e4tbara toppar. Dessutom anv\u00e4nder jag processexport\u00f6rer som registrerar accept-tid och k\u00f6fyllnadsniv\u00e5er, samt systemprofiler (perf, eBPF) f\u00f6r att vid behov kunna zooma in p\u00e5 accept-v\u00e4gen. \u00d6vervakningen samlar in histogram \u00f6ver f\u00f6rdr\u00f6jningar vid anslutningsuppbyggnad, s\u00e5 att jag inte bara ser medelv\u00e4rden utan \u00e4ven f\u00f6rdelningar och P95\/P99 \u2013 det \u00e4r just d\u00e4r symptomen p\u00e5 f\u00f6r sm\u00e5 k\u00f6er g\u00f6mmer sig.<\/p>\n\n<h2>Checklista f\u00f6r genomf\u00f6randet<\/h2>\n<ul>\n  <li>M\u00e4ta belastningsprofil: Conn\/s, burst-amplitud, accept-latens, keep-alive-kvot.<\/li>\n  <li>Dokumentera aktuella v\u00e4rden: somaxconn, tcp_max_syn_backlog, netdev-backlog, tj\u00e4nstebackloggar, nofile.<\/li>\n  <li>Kontrollera k\u00e4rnr\u00e4knare: ListenOverflows\/Drops, Syncookies-r\u00e4knare, dmesg-meddelanden.<\/li>\n  <li>\u00d6ka orderstocken stegvis: Anv\u00e4ndning och somaxconn synkroniserade, m\u00e4tslingor f\u00f6r varje steg.<\/li>\n  <li>S\u00e4kra SYN-fasen: h\u00f6j tcp_max_syn_backlog n\u00e5got, aktivera SYN-cookies och h\u00e5ll ett \u00f6ga p\u00e5 situationen.<\/li>\n  <li>Parallellisering: Anv\u00e4nd SO_REUSEPORT, kalibrera arbetare och affiniteter.<\/li>\n  <li>\u00d6versikt \u00f6ver paketv\u00e4gen: Justera netdev-backlog, IRQ-balans och mottagnings-\/s\u00e4ndningsbuffertar.<\/li>\n  <li>Persistens och \u00e5terst\u00e4llning: sysctl.d, versionshantering, stegvis inf\u00f6rande, telemetri i fokus.<\/li>\n<\/ul>\n\n<h2>Sammanfattning f\u00f6r snabb implementering<\/h2>\n\n<p>Jag dimensionerar backloggen p\u00e5 ett pragmatiskt s\u00e4tt: f\u00f6rst m\u00e4ta, sedan <strong>anpassa<\/strong>, och m\u00e4ta sedan igen. F\u00f6r m\u00e5nga webb- och API-servrar utg\u00f6r v\u00e4rdena 2048 till 8192 f\u00f6r somaxconn, i kombination med l\u00e4mpliga appinst\u00e4llningar, en h\u00e5llbar startniv\u00e5 som jag testar genom belastningstester. Vid handskakningsrusningar h\u00f6jer jag tcp_max_syn_backlog stegvis och aktiverar SYN-cookies s\u00e5 att legitima klienter inte bromsas upp. Parallellt med detta justerar jag netdev-backlog, mottagnings- och s\u00e4ndningsbuffertar, IRQ-balans och accept-strategin i anv\u00e4ndarutrymmet. P\u00e5 s\u00e5 s\u00e4tt h\u00e5ller jag uppkoppling, svarstid och felfrekvens under kontroll och utnyttjar <strong>Linux-efterfr\u00e5gan<\/strong> som ett effektivt verktyg f\u00f6r att s\u00e4kerst\u00e4lla en j\u00e4mn n\u00e4tverksprestanda.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e4r dig hur du dimensionerar Linux-sockets backlog p\u00e5 r\u00e4tt s\u00e4tt och hur du genom m\u00e5linriktad TCP-optimering kan f\u00f6rb\u00e4ttra n\u00e4tverksprestandan hos dina servrar p\u00e5 l\u00e5ng sikt.<\/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":"153","_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\/sv\/wp-json\/wp\/v2\/posts\/21143","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=21143"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21143\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/21136"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=21143"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=21143"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=21143"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}