Skip to main content

FAQ

Frequently asked questions. If anything is unclear or not covered in the documentation, don't hesitate to open an issue.

What languages are supported?​

Infrastructure-wide always-on automatic profiling with Parca Agent currently supports languages like C, C++, Rust, Go (with extended support for Go), Ruby, Node.js, Python, Java, Rust, JVM, .NET, Perl, and PHP and many more. The list is continuously growing. For more details, please refer to the Language Support page.

Parca itself supports any pprof formatted profile. Any library or implementation that outputs valid pprof profiles is supported by Parca. More details about pprof client libraries for various languages can be found here.

What overhead does always-on profiling have?​

Parca Agent has been observed to have an overhead of less than 1% in CPU and less than 200 Mb memory (this can depend on the number of targets actively being profiled). More elaborate and reproducible reports coming soon.

Since Parca Agent has to run as root for eBPF, what are the security considerations?​

  • The profiler source code is open source, so anyone can inspect the code that would be running as root on their servers.
  • It is written in Go, a memory-safe language.
  • Binaries and container images are fully reproducible, so users can ensure that the artifacts they are running are exactly the same as the those that are being distributed.

Read the docs on more in-depth explanations on Parca Agent Security.

Does Parca have our binaries or code?​

No. Profiling data is made up of statistics representing. For example, how much time the CPU has spent in a particular function, but the function metadata is decoupled from the actual executable and source code. Parca only ever gets to see the measured statistics and function name metadata.

Read the docs on symbolization to understand further why.

What happened to the Merge button?​

Until Parca v0.16.0 Parca had a merge button next to the Search and Compare button.

With version v0.16.0 the merge button is gone. Profiles that can be merged will automatically merge across the selected time range. Some profiles (goroutines, memory heap, and allocations) never made sense to be merged. Therefore, the functionality to merge these profiles is gone and you need to select individual profiles from the metrics graph.

What are the 0x7f79e7a26b10 memory addresses I see in profiles?​

This means the Parca server is failed to symbolize the profile that it received. For the generic profiles, the function metadata is decoupled from the actual executable and source code. In this particular situation, Parca has the profile but not the metadata.

This problem could happen because of several reasons:

  • If the location doesn't have any mapping, the process might have disappeared before the profiling interval was over. As a result, we didn't even get the chance to read the /proc/PID/maps file.

  • If there are Go runtime stack entries, such as runtime.mstart or runtime.sysmon, then this is the Linux Kernel walking the Go runtime stack too far.

  • If your executable or the libraries that your executable uses do not include the debug information.

To solve the last one, either you can provide the debug information in your environment (by recompiling the binary with debug info), or you can upload additional object files that include the debug information for your executables to Parca server. We have created an auxiliary tool called parca-debug-info to ease-up the process.

  • If the asynchronous symbolization hasn't worked yet. This could happen freshly ingested profiles.

Please read the docs on symbolization to understand how it works.

What happened to Conprof?​

The Parca project is the continuation of Conprof. Parca already includes almost all the features and builds more on top of Conprof. Conprof, as of we open-sourced Parca, is archived, and there won't be any future development on it. And all the relevant issues are migrated to Parca. You can still find Conprof under https://github.com/parca-dev/conprof-archived.

The migration from Conprof to Parca should be painless for an end-user. Especially considering they both share the exact same discovery mechanism. If you have a dependency on the API as a developer, unfortunately, they are not 100% compatible. Please let us know if you need any help in case of a migration.

How can I verify the container image signature with cosign?​

We use keyless signing, so the verification is also keyless.

Server

cosign verify \
  --certificate-identity=https://github.com/parca-dev/parca/.github/workflows/release.yml@refs/tags/v0.22.0 \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  ghcr.io/parca-dev/parca:v0.22.0

Agent

cosign verify \
  --certificate-identity=https://github.com/parca-dev/parca-agent/.github/workflows/release.yml@refs/tags/v0.35.0 \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  ghcr.io/parca-dev/parca-agent:v0.35.0