{"id":19569,"date":"2026-06-01T08:35:01","date_gmt":"2026-06-01T06:35:01","guid":{"rendered":"https:\/\/webhosting.de\/softirq-cpu-hosting-netzwerkdurchsatz-optimierung-datacenter\/"},"modified":"2026-06-01T08:35:01","modified_gmt":"2026-06-01T06:35:01","slug":"softirq-cpu-hosting-netwerk-doorvoer-optimalisatie-datacenter","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/softirq-cpu-hosting-netzwerkdurchsatz-optimierung-datacenter\/","title":{"rendered":"softirq cpu hosting: serverprestaties en netwerkdoorvoer optimaliseren"},"content":{"rendered":"<p>Ik laat zien hoe <strong>softirq cpu<\/strong> Samen met NAPI, IRQ-distributie en wachtrijontwerp beperkt of ontketent het de netwerkdoorvoer bij hosting. Met duidelijke meetpunten, gerichte afstemming en schone affiniteiten verminder ik <strong>Latencies<\/strong> en consistent de pps-doorvoer op productieve servers verhogen.<\/p>\n\n<h2>Centrale punten<\/h2>\n<p>Deze kernidee\u00ebn transporteren netwerkpakketten effici\u00ebnt via CPU, kernel en NIC - en beperken reactietijden tot een minimum. <strong>constant<\/strong> laag.<\/p>\n<ul>\n  <li><strong>NAPI-begroting<\/strong> fijnafstemming: Meer pakketten per poll verlagen de overheadkosten en vlakken de <strong>CPU-belasting<\/strong>.<\/li>\n  <li><strong>IRQ-balancering<\/strong> en affiniteit: hotspots vermijden, cache-hits verhogen, <strong>Pieken in latentie<\/strong> drukken.<\/li>\n  <li><strong>Multi-queue<\/strong>, RSS\/RPS\/XPS: stromen parallelliseren, NUMA-uitlijning behouden, <strong>pps<\/strong> verhogen.<\/li>\n  <li><strong>Ontlaadt<\/strong> bewust gebruiken: GRO\/LRO, TSO, coalescing evalueren, <strong>Jitter<\/strong> in beeld.<\/li>\n  <li><strong>Isolatie<\/strong> en Busy Polling: voorspelbare responstijden op toegewijde <strong>Kernen<\/strong>.<\/li>\n<\/ul>\n\n<h2>Basis: Wat gebeurt er in de kernel tijdens netwerkverkeer?<\/h2>\n<p>Een pakket landt eerst in een hardware interrupt, waarna de kernel het werk overneemt in <strong>SoftIRQ's<\/strong> en NAPI poll loops. Ik zorg ervoor dat de snelle HardIRQ fase heel kort blijft en dat de eigenlijke logica naar de juiste context gaat, zodat de <strong>CPU-tijd<\/strong> niet uit. De ksoftirqd threads stappen alleen in als directe verwerking niet mogelijk is, wat snel leidt tot wachtrijen onder continue belasting. Dit is precies waar wachttijd optreedt, wat zich uit in verhoogde TTFB en fluctuerende doorvoer. Als je dieper wilt gaan, kun je praktische kennis over IRQ-verwerking vinden in dit artikel over <a href=\"https:\/\/webhosting.de\/nl\/server-interruptverwerking-cpu-prestatieoptimalisatie-7342\/\">Interruptverwerking en CPU-prestaties<\/a>, die ik gebruik voor de categorisatie.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/serverperformance-netzwerk-4861.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NAPI, SoftIRQ's en ksoftirqd: latentie regelen in plaats van beheren<\/h2>\n<p>NAPI vermindert interrupt storms door meerdere pakketten per run op te pikken binnen een gedefinieerd budget en zo de interrupttijd te minimaliseren. <strong>Overhead<\/strong> verlaagt. Als het budget ontoereikend is, stapelen de pakketten zich op, loopt de ksoftirqd warm en wordt de <strong>Latency<\/strong> meetbaar toeneemt. In zulke situaties controleer ik systematisch \/proc\/softirqs en \/proc\/net\/softnet_stat om drops, time_squeeze of overlopende wachtrijen te visualiseren. Vervolgens verhoog ik geleidelijk het net.core.netdev_budget of net.core.netdev_budget_usecs en monitor tegelijkertijd de CPU-belasting, p95\/p99-verdeling en pakketverliezen. De truc is om genoeg werk gedaan te krijgen per poll zonder de interactieve uitvoering van userland threads te verdringen.<\/p>\n\n<h2>IRQ-balancering en -affiniteit: hotspots vermijden, cache-hits verhogen<\/h2>\n<p>Een enkele core met alle IRQ's van de NIC wordt een bottleneck omdat deze interrupts, zachte IRQ's en app-threads moet bedienen. <strong>IRQ's<\/strong> gericht. De dienst irqbalance helpt, maar voor hoge pps-snelheden breng ik RX\/TX-wachtrijen expliciet in kaart via affiniteit naar geschikte <strong>kernen<\/strong>. Op NUMA-systemen bind ik wachtrijen aan kernen van hetzelfde knooppunt om geheugentoegang op afstand te vermijden. Toepassingshreads draaien op naburige maar afzonderlijke kernen, wat de cache-lokalisatie en planbaarheid verbetert. Deze gids voor strategische distributie geeft een goed overzicht van de <a href=\"https:\/\/webhosting.de\/nl\/server-irq-balancing-netwerkprestatieoptimalisatie-datacenter\/\">IRQ-balancering in het datacenter<\/a>, die ik gebruik als referentie voor fijnafstelling.<\/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\/06\/serverperformance3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Multi-queue, RSS\/RPS\/XPS: parallellisatie correct gebruiken<\/h2>\n<p>Moderne NIC's worden geleverd met verschillende RX\/TX-wachtrijen, die ik kan beheren via <strong>RSS<\/strong> naar flows en zo echt parallellisme bereiken. Als de kaart te weinig wachtrijen biedt, gebruik ik RPS\/XPS om aanpassingen te maken aan de softwarekant om pakketten op een verstandige manier over flows te verdelen. <strong>kernen<\/strong> te pushen. Schone hash distributie is belangrijk zodat een stroom altijd op dezelfde CPU blijft en er geen dure cache verstoringen optreden. Tegelijkertijd houd ik TX en RX paden dicht bij elkaar om lock contention en onnodige cross-node toegang te voorkomen. Dit verhoogt de pps-doorvoer zonder dat een enkele core aan de rem trekt.<\/p>\n\n<h2>CPU-affiniteit tot in de gebruikersruimte: end-to-end denken<\/h2>\n<p>Ik plan het gegevenspad van de NIC-IRQ via NAPI-wachtrijen naar de worker-threads van de app zodat pakketten hun bestemming bereiken zonder onnodige haken en de <strong>Reactietijd<\/strong> constant blijft. Om dit te bereiken, scheid ik kernen voor interrupts\/softIRQ's consequent van app-kernen en maak ik duidelijke <strong>Affiniteit<\/strong>-regels. Webservers, reverse proxies en databases krijgen vaste CPU sets die dicht bij de IRQ cores liggen om de paden kort te houden. Daarnaast stel ik de CPU gouverneur in op prestatie zodat klokveranderingen geen jitter in p99 brengen. Deze consistente toewijzing maakt gedrag voorspelbaar en helpt om knelpunten netjes te diagnosticeren.<\/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\/06\/server-performance-optimization-8321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Offloads, GRO\/LRO, firewall en eBPF: Belasting besparen zonder blind te vliegen<\/h2>\n<p>checksum offload, TSO en coalescing opslaan <strong>CPU-tijd<\/strong>, Ze kunnen echter pakketgroottes, burstgedrag en jitter veranderen, daarom meet ik specifiek de effecten. GRO\/LRO bundelen frames en verminderen de belasting op de stack, maar voor realtime vereisten beslis ik situationeel over <strong>Deactivering<\/strong> of beperkt gebruik. Conntrack tabellen en diepe nftables\/iptables ketens kosten klokken, dus ik ruim overbodige regels op en vereenvoudig paden. Indien nodig neem ik mijn toevlucht tot eBPF (XDP, tc-BPF) om vroege beslissingen te nemen op de NIC en dure paden te vermijden. Een goed startpunt voor fine-tuning is dit overzicht van <a href=\"https:\/\/webhosting.de\/nl\/interrupt-coalescing-netwerk-optimalisatie-serverflux\/\">Interrupt samenvoegen<\/a>, waar ik rekening mee houd voor gevoelige latency budgetten.<\/p>\n\n<h2>Bezette polling en CPU-isolatie: reactietijden vergrendelen<\/h2>\n<p>Voor doelen met een harde latency gebruik ik busy polling zodat sockets in de gebruikersruimte nog eerder pakketten oppikken en <strong>Wachttijden<\/strong> inkorten. Dit verhoogt de belasting, maar geeft me zeer smalle p99-distributies voor API- of handelsbelastingen op dedicated <strong>Kernen<\/strong>. Daarnaast isoleer ik cores met isolcpus=, nohz_full= en rcu_nocbs= zodat timers, RCU en systeemservices alleen draaien op CPU's die het huishouden doen. Deze scheiding voorkomt interferentie op de latency cores en maakt gedrag reproduceerbaar. Het resultaat is een duidelijk stappenplan: speciale cores, vroege pakketverzameling, gedefinieerde budgetten.<\/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\/06\/softirq_cpu_hosting_4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bewaking en probleemoplossing: van symptoom naar oorzaak<\/h2>\n<p>Ik begin met pps, doorvoer en kernbelasting, controleer dan druppels en de activiteit van de <strong>ksoftirqd<\/strong>-draden in de loop van de tijd om op betrouwbare wijze patronen te herkennen. Gereedschappen als sar, htop, ss, nload en ethtool laten me zien wanneer en waar congestie optreedt en of de <strong>Cues<\/strong> hun limieten bereiken. Verdelingen zijn belangrijk in plaats van gemiddelde waarden zodat avondpieken, cronvensters of campagnes niet verloren gaan. Ik correleer TTFB-pieken met IRQ-verdeling, NAPI-budget en offload-instellingen om gerichte aanpassingen te kunnen doen. Een aangepaste IRQ affiniteit of een nieuw aangepast NAPI budget is vaak genoeg om timeouts merkbaar te verminderen.<\/p>\n\n<h2>Afstemparameters in een oogopslag<\/h2>\n<p>Het volgende overzicht helpt me om wijzigingen verstandig te gebruiken en effecten duidelijk toe te wijzen voordat ik permanente wijzigingen aanbreng. <strong>Roll-outs<\/strong> plan. Ik test elke aanpassing iteratief, meet latentieverdelingen en observeer neveneffecten op <strong>CPU<\/strong> en geheugen. Ik verander altijd maar \u00e9\u00e9n punt per testvenster, zodat oorzaak en gevolg duidelijk blijven. Vervolgens documenteer ik de resultaten en stel ik drempelwaarden in voor waarschuwingen. Op deze manier bereik ik reproduceerbare verbeteringen zonder het risico te lopen op verrassingen in productief verkeer.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Parameter\/Functie<\/th>\n      <th>Effect in het gegevenspad<\/th>\n      <th>Wanneer verhogen\/activeren<\/th>\n      <th>Risico's\/bijwerkingen<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>net.core.netdev_budget<\/strong><\/td>\n      <td>Meer pakketten per NAPI-peiling<\/td>\n      <td>Voor druppels in softnet_stat<\/td>\n      <td>Langere polls verdringen gebruikersdiscussies<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.core.netdev_budget_usecs<\/strong><\/td>\n      <td>Tijdsvenster per peiling beperken<\/td>\n      <td>Voor jitter door grote bursts<\/td>\n      <td>Te klein: meer contextveranderingen<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>RSS\/RPS\/XPS<\/strong><\/td>\n      <td>Stromen verdelen over cores<\/td>\n      <td>Voor hotspots op een kern<\/td>\n      <td>Onjuiste hashes: cachevervormingen<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>IRQ affiniteit<\/strong><\/td>\n      <td>IRQ's dicht bij de kern binden<\/td>\n      <td>Met NUMA-Missmatch<\/td>\n      <td>Verkeerde toewijzing cre\u00ebert nieuwe hotspots<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>GRO\/LRO\/TSO<\/strong><\/td>\n      <td>Vermindert het aantal pakketten<\/td>\n      <td>Voor CPU-knelpunt<\/td>\n      <td>Jitter, grotere uitbarstingen<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Bezig met polling<\/strong><\/td>\n      <td>Vroeg ophalen van pakketten<\/td>\n      <td>Voor moeilijke p99-doelen<\/td>\n      <td>Meer CPU-verbruik<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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\/06\/developer_desk_focus_optimization_3748.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>RX\/TX-ringen en cue-diepte: buffers correct dimensioneren<\/h2>\n<p>Zelfs met goed verdeelde IRQ's en geschikte budgetten kunnen te kleine of te grote NIC-ringen de prestaties drukken. Ik controleer daarom de RX\/TX ringgroottes van de kaart en pas ze aan aan de burst karakter en latency targets. Te kleine ringen leiden tot druppels in de NIC tijdens verkeerspieken, zichtbaar als rx_missed_errors of fifo_errors in de statistieken van het stuurprogramma. Te grote ringen verhullen congestie, verhogen latency en cre\u00ebren lange trailing edges in p95\/p99. Ik ben op zoek naar de middenweg: genoeg buffer om korte uitbarstingen te absorberen, maar niet zoveel dat pakketten \u201cverouderen\u201d in wachtrijen.<\/p>\n<p>Daarnaast kijk ik naar de host-side <strong>tx_queue_len<\/strong> en de gebruikte Qdisc. Met sch_fq of fq_codel kan ik burstgedrag afvlakken en grote TSO pakketten verdelen via pacing. Dit vermindert microbursts op de switchpoort en maakt de latencycurve vloeiender - belangrijk voor gemengde workloads waarbij kleine RPC's naast grote uploads draaien. Ik monitor ethtool statistieken en correleer ze met softnet_stat om te herkennen of de congestie optreedt in de NIC-ring, in de netdev backlog of in de Qdisc.<\/p>\n\n<h2>MTU, jumbo frames en segmentatie<\/h2>\n<p>De <strong>MTU<\/strong> is een klassieke hefboom die vaak wordt onderschat. Jumbo frames verminderen het aantal pakketten per Gbit\/s en verminderen de belasting van de CPU - maar alleen als het pad echt end-to-end jumbo-capabel is. Daarom valideer ik systematisch de externe stations, switches en tunnels. Zodra er ergens terug naar 1500 gefragmenteerd wordt, is er een risico op pad MTU-problemen, heruitzendingen en onnodige <strong>Jitter<\/strong>. In datacenters met dominante Oost\/West communicatie is een homogene 9k strategie de moeite waard, terwijl 1500 vaak de stabielere keuze is voor Internet gerichte werklasten.<\/p>\n<p>Ik evalueer de MTU altijd in combinatie met <strong>TSO\/GSO\/GRO<\/strong>Te agressieve bundeling kan leiden tot grote uitbarstingen in de TX die upstream buffers vullen en latency pieken genereren. Het doel is een consistent pad: verstandige segmentatie bij de zender, voldoende pacingmechanismen en GRO dat werk bespaart aan de ontvangerkant zonder de real-time vereisten te doorkruisen.<\/p>\n\n<h2>UDP, QUIC en streaming werklasten: overweeg de specifieke kenmerken<\/h2>\n<p>Niet al het verkeer is TCP. <strong>UDP<\/strong>-zware profielen (DNS, VoIP, QUIC, telemetrie) gedragen zich anders in RSS\/RPS en GRO. Moderne stacks ondersteunen UDP-GRO\/GSO, wat de belasting van de CPU kan verminderen - ik gebruik dit selectief en meet of herordeningsrisico's of jitter toenemen. Voor QUIC\/HTTP3-belastingen is een schone stroomverdeling cruciaal: RPS kan helpen als de NIC te weinig RSS-wachtrijen biedt, maar mag geen hete cache-stromen \u201crondgooien\u201d. Aan de TX-kant stel ik <strong>XPS<\/strong> om transmissiepaden te bundelen en lock-conflicten te verminderen. In de praktijk loont een rustige, core-affine toewijzing, vooral met veel middelgrote UDP stromen waarbij elke cache hit telt.<\/p>\n\n<h2>Virtualisatie en containers: schone integratie van host, gast en vhost<\/h2>\n<p>In gevirtualiseerde omgevingen verschuift het werk tussen host, vhost threads en gast IRQ's. Ik zorg ervoor dat <strong>vhost-net<\/strong>-threads krijgen hun eigen cores en botsen niet met app workers. Hun affiniteiten moeten overeenkomen met de fysieke RX\/TX wachtrijen, anders vindt er onnodige cross-CPU migratie plaats. In de gast controleer ik virtio-net wachtrijen, activeer ik multi-queue en stel ik RSS\/RPS in analoog aan bare metal. Waar latency en pps op de voorgrond staan <strong>SR-IOV<\/strong> de overhead verder verminderen - de voorwaarde is een consistente NUMA-topologie: VF, vCPU en geheugen horen op hetzelfde knooppunt.<\/p>\n<p>In de containerstack veroorzaken overlay netwerken, diepe NAT-ketens en complexe CNI-topologie\u00ebn extra hops. Voor latency-kritische diensten geef ik de voorkeur aan hostNetwork of slanke netwerken (macvlan\/ipvlan), egaliseer NAT-paden en houd <strong>Conntrack<\/strong> zo klein mogelijk. Een consistente CPU strategie is belangrijk: IRQ en NAPI cores van de host moeten in de buurt liggen van de cores waarop vhost\/container workers draaien - dit is de enige manier om het gegevenspad kort en voorspelbaar te houden.<\/p>\n\n<h2>Planning, C-states en IRQ-threading<\/h2>\n<p>Omdat latentie niet alleen rekentijd is, maar ook <strong>Wektijd<\/strong> Ik minimaliseer diepe C-states op de latency cores. Een agressieve powersave kan milliseconden kosten voordat een SoftIRQ daadwerkelijk draait. Daarom vertrouw ik op prestatiebeheerders, beperk ik diepe C-states en houd ik de turbo consistent om frequentiesprongen voorspelbaar te maken. Net zo belangrijk is <strong>IRQ threading<\/strong>Waar stuurprogramma's het toelaten, verplaats ik werk naar IRQ threads en prioriteer ik zodat RX start voor downstream werk zonder userland volledig te verdringen. Het samenspel van sched policies, affiniteiten en budgetten is lastig; ik test stap voor stap, log p99 en kijk uit voor interferentie met ksoftirqd, dat anders een geheime bottleneck wordt.<\/p>\n\n<h2>Diepgaande observatie: spoorpunten, tellers, histo's<\/h2>\n<p>Als de metriek vaag blijft, ga ik een niveau dieper: ik gebruik kernel tracepoints rond <strong>netif_ontvangen_skb<\/strong>, <strong>napi_poll<\/strong> en <strong>net_dev_queue<\/strong>, om de duur van peilingen, pakketvolumes en wachttijden als histogrammen te bekijken. Zulke verdelingen laten zien of 1 % van de polls te lang duren of dat individuele wachtrijen opraken. Daarnaast kan ethtool-<strong>rx\/tx<\/strong>-tellers, TCP retransmits, busy poll hits en softnet_stat geven duidelijk aan waar pakketten verloren gaan. Ik gebruik druppelanalyse om te herkennen of de NIC pakketten laat vallen (ring vol), de netdev backlog instort (time_squeeze) of de Qdisc\/firewall vertraagt. Pas als deze stukjes van de puzzel in elkaar passen, ga ik ringen, budgetten of offloads aanpassen.<\/p>\n\n<h2>Beveiligings- en filterpaden stroomlijnen<\/h2>\n<p>Complexe ACL's, diepe nftables\/iptables ketens en brede conntrack tabellen voegen constante latency per pakket toe. Ik consolideer regels, werk met sets\/maps en verplaats generieke drops zo ver mogelijk naar voren in het pad - idealiter zo vroeg mogelijk op de NIC (XDP\/clsact) als latentie kritisch is. Stateless flows, telemetrie of bekende \u201cveilige\u201d poorten kunnen gericht gebruikt worden. <strong>zonder tracking<\/strong> om kostbare opzoekingen te elimineren. Tegelijkertijd houd ik de toestandstabellen fris, pas ik de hashgrootte aan op belastingspieken en ruim ik op agressieve wijze verweesde regels op. Het doel is een schoon, traceerbaar beleidspad dat in het profiel niet opvalt als een permanente belasting.<\/p>\n\n<h2>Typische anti-patronen en hoe ik ze vermijd<\/h2>\n<ul>\n  <li><strong>Alle IRQ's op \u00e9\u00e9n core:<\/strong> leidt tot congestie en hete ksoftirqd. Tegengif: gerichte affiniteiten per keu, NUMA-coherent.<\/li>\n  <li><strong>Blinde maximalisatie van ringen\/budgetten:<\/strong> Verbergt congestie, vergroot latentiestaarten. Tegengif: stapsgewijs verhogen, verdelingen meten.<\/li>\n  <li><strong>Onjuiste flow hashing configuratie:<\/strong> Stromen springen tussen cores, caches lopen uit. Tegengif: stabiele RSS-toetsen, RPS\/XPS alleen met een duidelijk doel.<\/li>\n  <li><strong>App threads op dezelfde cores als SoftIRQ's:<\/strong> Interferentie en jitter. Tegengif: harde scheiding, naburige toewijzing.<\/li>\n  <li><strong>Overlays\/NAT zonder budget:<\/strong> toegevoegd aan elke hop. Oplossing: Stroomlijn paden, host netwerken voor latency workloads.<\/li>\n  <li><strong>Energiebesparing op cores met latentie:<\/strong> Diepe C-states vertragen de reactie. Tegengif: prestatieregelaar, C-state beperking.<\/li>\n  <li><strong>Uitladen zonder meting:<\/strong> TSO\/GRO kan bursts en jitter verergeren. Oplossing: Werklastspecifiek activeren, p99 controleren.<\/li>\n<\/ul>\n\n<h2>Praktische hosting: stappen die werken<\/h2>\n<p>Ik begin met een schone meetfase, stel basisregels in en houd alle veranderingen klein in korte tijdsvensters zodat ik <strong>Oorzaken<\/strong> kunnen worden gescheiden. Vervolgens activeer ik irqbalance, controleer ik de automatische verdeling en stel ik, indien nodig, handmatige affiniteiten in totdat er geen <strong>Hotspots<\/strong> niet langer zichtbaar zijn. Vervolgens stel ik Multi-Queue, RSS en - indien nodig - RPS\/XPS in, gesynchroniseerd met NUMA. Ik bind de app workers aan cores in de buurt van hun IRQ cores, maar zonder directe botsingen. Tenslotte zuiver ik firewall paden, controleer ik conntrack tabellen en maak ik bewuste beslissingen over offloads gebaseerd op latency targets.<\/p>\n\n<h2>Voorbeeld afspeelboek voor p99 latenties<\/h2>\n<p>Eerst meet ik p95\/p99 via representatieve belasting en beveiligde logs van \/proc\/softirqs en \/proc\/net\/softnet_stat om <strong>Druppels<\/strong> en time_squeeze duidelijk zichtbaar zijn. Vervolgens verhoog ik stap voor stap netdev_budget of netdev_budget_usecs en houd ik p99 ingedrukt na elke wijziging, zodat ik echte <strong>Trends<\/strong> herkennen. Parallel daaraan bind ik IRQ's aan kernen van een NUMA-node en verplaats ik app-werkers naar geschikte buren. Als p99 blijft springen, test ik GRO\/LRO varianten en interrupt coalescing profielen, elk met een kort meetpad. Pas als de distributie stabiel blijft, zet ik de configuratie over naar Ansible rollen of systemd dropins.<\/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\/06\/serverraum-performance-1947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Korte versie voor admins<\/h2>\n<p>Ik bereik de grootste hefboomwerking door <strong>SoftIRQ's<\/strong>, NAPI budget, IRQ affiniteiten en app threads als een coherent gegevenspad. Ik verdeel netwerkwerk over cores, houd NUMA-coherente wachtrijen en verbind werkers verstandig zodat <strong>Routes<\/strong> kort blijven. Ik stel offloads bewust in en meet jitter in plaats van blindelings te optimaliseren voor doorvoer. Voor harde latency doelen vertrouw ik op busy polling en CPU isolatie, terwijl housekeeping CPU's interferentie onderscheppen. Als je deze stappen op een gedisciplineerde manier implementeert, krijg je constante doorvoer, smallere latentieverdelingen en een hostingomgeving die voorspelbaar reageert op belastingspieken.<\/p>","protected":false},"excerpt":{"rendered":"<p>Leer hoe softirq cpu-hosting met geoptimaliseerde linux interrupts, NAPI en IRQ-balancing uw netwerkdoorvoer verhoogt en latenties in serverwerking verlaagt.<\/p>","protected":false},"author":1,"featured_media":19562,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19569","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":"70","_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":"softirq cpu","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":"19562","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/19569","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=19569"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/19569\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/19562"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=19569"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=19569"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=19569"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}