{"id":19369,"date":"2026-05-15T11:51:18","date_gmt":"2026-05-15T09:51:18","guid":{"rendered":"https:\/\/webhosting.de\/server-irq-balancing-netzwerk-performance-optimierung-datacenter\/"},"modified":"2026-05-15T11:51:18","modified_gmt":"2026-05-15T09:51:18","slug":"server-irq-balancing-netwerkprestatieoptimalisatie-datacenter","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/server-irq-balancing-netzwerk-performance-optimierung-datacenter\/","title":{"rendered":"Server IRQ-balancering en netwerkprestaties voor hoogbelaste hosting"},"content":{"rendered":"<p>Hoge netwerkbelasting wordt bepaald door de effici\u00ebnte verwerking van <strong>IRQ server<\/strong> signalen: Als je interrupts verstandig verdeelt over CPU cores, verminder je latency en voorkom je drops. In deze handleiding laat ik je zien hoe je IRQ balancering, RSS\/RPS en CPU affiniteit op een praktische manier kunt combineren om hoogbelaste hosting duurzaam te maken. <strong>performant<\/strong> te bedienen.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>IRQ-verdeling<\/strong> voorkomt hotspots op afzonderlijke CPU-kernen.<\/li>\n  <li><strong>Multi-queue<\/strong> plus RSS\/RPS paralleliseert pakketverwerking.<\/li>\n  <li><strong>NUMA Aandacht<\/strong> vermindert toegang tussen knooppunten en latentie.<\/li>\n  <li><strong>CPU-gouverneur<\/strong> en thread pinning verbeteren de reactietijden.<\/li>\n  <li><strong>Controle<\/strong> Controleert pps, latencies, drops en coregebruik.<\/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\/05\/serverraum-hosting-0382.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>IRQ's kort uitgelegd: waarom ze de netwerkbelasting regelen<\/h2>\n\n<p>Voor elk inkomend pakket rapporteert de netwerkkaart via <strong>IRQ<\/strong>, dat er werk aan de gang is, anders zou de kernel actief moeten enqu\u00eateren. Als de opdracht op \u00e9\u00e9n core blijft staan, neemt het gebruik ervan toe, terwijl andere cores <strong>ongebruikt<\/strong> blijven. Dit is precies wanneer latenties groeien, de RX ring buffers vol raken en stuurprogramma's pakketten beginnen weg te gooien. Ik verdeel interrupts over geschikte kernen om pakketverwerking gelijkmatig en voorspelbaar te houden. Dit verlicht knelpunten, vlakt reactietijden af en beperkt pakketverliezen tot een minimum.<\/p>\n\n<h2>IRQ-balancering en CPU-affiniteit onder Linux<\/h2>\n\n<p>De service <strong>irqbalans<\/strong> verdeelt interrupts dynamisch, analyseert de belasting en verschuift de affiniteiten automatisch in de loop van de tijd. Voor extreme belastingsprofielen definieer ik affiniteiten handmatig via <code>\/proc\/irq\/\/smp_affiniteit<\/code> en binden signalen specifiek aan kernen van dezelfde <strong>NUMA<\/strong>-knooppunten. Deze combinatie van automatische en fijnafstelling helpt me om zowel basisbelastingen als pieken netjes te verwerken. Een diepgaande inleiding tot <a href=\"https:\/\/webhosting.de\/nl\/server-interruptverwerking-cpu-prestatieoptimalisatie-7342\/\">Interruptverwerking en CPU-optimalisatie<\/a> Ik gebruik ze om me te helpen bij mijn planning. Het blijft belangrijk: Ik koppel hardware topologie, IRQ distributie en applicatie threads consequent aan elkaar.<\/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\/05\/server_irq_balance_performance_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktisch gebruik van multi-queue NIC's, RSS en RPS<\/h2>\n\n<p>Moderne NIC's bieden verschillende RX\/TX-wachtrijen, waarbij elke wachtrij zijn eigen <strong>IRQ's<\/strong>, en Receive Side Scaling (RSS) verdeelt stromen over kernen. Als er niet genoeg hardware wachtrijen zijn, voeg ik Receive Packet Steering (RPS) en Transmit Packet Steering (XPS) toe aan de kernel voor extra <strong>Parallellisme<\/strong>. Met <code>ethtool -L ethX gecombineerd N<\/code> Ik pas het wachtrijnummer aan aan het core-nummer van het bijbehorende NUMA-knooppunt. Ik controleer met <code>ethtool -S<\/code> en <code>nstat<\/code>, of er drops, bezette polls of hoge pps-pieken optreden. Voor een fijnere afvlakking van de belasting gebruik ik ook <a href=\"https:\/\/webhosting.de\/nl\/interrupt-coalescing-netwerk-optimalisatie-serverflux\/\">Interrupt samenvoegen<\/a> in de planning zodat de NIC niet teveel individuele IRQ's genereert.<\/p>\n\n<p>De volgende tabel toont centrale componenten en typische commando's die ik gebruik voor een coherente opstelling:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Bouwsteen<\/th>\n      <th>Doel<\/th>\n      <th>Voorbeeld<\/th>\n      <th>Tip<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>irqbalans<\/strong><\/td>\n      <td>Automatische distributie<\/td>\n      <td><code>systemctl enable --now irqbalance<\/code><\/td>\n      <td>Uitgangspunt voor gemengde werklasten<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Affiniteit<\/strong><\/td>\n      <td>Fixes Pinning<\/td>\n      <td><code>echo mask &gt; \/proc\/irq\/XX\/smp_affinity<\/code><\/td>\n      <td>NUMA-toewijzing observeren<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Cues<\/strong><\/td>\n      <td>Meer parallellisme<\/td>\n      <td><code>ethtool -L ethX gecombineerd N<\/code><\/td>\n      <td>Overeenstemming met knooppuntkernen<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>RSS\/RPS<\/strong><\/td>\n      <td>Stromingsverdeling<\/td>\n      <td><code>sysfs: rps_cpus\/rps_flow_cnt<\/code><\/td>\n      <td>Nuttig voor een klein aantal NIC-wachtrijen<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>XPS<\/strong><\/td>\n      <td>Geordende TX pad-kernen<\/td>\n      <td><code>sysfs: xps_cpus<\/code><\/td>\n      <td>Vermijdt cache thrash<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Verstandig gebruik maken van automatische IRQ-balancering<\/h2>\n\n<p>Voor gemengde hostingservers is het vaak voldoende om het volgende te activeren <strong>irqbalans<\/strong>, omdat de daemon voortdurend belastingsverschuivingen herkent. Ik controleer de status via <code>systemctl status irqbalans<\/code> en kijk eens naar <code>\/proc\/onderbrekingen<\/code>, om de verdeling per wachtrij en kern te zien. Als latenties in pieken toenemen, definieer ik test cores die voornamelijk interrupts verwerken en vergelijk de gemeten waarden voor en na de verandering. Ik behoud de configuratie <strong>eenvoudig<\/strong>, zodat latere audits en rollbacks snel kunnen worden uitgevoerd. Pas als de patronen duidelijk zijn, ga ik dieper in op pinnen.<\/p>\n\n<h2>Handmatige CPU-affiniteit voor maximale controle<\/h2>\n\n<p>Bij zeer hoge pps-snelheden zet ik RX-wachtrijen vast op geselecteerde cores van dezelfde <strong>NUMA<\/strong>-nodes en applicatie-threads er bewust van scheiden. Ik isoleer individuele cores voor interrupts, laat workers draaien op naburige cores en besteed veel aandacht aan cache localiteit. Op deze manier verminder ik cross-node toegang en minimaliseer ik dure contextwisselingen in het hot path. Voor reproduceerbare resultaten documenteer ik duidelijk de IRQ maskers, de wachtrijtoewijzing en de thread affiniteit van de services. Deze duidelijkheid houdt de pakketruntijden <strong>constant<\/strong> en vermindert uitschieters.<\/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\/05\/server-performance-optimization-9876.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Schone co\u00f6rdinatie van CPU-optimalisatie en toepassingen<\/h2>\n\n<p>Ik heb de <strong>CPU-gouverneur<\/strong> vaak ingesteld op \u201eperformance\u201c omdat klokveranderingen de latency sprongen verhogen. Ik bind kritieke processen zoals Nginx, HAProxy of databases aan cores die dicht bij de IRQ cores liggen, of ik scheid ze bewust als het cacheprofiel dat vereist. Het blijft belangrijk om contextveranderingen te beperken en de kernel up-to-date te houden zodat optimalisaties in de net stack effect hebben. Ik meet de effecten van elke verandering in plaats van aannames te doen en pas ze stap voor stap aan. Dit resulteert in een setup die werkt onder belasting <strong>voorspelbaar<\/strong> reageert.<\/p>\n\n<h2>Bewaking en meting correct instellen<\/h2>\n\n<p>Zonder gemeten waarden blijft tuning een gokspelletje, dus ik begin met <strong>sar<\/strong>, <strong>mpstat<\/strong>, <strong>vmstat<\/strong>, <strong>nstat<\/strong>, <strong>ss<\/strong> en <code>ethtool -S<\/code>. Voor gestructureerde belastingstests gebruik ik <code>iperf3<\/code> en kijk naar doorvoer, pps, latency, retransmits en coregebruik. Ik leg langetermijntrends vast met standaard monitoringsystemen om patronen te herkennen zoals avondpieken, back-upvensters of campagnes. Als je het datapad holistisch wilt begrijpen, heb je baat bij een overzicht van de <a href=\"https:\/\/webhosting.de\/nl\/server-pakketverwerking-pijplijn-hosting-netwerk-router\/\">Pakketverwerkingspijplijn<\/a> van de IRQ van de NIC naar de gebruikersruimte. Alleen de combinatie van deze signalen laat zien of IRQ balancering en affiniteit het gewenste effect hebben bereikt. <strong>Effect<\/strong> brengen.<\/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\/05\/server_irq_balancing_4356.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NAPI, Softirqs en ksoftirqd begrijpen<\/h2>\n<p>Om latentiepieken met hoge pps-belastingen te beheren, houd ik rekening met de <strong>NAPI<\/strong>-mechanica en de interactie tussen harde IRQ's en zachte IRQ's. Na de eerste hardware IRQ haalt NAPI verschillende pakketten op uit de RX wachtrij in poll mode om IRQ stormen te vermijden. Als zachte IRQ's niet onmiddellijk verwerkt worden, worden ze verplaatst naar <code>ksoftirqd\/N<\/code> Threads die alleen met normale prioriteit draaien - een klassieke reden voor toenemende tail latencies. Ik observeer <code>\/proc\/softirqs<\/code> en <code>\/proc\/net\/softnet_stat<\/code>; een hoge \u201e<code>tijdsverschil<\/code>\u201cwaarde of dalingen geven aan dat het budget te krap is. Met <code>sysctl -w net.core.netdev_budget_usecs=8000<\/code> en <code>sysctl -w net.core.netdev_budget=600<\/code> Ik verhoog de verwerkingstijd per NIC poll en het pakketbudget als test. Belangrijk: ik verhoog de waarden geleidelijk, meet en controleer of CPU jitter of interferentie met applicatie-threads optreedt.<\/p>\n\n<h2>RSS hash- en indirigatietabel fijn afstellen<\/h2>\n<p>RSS verdeelt stromen naar wachtrijen via de indirigatietabel (RETA). Ik controleer de hashsleutel en tabel met <code>ethtool -n ethX rx-flow-hash tcp4<\/code> en stel de verdeling indien nodig symmetrisch in. Met <code>ethtool -X ethX gelijk N<\/code> of specifiek per vermelding (<code>ethtool -X ethX hkey ... hfunc toeplitz indir 0:1 1:3 ...<\/code>), koppel ik toewijzingen aan de voorkeurskernen van een NUMA-knooppunt. Het doel is <strong>Kleverigheid van de stroom<\/strong>Een stroom blijft op dezelfde core zodat cache localiteit en lock retentie in de stack minimaal blijven. Voor omgevingen met veel korte UDP-stromen verhoog ik <code>rps_stroom_cnt<\/code> per RX-wachtrij zodat de softwaredistributie genoeg buckets heeft en geen hotspots cre\u00ebert. Ik houd in gedachten dat symmetrische hashes helpen bij ECMP-topologie\u00ebn, maar in de servercontext is core-balans het belangrijkst.<\/p>\n\n<h2>Kies uitladingen, GRO\/LRO en ringmaten op een verstandige manier<\/h2>\n<p>Hardware offloads verminderen de belasting op de CPU, maar kunnen latentieprofielen veranderen. Ik controleer met <code>ethtool -k ethX<\/code>, of <strong>TSO\/GSO\/UDP_SEG<\/strong> op TX en <strong>GRO\/LRO<\/strong> actief zijn op RX. GRO bundelt pakketten in de kernel en is bijna altijd nuttig voor doorvoer; LRO kan problematisch zijn in routerings- of filteropstellingen en kan daar beter uitgeschakeld worden. Voor latency-kritische API's test ik kleinere GRO aggregatie (of tijdelijk uit) als p99 latencies domineren. Ik pas ook ringgroottes aan via <code>ethtool -G ethX rx 1024 tx 1024<\/code>Grotere ringen onderscheppen uitbarstingen, maar verhogen de latentie bij congestie; te kleine ringen leiden tot <code>rx_gemiste_fouten<\/code>. Ik vertrouw op gemeten waarden van <code>ethtool -S<\/code> (bijv. <code>rx_no_buffer_count<\/code>, <code>rx_verloren<\/code>) en dit afspreken met <strong>BQL<\/strong> (byte queue-limieten, automatisch aan de kernelzijde) zodat TX-wachtrijen niet overvoerd worden.<\/p>\n\n<h2>Virtualisatie: IRQ's in VM's en op de hypervisor<\/h2>\n\n<p>In gevirtualiseerde opstellingen beheer ik de fysieke NIC-verdeling op de host en stel ik <strong>IRQ-balancering<\/strong> duidelijk. VM's krijgen genoeg vCPU's, maar ik vermijd blinde overcommitment zodat planningsvertragingen de latency niet verhogen. Moderne paravirtualised drivers zoals virtio-net of vmxnet3 bieden me de betere paden voor hoge pps-snelheden. Binnen de VM controleer ik opnieuw affiniteit en wachtrijtelling zodat de gast geen bottleneck wordt. Het is cruciaal om een consistent beeld te hebben van de host en de gast zodat het volledige gegevenspad <strong>Echt<\/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\/05\/server_irq_balance_net_5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Diepere virtualisatie: SR-IOV, vhost en OVS<\/h2>\n<p>Voor zeer hoge pps-snelheden gebruik ik de hypervisor <strong>SR-IOV<\/strong>Ik bind virtuele functies (VF's) van de fysieke NIC direct aan VM's en pin ze vast aan kernen van de juiste NUMA-knooppunten. Dit omzeilt delen van de host stack en vermindert latency. Waar SR-IOV niet past, besteed ik aandacht aan <strong>vhost-net<\/strong> en pin de vhost threads zoals applicatiewerkers en IRQ cores zodat er geen cross-NUMA jumps optreden. In overlay of switching opstellingen evalueer ik de extra kosten van Linux bridge of OVS; voor extreme profielen gebruik ik alleen OVS-DPDK als de operationele inspanning het meetbare voordeel rechtvaardigt. Hetzelfde geldt hier: ik meet pps, latency en CPU-verdeling voordat ik beslissingen neem, niet achteraf.<\/p>\n\n<h2>Drukke polling en gebruikersruimte tuning<\/h2>\n<p>Voor latentiekritieke diensten <strong>Bezig met polling<\/strong> de jitter verminderen. Ik activeer het volgende als test <code>sysctl -w net.core.busy_read=50<\/code> en <code>net.core.busy_poll=50<\/code> (microseconden) en stel de socketoptie <code>SO_BUSY_POLL<\/code> selectief voor betrokken sockets. De gebruikersruimte peilt dan kort voor het blokkeren en vangt pakketten op voordat ze dieper in de wachtrijen terecht komen. Dit kost CPU-tijd, maar levert vaak stabielere p99 latencies op. Ik houd de waarden laag, monitor het core gebruik en combineer busy polling alleen met duidelijke thread affiniteit en een vaste CPU gouverneur, anders heffen de effecten elkaar op.<\/p>\n\n<h2>Kosten voor pakketfilter, Conntrack en eBPF in \u00e9\u00e9n oogopslag<\/h2>\n<p>Firewalling en NAT maken deel uit van het gegevenspad. Daarom controleer ik de <strong>nftables\/iptables<\/strong>-regels en ruim ik dode regels of diepe ketens op. In drukke opstellingen pas ik de Conntrack tabelgrootte aan (<code>nf_conntrack_max<\/code>, hash bucket nummer) of deactiveer Conntrack specifiek voor stateless flows. Als eBPF-programma's (XDP, tc-BPF) worden gebruikt, meet ik hun runtimekosten per hook en geef ik prioriteit aan \u201eearly drop\/redirect\u201c om dure paden te ontlasten. Een duidelijke verantwoordelijkheid is belangrijk: of de optimalisatie vindt plaats in de NIC offload, in het eBPF programma of in de klassieke stack - duplicatie verhoogt alleen de latentie.<\/p>\n\n<h2>CPU-isolatie en huishoudelijke cores<\/h2>\n<p>Voor absoluut deterministische latentie sla ik achtergrondwerk op <strong>Huishoudelijke CPU's<\/strong> uit. Kernelparameters zoals <code>nohz_full=<\/code>, <code>rcu_nocbs=<\/code> en <code>irqaffiniteit=<\/code> helpen om specifieke cores grotendeels vrij te houden van tick handling, RCU callbacks en externe IRQ's. Ik isoleer een set kernen voor applicatiewerkers en een andere voor IRQ's en softirq's; systeemservices en timers draaien op aparte kernen. Dit zorgt voor schone cacheprofielen en vermindert pre-emption effecten. Hyper-threading kan jitter verhogen in individuele gevallen; ik test of het uitschakelen ervan per core-paar de p99 latencies afvlakt voordat ik een globale beslissing neem.<\/p>\n\n<h2>Diagnostisch draaiboek en typische antipatronen<\/h2>\n<p>Wanneer er druppels of latentiepieken optreden, hanteer ik een gestructureerde aanpak: 1) <code>\/proc\/onderbrekingen<\/code> Controleer op ongelijkmatige verdeling. 2) <code>ethtool -S<\/code> bij RX\/TX-dalingen, FIFO-fouten, <code>rx_no_buffer_count<\/code> controle. 3) <code>\/proc\/net\/softnet_stat<\/code> naar \u201e<code>tijdsverschil<\/code>\" of \"<code>druppels<\/code>\u201c. 4) <code>mpstat -P ALL<\/code> en <code>top<\/code> voor ksoftirqd activiteit. 5) Toepassingsgegevens (aantal actieve verbindingen, heruitzendingen met <code>ss -ti<\/code>). Antipatronen die ik vermijd: enorme RX-ringen (verborgen congestie), het in het wilde weg in- en uitschakelen van offloads zonder meting, het mengen van vaste affiniteiten met agressieve irqbalance, of RPS en RSS tegelijkertijd zonder duidelijke doelarchitectuur. Elke verandering krijgt een meting voor\/na vergelijking en een kort protocol.<\/p>\n\n<h2>Voorbeeldconcepten voor webhosting en API's<\/h2>\n\n<h3>Klassieke webhostingserver<\/h3>\n<p>Voor veel kleine websites activeer ik <strong>irqbalans<\/strong>, Ik stel verschillende wachtrijen in en selecteer de prestatiegouverneur. Ik meet L7 latencies tijdens pieken en let op pps-pieken, die vooral optreden bij TLS en HTTP\/2. Als hardwarewachtrijen niet voldoende zijn, voeg ik RPS toe voor extra distributie op softwareniveau. Deze aanpassing houdt de responstijden <strong>constant<\/strong>, zelfs als de algehele bezettingsgraad matig lijkt. Regelmatige controles van <code>\/proc\/onderbrekingen<\/code> Laat me zien of individuele kernen kantelen.<\/p>\n\n<h3>Hoog belaste reverse proxy of API-gateway<\/h3>\n<p>Voor frontends met een groot aantal verbindingen pin ik RX-wachtrijen fijnmazig vast op gedefinieerde kernen en plaats ik proxy-werkers op nabijgelegen kernen. Ik maak een bewuste keuze of irqbalance actief blijft of dat vaste pinning duidelijkere resultaten oplevert. Als er niet genoeg wachtrijen zijn, selecteer ik specifiek RPS\/XPS en kalibreer ik <strong>Coalescing<\/strong>, om IRQ stormen te voorkomen. Op deze manier bereik ik een lage latency bij een zeer hoge pps-snelheid en houd ik de tail latencies onder controle. Documentatie van elke wijziging vergemakkelijkt latere audits en houdt het gedrag <strong>voorspelbaar<\/strong>.<\/p>\n\n<h2>Keuze van leverancier en hardwarecriteria<\/h2>\n\n<p>Ik let op NIC's met <strong>Multi-queue<\/strong>, betrouwbare latency in de backbone en up-to-date kernelversies van het platform. Een gebalanceerde CPU-topologie en een duidelijke NUMA-scheiding voorkomen dat netwerkinterrupts in afgelegen geheugenzones terechtkomen. Voor projecten met hoge pps-percentages honoreert de keuze van de infrastructuur elk uur tuning omdat de hardware reserves levert. In praktische vergelijkingen heb ik goed gewerkt met providers die prestatieprofielen openbaar maken en IRQ-vriendelijke standaardinstellingen bieden, zoals providers als webhoster.de. Met dergelijke opstellingen kan ik IRQ-balancing, RSS en affiniteit effectief gebruiken en de responstijden minimaliseren. <strong>eng<\/strong> om vast te houden.<\/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\/05\/serverraum-performance-2468.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Stap-voor-stap procedure voor je eigen afstemming<\/h2>\n\n<p><strong>Stap 1:<\/strong> Ik bepaal de huidige status met <code>iperf3<\/code>, <code>sar<\/code>, <code>mpstat<\/code>, <code>nstat<\/code> en <code>ethtool -S<\/code>, zodat ik duidelijke beginwaarden heb. <strong>Stap 2:<\/strong> Als irqbalance niet draait, activeer ik de service, wacht onder belasting en vergelijk latency, pps en drops. <strong>Stap 3:<\/strong> Ik pas het wachtrijnummer en de RSS-configuratie aan de kernen van het bijbehorende NUMA-knooppunt aan. <strong>Stap 4:<\/strong> Ik stel de CPU-governor in op \u201eperformance\u201c en wijs centrale services toe aan de juiste cores. <strong>Stap 5:<\/strong> Pas daarna pas ik handmatige affiniteit en NUMA pinning aan als de gemeten waarden nog steeds bottlenecks laten zien. <strong>Stap 6:<\/strong> Ik controleer trends in de loop van dagen om pieken in evenementen, back-ups of marketingpieken betrouwbaar te kunnen categoriseren.<\/p>\n\n<h2>Kort samengevat<\/h2>\n\n<p>Effectief <strong>IRQ-balancering<\/strong> verdeelt netwerkwerk over geschikte cores, vermindert latencies en voorkomt drops bij hoge pps-snelheden. In combinatie met multi-queue NIC's, RSS\/RPS, een geschikte CPU-governor en schone thread affiniteit, maak ik op een betrouwbare manier gebruik van de net stack. Gemeten waarden van <code>ethtool -S<\/code>, <code>nstat<\/code>, <code>sar<\/code> en <code>iperf3<\/code> me stap voor stap naar mijn doel leiden in plaats van in het duister te tasten. Als je nadenkt over NUMA topologie, IRQ pinning en plaatsing van applicaties samen, dan kun je reactietijden tot een minimum beperken. <strong>laag<\/strong> - zelfs tijdens piekbelastingen. Dit betekent dat hosting met hoge belasting merkbaar responsief blijft zonder onnodige CPU-reserves te verbranden.<\/p>","protected":false},"excerpt":{"rendered":"<p>Leer hoe u de netwerkprestaties van uw Linux-servers kunt verbeteren en hostingopstellingen effici\u00ebnter kunt maken door u te richten op server IRQ-balancing.<\/p>","protected":false},"author":1,"featured_media":19362,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19369","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":"110","_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":"Server IRQ","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":"19362","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/19369","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=19369"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/19369\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/19362"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=19369"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=19369"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=19369"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}