Understanding Garnet’s performance impact and optimization.

​
Overview

Garnet uses eBPF (Extended Berkeley Packet Filter) for monitoring, which provides near-zero overhead compared to traditional monitoring solutions.

​
Resource Usage

​
Typical Overhead

ResourceImpactNotes
CPU<1%Per-core overhead during normal operation
Memory50-100MBBase agent memory footprint
Network<10KB/sEvent telemetry to Garnet Platform
Disk I/ONegligibleOnly for local event buffering

​
Compared to Alternatives

Solution TypeCPU OverheadMemory Overhead
Garnet (eBPF)<1%50-100MB
Traditional agents5-15%200-500MB
Network tapsN/ARequires separate infrastructure
Application instrumentation10-30%Varies

​
Benchmark Results

​
GitHub Actions

Tested on ubuntu-latest runners: 
# Without Garnet
Build time: 2m 15s
CPU usage: 45%

# With Garnet
Build time: 2m 17s (+2s / +1.5%)
CPU usage: 46%
Result: Negligible impact on CI/CD pipelines

​
Kubernetes Workloads

Tested on 3-node cluster (4 CPU, 8GB RAM each):
MetricWithout GarnetWith GarnetDifference
Request latency (p95)45ms46ms+2.2%
Throughput (req/s)1,2501,235-1.2%
Pod memory512MB522MB+2.0%
Node CPU usage35%35.5%+1.4%
Result: Minimal production impact

​
Docker Containers

Single container benchmark (alpine-based): 
# Container stats without Garnet
CPU: 0.5% | Memory: 25MB

# Container stats with Garnet agent
CPU: 0.6% | Memory: 75MB
Result: Low overhead for containerized workloads

​
Performance Factors

​
What Affects Performance

High network/process activity increases CPU usage
  • More events = more eBPF processing
  • Typically still <2% CPU even under heavy load
  • Events are batched and sent asynchronously
Optimization: Use network policies to filter noisy destinations
More concurrent processes = more monitoring points
  • Each process requires eBPF attachment
  • Memory scales with process count
  • Agent automatically handles cleanup
Optimization: No action needed - handled automatically
Newer kernels = better eBPF performance
  • Kernel 5.15+: Optimized eBPF JIT
  • Kernel 5.10-5.14: Good performance
  • Kernel <5.10: Not supported
Recommendation: Use kernel 5.15 or later
More policies = slightly more filtering overhead
  • Each policy adds ~0.01% CPU
  • Policies are evaluated in-kernel (very fast)
  • Compiled to eBPF bytecode
Impact: Negligible (even with 100+ policies)

​
Optimization Tips

1

Use Scoped Policies

Apply network policies at the most specific scope:
# Good: workflow-specific
scope: workflow

# Okay: repo-wide
scope: repo

# Avoid unless necessary: global
scope: global
2

Filter Noisy Destinations

Reduce event volume by allowing known-good destinations:
# Example: allow npm registry
garnet network-policy create \
  --action allow \
  --destination "registry.npmjs.org" \
  --scope workflow
3

Right-Size Agent Resources

Adjust resource limits in Kubernetes:
resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi
4

Monitor Agent Health

Check agent metrics in dashboard:
  • Event processing rate
  • Memory usage trends
  • Network throughput
  • CPU utilization

​
Scaling Considerations

​
GitHub Actions

  • Impact: Per-runner overhead
  • Scaling: Automatically scales with workflow concurrency
  • Cost: No additional cost beyond Garnet subscription

​
Kubernetes

  • DaemonSet deployment: One agent per node
  • Small clusters (1-10 nodes): <0.5% cluster CPU
  • Large clusters (100+ nodes): <0.3% cluster CPU
  • Auto-scaling: Agent memory is bounded and predictable

​
Docker / Standalone

  • Single agent per host
  • Shared across all containers
  • Resource limits configurable via Docker run flags

​
Performance Monitoring

​
Agent Metrics

Available in Garnet Dashboard:

Event Rate

Events processed per second

Memory Usage

Agent memory consumption

CPU Usage

Percentage CPU utilization

Network Throughput

Data sent to platform

​
Performance Alerts

Configure alerts for:
  • Agent CPU usage >5%
  • Agent memory usage >200MB
  • Event processing lag >10s
  • Agent disconnections

​
Troubleshooting Performance Issues

​
High CPU Usage (>2%)

# View events per second
kubectl logs -n garnet-system jibril-xxx | grep "events/sec"

# Expected: &lt;100 events/sec
# High: &gt;1000 events/sec
Solution: Add network policies to filter noisy destinations
# Check kernel version
uname -r

# Should be: 5.15 or higher
Solution: Upgrade kernel if possible
# Check if agent is CPU throttled
kubectl describe pod -n garnet-system jibril-xxx

# Look for: "cpu throttling"
Solution: Increase CPU limits

​
High Memory Usage (>200MB)

# Count monitored processes
ps aux | wc -l
Expected: Memory scales ~1MB per 100 processesSolution: Normal behavior for high-process-count systems
# Check for network issues causing buffer buildup
kubectl logs -n garnet-system jibril-xxx | grep "buffer"
Solution: Check network connectivity to Garnet Platform

​
Event Processing Lag

# Test connectivity to Garnet Platform
curl -w "@curl-format.txt" -o /dev/null -s https://api.garnet.ai/health
Solution: Check network policies or firewall rules
# Check agent logs for auth errors
kubectl logs -n garnet-system jibril-xxx | grep -i "auth"
Solution: Verify API token is valid and not expired

​
Production Best Practices

For production Kubernetes deployments:
# DaemonSet resource limits
resources:
  requests:
    cpu: 100m      # Start conservative
    memory: 128Mi
  limits:
    cpu: 500m      # Allow bursts
    memory: 256Mi  # Bounded memory

# Environment variables
env:
  - name: GARNET_API_TOKEN
    valueFrom:
      secretKeyRef:
        name: garnet-token
        key: token
  - name: GARNET_EVENT_BATCH_SIZE
    value: "100"  # Optimize for your event rate
  - name: GARNET_EVENT_BATCH_TIMEOUT
    value: "5s"   # Balance latency vs throughput

​
FAQs

No. eBPF monitoring happens outside the application’s execution path. There’s no inline interception of requests.
Your applications continue running normally. eBPF programs are safely removed by the kernel. The agent auto-restarts via supervisor (Kubernetes/systemd).
Yes. Garnet is designed for production use with <1% overhead. Used by companies processing millions of requests per day.
  1. Measure baseline metrics (CPU, memory, latency)
  2. Deploy Garnet agent
  3. Run normal workload for 24 hours
  4. Compare metrics
We’re happy to help with benchmarking. Contact us.

​
Next Steps

Architecture

Understand how Garnet works

Troubleshooting

Solve common issues