The first serious technical question production engineering teams raise is not detection accuracy. It is: "What does this do to our latency?" That is a fair concern. We measured it across our early-access deployments. This post shares the actual figures from four representative workload types, plus the methodology and the variables with the greatest effect.
In brief: across three of the four workload types, total CPU overhead stayed below 1.5%, while p99 latency impact was not measurable above noise. The fourth, high-frequency microservices, had more noticeable overhead before we lowered kprobe density. We explain what caused it and how we addressed it.
Method
We collected measurements from early-access deployments in four production-grade environments during Q4 2025. Each ran Oligo on Linux kernel 5.15+ with kprobe and tracepoint programs attached. We measured:
- CPU overhead: Additional CPU time consumed by the eBPF programs and the Oligo userspace agent, expressed as a percentage of total CPU capacity per core.
- Latency impact: p50 and p99 request latency measured by the application's existing metrics, comparing seven-day windows before and after Oligo deployment.
- Memory overhead: Additional resident memory used by the Oligo DaemonSet pod and by eBPF map memory in kernel space.
These results come from real production environments rather than synthetic benchmarks. They capture each workload's actual syscall rates and program complexity. We do not associate them with named customers. The figures come from Oligo's early-access program and illustrate the range you may see, not guaranteed results for your configuration.
Workload 1: I/O-Bound Web API
A Python Django application handled REST API traffic at approximately 800 requests per second, backed by PostgreSQL. Its syscall rate was moderate, with network I/O dominant and some file I/O for static assets.
| Metric | Value |
|---|---|
| Additional CPU (per core) | 0.6% |
| p50 latency delta | <1ms (within noise floor) |
| p99 latency delta | ~2ms |
| eBPF map memory (kernel) | 18 MB |
| Agent pod memory (userspace) | 64 MB |
The kprobe programs attached to execve, connect, and mmap entry points imposed a small fixed cost per syscall. At 800 req/s, relevant syscalls occurred infrequently enough that eBPF execution time was negligible beside the application's network I/O time. This workload represents the best-case scenario for eBPF security instrumentation.
Workload 2: CPU-Bound Batch Processing
A Java service ran data transformation jobs. Application logic drove high CPU use, while I/O stayed low. It processed one batch per minute, with intensive computation during each run.
| Metric | Value |
|---|---|
| Additional CPU (per core) | 0.9% |
| Batch job duration delta | +0.4% (3 seconds on a 750s job) |
| eBPF map memory (kernel) | 22 MB |
| Agent pod memory (userspace) | 71 MB |
CPU-bound workloads respond to eBPF overhead differently than I/O-bound workloads. The programs add little per-syscall time, but they compete for the same core CPU capacity as the application. The 0.9% increase produced a small yet measurable rise in batch duration. Most security teams consider that acceptable. For batch jobs with very tight SLA requirements, narrowing kprobe scope can lower overhead further.
Workload 3: High-Frequency Microservices
A Go-based service mesh with 12 microservices used gRPC and processed approximately 15,000 requests per second per node, with many short-lived goroutines. It had the highest relevant syscall rate of the four types tested.
| Metric | Value |
|---|---|
| Additional CPU (initial config) | 4.2% |
| Additional CPU (after kprobe tuning) | 1.4% |
| p99 latency delta (initial) | ~8ms |
| p99 latency delta (after tuning) | ~2ms |
| eBPF map memory (kernel) | 41 MB |
| Agent pod memory (userspace) | 89 MB |
This was the workload with meaningful overhead under the default configuration. The cause was kprobe density: 15,000 req/s and many short-lived goroutines produced frequent socket creation and connection events. Every kprobe execution adds a small time cost, and at sufficiently high syscall rates those costs accumulate.
We lowered overhead through sampling, since high event rates do not require full processing for every connect() event; behavioral anomaly detection needs a representative sample. We also moved filtering logic from userspace into the eBPF program, preventing events that failed the baseline filter from reaching the ring buffer, and narrowed uprobe attachments for this workload. After tuning, p99 latency impact returned to the 2ms range acceptable to the team.
Workload 4: Database-Adjacent Middleware
A Node.js service handled data transformation and caching between upstream services and a database cluster. It processed 2,200 req/s, used persistent connections with high socket reuse, and followed predictable behavior patterns.
| Metric | Value |
|---|---|
| Additional CPU (per core) | 0.7% |
| p50 latency delta | <1ms (within noise floor) |
| p99 latency delta | <1ms (within noise floor) |
| eBPF map memory (kernel) | 15 MB |
| Agent pod memory (userspace) | 58 MB |
This workload had the lowest overhead, largely because high socket reuse creates fewer connect() and accept() syscalls per request than workloads that frequently open new connections. The stable connection pool kept kprobe event flow very low relative to request volume. Predictable behavior also produced a tight behavioral baseline and efficient filtering.
Key Variables Behind Overhead
The measurements identify these main drivers of eBPF security instrumentation overhead:
Syscall rate for instrumented calls: A kprobe execution adds a small per-syscall cost, roughly 100-300 nanoseconds for a simple program without complex map lookups. At 50,000 connect() calls per second, those costs accumulate. The key question is not "how much does one kprobe cost?" but "how many times per second will this kprobe fire?"
BPF program complexity: A kprobe program performing a hash map lookup and writing to a ring buffer is faster than one performing multiple map lookups, string comparisons, and conditional branches. Keeping each program's in-kernel portion simple and moving analysis to userspace reduces per-event overhead.
Ring buffer backpressure: When the userspace agent cannot consume events quickly enough, the ring buffer fills and events are dropped. This does not increase application latency because the eBPF program writes to the ring buffer and returns immediately regardless of consumption rate, but it reduces detection coverage. Agent sizing is important for high-volume deployments.
Kernel version: eBPF program performance improved significantly between Linux 4.14 and 5.15. For our use case, the ring buffer, available since 5.8, is more efficient than the older perf buffer. Running a current kernel materially lowers overhead compared with older versions.
What the Measurements Mean for Deployment
For most production workloads, including web APIs, batch jobs, and database-adjacent services, overhead is typically under 1.5% additional CPU and under 2ms in p99 latency, a range teams find acceptable. Very high-frequency services may need kprobe density and sampling-rate tuning to stay there.
These are not universal figures. Syscall patterns vary between workloads. Before deploying instrumentation in production, measure your specific workload in a staging environment under realistic load, using the configuration intended for production. These results begin the discussion; they do not guarantee what your environment will experience.