{"id":20682,"date":"2026-08-15T18:19:23","date_gmt":"2026-08-15T16:19:23","guid":{"rendered":"https:\/\/webhosting.de\/bcc-tools-linux-performance-ebpf-observability-focus\/"},"modified":"2026-08-15T18:19:23","modified_gmt":"2026-08-15T16:19:23","slug":"bcc-tools-linux-prestaties-ebpf-observabiliteit-focus","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/bcc-tools-linux-performance-ebpf-observability-focus\/","title":{"rendered":"bcc tools in de praktijk: Praktische handleiding voor Linux Performance Engineering met eBPF"},"content":{"rendered":"<p>Ik leg stap voor stap uit hoe ik <strong>bcc-tools<\/strong> ik gebruik eBPF om knelpunten op Linux-servers snel te lokaliseren en op te lossen. Daarbij maak ik gebruik van praktische workflows, meet ik de werkelijke latentie in de kernel en koppel ik gebeurtenissen uit de CPU, I\/O en het netwerk aan een <strong>duidelijk<\/strong> Oorzakenanalyse.<\/p>\n\n<h2>Centrale punten<\/h2>\n<ul>\n  <li><strong>eBPF<\/strong> biedt diepgaande tracering met een lage overhead.<\/li>\n  <li><strong>bcc-tools<\/strong> hebben betrekking op de CPU, I\/O, het netwerk en processen.<\/li>\n  <li><strong>Productiegerelateerd<\/strong> te gebruiken zonder aanpassingen aan de app.<\/li>\n  <li><strong>Checklist<\/strong> met tien gereedschappen om mee te beginnen.<\/li>\n  <li><strong>Beveiliging<\/strong> door middel van verificatie en duidelijke beleidsregels.<\/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-performance-ebpf-4976.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Waarom eBPF voor Linux Performance Engineering<\/h2>\n<p>Ik reik naar <strong>eBPF<\/strong>, omdat ik kernelgebeurtenissen op een veilige, selectieve manier en met zeer weinig overhead wil meten. Klassieke tools geven totalen weer, maar leggen zelden uit waarom threads wachten, pakketten opnieuw worden verzonden of I\/O vastloopt; eBPF vult deze leemte met <strong>concrete<\/strong> Events. De programma\u2019s draaien in de kernel, de verifier controleert ze vooraf en ik kan ze starten zonder opnieuw op te starten. Zo breng ik userland-aanroepen in verband met kernelpaden en krijg ik een beeld dat directe optimalisaties mogelijk maakt. Wie zich hier verder in wil verdiepen, vindt een overzicht in mijn korte inleiding over de <a href=\"https:\/\/webhosting.de\/nl\/ebpf-prestatieanalyse-linux-tracing-servermonitoring-observability\/\">eBPF-prestatieanalyse<\/a>, waarin de wisselwerking tussen tracing en observability wordt geschetst.<\/p>\n\n<h2>Wat zijn BCC-tools en waar kan ik ze vinden?<\/h2>\n<p>De <strong>bcc<\/strong> tools zijn kant-en-klare diagnoseprogramma\u2019s op basis van eBPF en bevinden zich doorgaans in \/usr\/share\/bcc\/tools. Ik start ze rechtstreeks vanuit de shell, krijg duidelijke standaarduitvoer en hoef mijn applicaties niet aan te passen. De verzameling omvat processen, systeemaanroepen, bestandssystemen, blok-I\/O, netwerk, schedulers en profilering en is daarmee geschikt voor <strong>productief<\/strong> Analyses. Aangezien ik tracing doelgericht activeer, blijft de invloed beperkt en zijn meetfouten als gevolg van monitoring gering. Voor meer diepgaande gevallen vul ik de tools aan met eigen eBPF of maak ik bovendien gebruik van sampling-profielen.<\/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\/bcc_tools_linux_eBPF_7438.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Installatie en vereisten<\/h2>\n<p>Ik installeer de <strong>bcc<\/strong> tools via het pakketbeheer (bcc-tools of bpfcc-tools) op gangbare distributies. Vereist zijn een kernel met eBPF-ondersteuning (vanaf 4.x, bij voorkeur 4.9+), geactiveerde BPF-functies en voldoende rechten om de programma\u2019s te laden. Op productieve servers controleer ik vooraf in een testomgeving of de kernel en de distributie eBPF ondersteunen, zodat latere metingen <strong>betrouwbare<\/strong> draaien. Beveiligingsprofielen die eBPF volledig blokkeren, voorkom ik door middel van afgestemde beleidsregels. De beknopte aanwijzingen over geven een praktisch overzicht van de installatie en bediening <a href=\"https:\/\/webhosting.de\/nl\/ebpf-linux-analysetools-servermonitoring-inzichten\/\">eBPF-analysetools<\/a>.<\/p>\n\n<h2>Voor de start: systeem- en veiligheidscontroles<\/h2>\n<p>Voordat ik in de productie metingen uitvoer, controleer ik de basisvaardigheden van de host. Zo voorkom ik valse starts en krijg ik reproduceerbare resultaten.<\/p>\n<ul>\n  <li>Kernelfuncties controleren: <code>uname -r<\/code> en beschikbare BPF-functies (bijvoorbeeld via Feature-Check). Belangrijk zijn kprobes\/tracepoints, BTF (voor stabiele type-informatie) en perf-events.<\/li>\n  <li>Rechten en beleidsregels: Ik zorg ervoor dat alleen bevoegde gebruikers eBPF mogen laden (CAP_BPF\/CAP_SYS_ADMIN of een overeenkomstig beleid) en dat LSM-profielen het laden niet blokkeren.<\/li>\n  <li>Systeemparameters: <code>kernel.unprivileged_bpf_uitgeschakeld<\/code> is meestal actief in productieve omgevingen. Daarom werk ik bewust vanuit beveiligde sessies en met duidelijke controle.<\/li>\n  <li>Transparante paden: Ik gebruik mappen zoals <code>\/sys\/kernel\/debug\/tracing<\/code> en <code>\/sys\/fs\/bpf<\/code> in het oog houden om artefacten na metingen te verwijderen.<\/li>\n<\/ul>\n<p>Deze hygi\u00ebne zorgt ervoor dat ik metingen doelgericht en reproduceerbaar kan uitvoeren \u2013 zonder neveneffecten.<\/p>\n\n<h2>Praktische gids: De eerste tien hulpmiddelen<\/h2>\n<p>Voor een snelle prestatiecontrole volg ik een vaste volgorde. Zo kan ik oorzaken op het gebied van CPU, I\/O of netwerk duidelijk afbakenen en beslissen of ik dieper in de stacks of timings moet duiken. De tabel toont de kerntaak van de tools en de vraag die ik daarmee wil beantwoorden. Ik houd de looptijd in eerste instantie kort en herhaal de metingen zodra ik een vermoeden heb <strong>bevestigen<\/strong> wil. Zo voorkom ik blinde vlekken en verspil ik geen tijd bij acute <strong>Incidenten<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Gereedschap<\/th>\n      <th>Waargenomen<\/th>\n      <th>Typische vraag<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>execsnoop<\/td>\n      <td>Nieuwe processen<\/td>\n      <td>Wie neemt tijdelijke banen aan die voor extra werk zorgen?<\/td>\n    <\/tr>\n    <tr>\n      <td>opensnoop<\/td>\n      <td>Bestanden openen<\/td>\n      <td>Welke paden worden voortdurend geopend of geregistreerd?<\/td>\n    <\/tr>\n    <tr>\n      <td>ext4 is langzamer (xfs*, btrfs*, zfs*)<\/td>\n      <td>Trage FS-bewerkingen<\/td>\n      <td>Welke verzoeken vertonen hoge latentie per volume?<\/td>\n    <\/tr>\n    <tr>\n      <td>biolatency<\/td>\n      <td>Block-I\/O-verdeling<\/td>\n      <td>Zijn er sporadische of aanhoudende pieken in de latentie?<\/td>\n    <\/tr>\n    <tr>\n      <td>biosnoop<\/td>\n      <td>Afzonderlijke I\/O-verzoeken<\/td>\n      <td>Welk proces brengt bepaalde apparaten tot stilstand?<\/td>\n    <\/tr>\n    <tr>\n      <td>cachestat<\/td>\n      <td>Gedrag van de paginacache<\/td>\n      <td>Is meer RAM de moeite waard of vertoont de app dan storingen?<\/td>\n    <\/tr>\n    <tr>\n      <td>tcpconnect<\/td>\n      <td>Nieuwe TCP-verbindingen<\/td>\n      <td>Wie maakt hoe vaak gebruik van welke dienst?<\/td>\n    <\/tr>\n    <tr>\n      <td>tcpaccept<\/td>\n      <td>Goedgekeurde verbindingen<\/td>\n      <td>Welke serversockets staan onder zware belasting?<\/td>\n    <\/tr>\n    <tr>\n      <td>tcpretrans<\/td>\n      <td>Heruitzendingen<\/td>\n      <td>Wijst het verlies van pakketten op onstabiele routes?<\/td>\n    <\/tr>\n    <tr>\n      <td>runqlat<\/td>\n      <td>Vertragingen in de scheduler<\/td>\n      <td>Wachten threads te lang op CPU-tijd?<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>Ik gebruik ook <strong>profielen<\/strong> om hotspots in de gebruikers- of kernelruimte te detecteren en call-stacks samen te voegen. Zo ontdek ik kostbare reguliere expressies, ineffici\u00ebnte stuurprogramma\u2019s of spinlocks, die ik vervolgens in de code of in de configuratie oplos. Ik gebruik korte bemonsteringsintervallen en vergelijk meerdere runs, zodat uitschieters <strong>zichtbaar<\/strong> wordt. Deze combinatie van overzicht en diepgang bespaart me veel analysetijd. Vervolgens test ik de optimalisatie opnieuw onder dezelfde belasting.<\/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-performance-ebpf-tools-4528.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Uitbreiding: Off-CPU, vergrendelingen en wachttijden zichtbaar maken<\/h2>\n<p>Niet elke hoge latentie is CPU-gebonden. Vaak wachten threads \u201eoff-CPU\u201c op I\/O, locks of wake-ups. Hier bieden aanvullende bcc-tools en -profielen uitkomst:<\/p>\n<ul>\n  <li>Off-CPU-analyse: ik meet hoe lang threads niet op de CPU actief zijn en welke stacks daar naartoe leiden. Dit maakt een onderscheid tussen rekentijd en wachttijd en brengt blokkerende factoren aan het licht.<\/li>\n  <li>Lock-contention: Ik richt mijn aandacht specifiek op kritieke locks in de kernel en de gebruikersruimte. Lange wachttijden of hoge contention wijzen op serialisatiepunten die ik doorbreek (bijvoorbeeld door sharding, fijnere granulariteit of andere gegevensstructuren).<\/li>\n  <li>Wakeup-paden: vertragingen tussen \u201eis geactiveerd\u201c en \u201edraait weer\u201c wijzen op problemen met de planning en prioriteiten of op te grote worker-pools.<\/li>\n<\/ul>\n<p>Ik breng deze signalen in verband met <strong>runqlat<\/strong> en <strong>biolatency<\/strong>, om onderscheid te maken tussen oorzaken die te maken hebben met het geheugen, I\/O en de scheduler.<\/p>\n\n<h2>Meethygi\u00ebne: filters, duur, drempelwaarden<\/h2>\n<p>Om ervoor te zorgen dat eBPF-metingen reproduceerbaar blijven, hanteer ik drie basisregels:<\/p>\n<ul>\n  <li>Kort en bondig: ik laat tools in eerste instantie slechts kort draaien (bijvoorbeeld 10\u201330 seconden) en richt me op verdachte PID\u2019s, containers of sockets.<\/li>\n  <li>Drempels instellen: Bij \u201e*slower\u201c-tools filter ik kleine latenties eruit om de ruis te verminderen en alleen problematische calls te zien.<\/li>\n  <li>Het aantal gebeurtenissen beperken: Ik gebruik selectieve filters (bijv. procesnaam, TID's, poorten) om het aantal gebeurtenissen laag te houden. Zo blijft de overhead minimaal en voorkom ik dat gebeurtenissen verloren gaan.<\/li>\n<\/ul>\n<p>Pas als ik een patroon zie, verleng ik de looptijd of breid ik de reikwijdte uit. Daardoor krijg ik <strong>schoon<\/strong> en betrouwbare steekproeven.<\/p>\n\n<h2>Praktijkscenario 1: Onverklaarbaar hoge CPU-belasting<\/h2>\n<p>Als de CPU-indicator voortdurend hoge waarden aangeeft, begin ik met <strong>execsnoop<\/strong>, om kortstondige processen te herkennen. Vervolgens meet ik met runqlat hoe lang threads op CPU-tijd moeten wachten, en controleer ik of de runqueues overvol zijn of dat de prioriteiten onjuist zijn ingesteld. Als er opvallende wachttijden optreden, verminder ik het aantal workers, pas ik de threadpools aan of spreid ik de cronjobs uit, zodat de scheduler <strong>grijper<\/strong> kan. Met profile verzamel ik stacks en vind ik de echte hotspots in bibliotheken en in mijn eigen code. Pas als ik deze aanwijzingen samenbreng, neem ik beslissingen over limieten, garbage collection, affiniteiten of compiler-flags.<\/p>\n\n<h2>Praktijkscenario 2: I\/O-latenties en trage toepassingen<\/h2>\n<p>Als gebruikers klagen over vastlopers bij een lage CPU-belasting, controleer ik met <strong>ext4 is trager<\/strong> trage bestandssysteemoproepen per proces. Vervolgens bekijk ik met biolatency de verdeling van de blok-I\/O-tijden per apparaat, om sporadische pieken of aanhoudende knelpunten op te sporen. biosnoop laat me zien of een enkele dienst een ongezond aantal kleine schrijfbewerkingen genereert en daarmee wachtrijen veroorzaakt die andere processen vertragen. Met cachestat zie ik of de paginacache raak is of dat er misses zijn <strong>domineren<\/strong> en meer RAM zou helpen. Uiteindelijk beslis ik of batch-writes, grotere buffers of een overstap naar snellere opslag de moeite waard zijn.<\/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\/tech_office_nachtarbeit_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktijkscenario 3: Netwerkpaden en microservices<\/h2>\n<p>In gedistribueerde omgevingen begin ik met <strong>tcpconnect<\/strong>, om het tot stand brengen van verbindingen tussen diensten te meten. Vervolgens controleer ik met tcpaccept welke serversockets bijzonder veel inkomende verbindingen hebben en of de limieten aan de listener-zijde van kracht zijn. tcpretrans brengt herhalingsverzendingen aan het licht en maakt onderscheid tussen transportproblemen en applicatiefouten, voordat ik time-outs en herpogingen aanpas. Aan de hand van deze drie signalen kan ik zien of het netwerk, de app of een upstream-service de <strong>Latency<\/strong> stuur ik aan. Daarna pas ik de backoff-strategie\u00ebn, keepalive-waarden, load balancer-instellingen en buffergroottes aan.<\/p>\n\n<h2>Bedrijfsveiligheid en betrouwbaarheid van eBPF<\/h2>\n<p>Ik upload alleen <strong>betrouwbaar<\/strong> Ik gebruik tools en test mijn eigen eBPF-programma\u2019s eerst op de staging-omgeving. De kernel-verifier blokkeert foutieve programma\u2019s, maar ik stel bovendien limieten in voor maps en buffers, zodat het geheugen netjes binnen de grenzen blijft. Ik bewaar de logbestanden om het gedrag en de neveneffecten in de gaten te houden en indien nodig snel in te grijpen. Beleidsregels bepalen wie eBPF mag laden, zodat de controle bij het platformteam blijft en aan de beveiligingseisen wordt voldaan. Deze regels zorgen ervoor dat tracing in productieomgevingen <strong>Betrouwbaar<\/strong> blijft zoals het is en zorgt niet voor verrassingen.<\/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\/entwickler_schreibtisch_tools_4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Container- en Kubernetes-omgevingen<\/h2>\n<p>In containers maak ik een onderscheid tussen systematische problemen en pod-specifieke effecten. Hiervoor filter ik metingen op cgroup, namespace of PID-bereik. Veel bcc-tools bieden de mogelijkheid om te filteren op procesnamen of -ID's; als alternatief voer ik metingen uit op de host en wijs ik gebeurtenissen via cgroup toe aan de workloads. Belangrijk:<\/p>\n<ul>\n  <li>PID-naamruimte: PID\u2019s verschillen tussen host en container. Ik koppel de ID\u2019s aan elkaar of filter op basis van procesnamen\/poorten.<\/li>\n  <li>Quota\u2019s voor systeembronnen: CPU-throttling als gevolg van CFS-quota\u2019s uit zich in lange wachttijden zonder dat het systeem volledig wordt benut. Ik merk dit aan <strong>runqlat<\/strong> in combinatie met quota-statistieken.<\/li>\n  <li>Netwerknaamruimten: Bij socketanalyses let ik op de juiste naamruimte. Ik voer metingen uit op de host-interface en breng deze in verband met pod-IP-adressen en poorten.<\/li>\n<\/ul>\n<p>Zo blijven de meetresultaten betrouwbaar, zelfs als er veel workloads dicht bij elkaar draaien.<\/p>\n\n<h2>Integratie in observability-stacks<\/h2>\n<p>Ik vervang mijn monitoring niet, maar vul deze aan met <strong>eBPF<\/strong>. bcc-tools bieden mij de diepgang, terwijl metricsystemen, logs en APM de breedte laten zien; samen vormen ze een samenhangend beeld. Indien nodig leid ik traces uit bcc door naar log-pijplijnen, activeer ik snapshots bij incidenten en documenteer ik de bevindingen binnen het team. Voor gerichte profielen gebruik ik sampling naast tijdlijnen op basis van metrics, zodat afwijkingen <strong>tastbaar<\/strong> worden. Wie daarnaast de voorkeur geeft aan scripting, vindt in <a href=\"https:\/\/webhosting.de\/nl\/bpftrace-serverproblemen-bij-hosting-sneller-opsporen-en-diagnosticeren\/\">bpftrace in de hostingomgeving<\/a> een eenvoudige manier om ad-hocvragen met miniscripts te beantwoorden.<\/p>\n\n<h2>Veelvoorkomende struikelblokken \u2013 en hoe ik ze omzeil<\/h2>\n<ul>\n  <li>Noisy Neighbor: afzonderlijke taken veroorzaken een kortstondige, maar intense belasting. <strong>execsnoop<\/strong> plus <strong>profielen<\/strong> Deze patronen worden hierdoor betrouwbaar aan het licht gebracht; ik werk er met timeboxes mee of isoleer ze aan de hand van quota.<\/li>\n  <li>NUMA en affiniteiten: hoge latenties ondanks beschikbare cores duiden op Cross-NUMA-toegangen. Ik controleer de CPU-affiniteiten, het geheugengebruik en de IRQ-verdeling.<\/li>\n  <li>IRQ\/SoftIRQ-hotspots: de netwerkbelasting kan de ksoftirqd-kernels overbelasten. Ik houd heruitzendingen in de gaten, verdeel IRQ\u2019s via RSS\/wachtrijen en pas RPS\/XPS aan.<\/li>\n  <li>Effecten van de paginacache: koude starts verlopen trager. Ik houd rekening met opwarmfasen en vergelijk <strong>cachestat<\/strong>-Waarden v\u00f3\u00f3r en na belasting.<\/li>\n  <li>Kernel-updates: Kprobes kunnen bij versiesprongen veranderen. Ik geef de voorkeur aan stabiele tracepoints, test ze van tevoren en houd een minimale set bij de hand.<\/li>\n<\/ul>\n\n<h2>Werkprocessen die hun waarde hebben bewezen<\/h2>\n<ul>\n  <li>Incident-snapshot: 60\u2013120 seconden gecombineerde run (execsnoop, runqlat, biolatency, tcpretrans, profile). Daarna richt ik me op het opvallende subsysteem.<\/li>\n  <li>Baseline-routine: wekelijks korte metingen op kernpaden (bijv. opslag- en netwerkprofiel). Zo kan ik afwijkingen in een vroeg stadium opmerken.<\/li>\n  <li>Validatie van wijzigingen: Voor en na configuratiewijzigingen vergelijk ik dezelfde meetpunten om het effect meetbaar te maken.<\/li>\n<\/ul>\n\n<h2>Continue Linux-prestatieoptimalisatie<\/h2>\n<p>Ik beschouw performance als een doorlopend proces, niet als <strong>Eenmalige actie<\/strong>. In CI\/CD integreer ik korte, op eBPF gebaseerde controles om regressies in een vroeg stadium op te sporen en v\u00f3\u00f3r de uitrol te stoppen. Tijdens onderhoudsvensters meet ik typische paden onder belasting, stel ik basislijnen vast en documenteer ik aanvaardbare latentiebereiken. Zo herken ik afwijkingen snel en hoef ik tijdens een incident niet te gissen, omdat er vergelijkingsgegevens zijn <strong>beschikbaar<\/strong>. Deze werkwijze draagt direct bij aan de beschikbaarheid, kostenbeheersing en gebruikerservaring.<\/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\/bcc-tools-leitfaden-4956.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Mini-casestudy: van symptoom naar oorzaak in 12 minuten<\/h2>\n<p>Een API-cluster meldt stijgende 99p-latenties bij een ongewijzigd RPS. Ik maak een incident-snapshot: <strong>tcpconnect<\/strong> vertoont geen afwijkingen bij het tot stand brengen van de verbinding, <strong>tcpretrans<\/strong> blijft laag \u2013 het netwerk is dat in ieder geval niet. <strong>runqlat<\/strong> meldt korte, maar frequente wachttijden; <strong>profielen<\/strong> toont hotspots in een JSON-serialisatie. Tegelijkertijd houd ik in de gaten met <strong>cachestat<\/strong> een daling van de cache-hitratio's tijdens pieken. De correlatie wijst erop dat er sprake is van veel kleine payloads die synchroon worden geserialiseerd en onmiddellijk worden weggeschreven.<\/p>\n<p>Ik verifieer met <strong>ext4 is trager<\/strong>, dat fsyncs van meerdere milliseconden op hetzelfde volume voor het API-proces laat zien; <strong>biolatency<\/strong> bevestigt sporadische pieken in de wachtrij op het betreffende apparaat. Oplossing: het batchen van schrijfbewerkingen, een grotere buffer en asynchroon leegmaken op minder gevoelige punten. Na de uitrol dalen de 99p-latenties met 35 %, herstelt de cache-hitrate zich, en <strong>runqlat<\/strong> laat opnieuw smalle verdelingen zien.<\/p>\n\n<h2>Samenvatting voor de praktijk<\/h2>\n<p>Met <strong>bcc<\/strong> Met tools en eBPF krijg ik in korte tijd inzicht in de CPU, I\/O en het netwerk, zonder applicaties te hoeven aanpassen. De checklist met execsnoop, opensnoop, ext4slower, biolatency, biosnoop, cachestat, tcpconnect, tcpaccept, tcpretrans en runqlat vormt een logisch startpunt. Daarnaast gebruik ik profile om hotspots zichtbaar te maken en codepaden te optimaliseren. Dankzij duidelijke beleidsregels, logboekregistratie en limieten blijft het gebruik in de kernel <strong>veilig<\/strong> en inzichtelijk. Wie deze methode consequent toepast, lost prestatieproblemen sneller op, plant capaciteiten beter en verlaagt de kosten per aanvraag.<\/p>","protected":false},"excerpt":{"rendered":"<p>Ontdek hoe je met bcc tools en eBPF de prestaties van Linux op professionele wijze kunt analyseren en optimaliseren. Deze handleiding biedt praktische tips voor prestatie-engineering, met de nadruk op het trefwoord bcc tools.<\/p>","protected":false},"author":1,"featured_media":20675,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[922],"tags":[],"class_list":["post-20682","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technologie"],"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":"125","_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":"bcc tools","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":"20675","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20682","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=20682"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20682\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/20675"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=20682"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=20682"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=20682"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}