Parca

Last reviewed Sep 13, 2026 · 834 words

Continuous profiling answers the question metrics and logs cannot: which function, in which binary, is burning the CPU right now, and was it doing that last Tuesday too. Parca does it for every process on a machine with a single eBPF agent, no instrumentation, and about 1 percent CPU overhead, on 256 MB of RAM for the server. The requirement that stops most homelab installs is the kernel: the agent needs a recent Linux kernel with BTF type information, which stock kernels on distributions from the last few years provide and older enterprise LTS kernels do not. Check ls /sys/kernel/btf/vmlinux before anything else; if that file is missing, upgrade the kernel or pick a different tool.

Two binaries, one of them privileged

Parca is the server: it receives profiles, stores them in a columnar in-memory database, and serves the UI and API on port 7070. Parca Agent runs on every host you want profiled, as a privileged container or a systemd unit with CAP_SYS_ADMIN, because loading eBPF programs and reading kernel stacks requires it. On Kubernetes that is a DaemonSet with the agent pointed at the server address; on a bare Docker host it is:

docker run -d --name parca -p 7070:7070 ghcr.io/parca-dev/parca:latest
docker run -d --name parca-agent --privileged --pid=host \
  -v /sys:/sys -v /proc:/proc -v /run:/run \
  ghcr.io/parca-dev/parca-agent:latest \
  --remote-store-address=parca:7070 --remote-store-insecure

The agent samples stacks across all processes at a fixed frequency, symbolises what it can locally, and ships the rest with debug-info uploads so the server resolves symbols. Go, Rust, C and C++ binaries with symbols come out readable. JIT and interpreted languages (Python, Ruby, JVM, Node) are supported through language-specific unwinders that have improved a lot; expect most frames to resolve, not all.

Flame graph diffs are the feature worth the install

Any profiler shows you a flame graph. Parca's UI lets you select a time window, see the merged profile for a process or a whole node, and then compare two windows: before and after a deploy, this hour against yesterday's, one pod against another. The diff view colours the frames that grew red and those that shrank blue. That is how you find that the 15 percent CPU increase after Tuesday's release is a JSON serialiser being called in a loop, without adding a single log line. Query syntax is Prometheus-like label matching on process name, container, namespace and node, so the mental model transfers if you already run Prometheus.

The server can also scrape pprof endpoints from applications that expose them, which is how you get heap and goroutine profiles from Go services. Everything the eBPF agent produces on its own is CPU; if memory profiling of arbitrary processes is the requirement, Parca does not deliver it today.

Storage is in memory unless you say otherwise

The default server keeps profiles in RAM with a bounded retention and forgets them on restart. That is workable for "what is happening this week" on 2 or 3 hosts and inadequate for anything you want to look back on. Parca can persist to an object store (S3-compatible, so MinIO on your own box qualifies) for durable history; set that up before the first time you wish you had it. Plan RAM by sample volume rather than by host count: a busy 32-core node produces more stack samples than 5 idle ones, and the 256 MB floor will not hold for that node's server.

When Pyroscope is the safer pick

Grafana Pyroscope is the bigger project in this space, has a push SDK path for languages where eBPF unwinding is weaker, stores to object storage by default, and lives inside the Grafana UI you may already have open. If your team runs Grafana and Loki, Pyroscope is the lower-friction choice and its eBPF agent covers the same zero-instrumentation case. Parca wins when you want a standalone tool with a smaller footprint, a cleaner focus on whole-system CPU, and no ties to the Grafana ecosystem; it is also the project that pushed most of the eBPF profiling techniques the others now use. For a homelab curious about profiling, Parca is the quicker afternoon; for a company standardising on one observability stack, Pyroscope is easier to justify.

What I'd do

Confirm BTF on every host, deploy the agent as a DaemonSet or a privileged container, run the server with S3-compatible persistence from day one, and leave it alone for a week. Then open the diff view after your next deploy. If the profiles change a decision, keep it; if nobody looks at them after a month, remove the agent, because a privileged eBPF process is not something to run for decoration. On a fleet already inside Grafana, use Pyroscope instead and get the same insight in a familiar UI.