swift-parca supports continuous low-overhead profiling of Swift Server applications at scale, for always-on tracking of performance issues in production.
swift-parca is a fully packaged solution that extends Parca, an open-source continuous profiling tool that embeds opentelemetry-ebpf-profiler for creating low overhead samples, with native support for Swift symbol demangling.
Parca consists of an agent that runs on each node that is under monitoring as well as a server that aggregates all the profiling data for analysis using familiar tools such as flamegraphs and sample overviews.
swift-parca is provided as a single, pre-configured Docker container image that bundles Parca and all necessary dependencies, to simplify profiling of Swift applications at scale.
To begin profiling your Swift application, follow these simple steps:
- Start the Parca Server
Use the provided docker-compose.yml to bring up the Parca server:
docker compose up -dThis starts the Parca server, listening on HTTP port 7070 for UI and profiling data from agents.
- Start the Parca Agent
On each server running your Swift workloads, deploy the parca-agent:
export REMOTE_STORE_ADDRESS=<PARCA_SERVER_IP>:7070
docker-compose -f docker-compose.agent.yml up -dFor further setup and usage instructions, please refer to the Parca Documentation.
Parca agent samples 19 times per second per core, only the stack addresses are aggregated in eBPF maps; the rest of the processing is sending them and binaries to the server, where demangling/symbolicatition happens on demand when a trace is viewed. In practice this results in neglible overhead on the profiled application, that can be sub 1%.
Parca normally uses a Go demangler which lacks Swift symbol demangling.
This project addresses this limitation by configuring Parca to delegate address-to-line lookups and symbol demangling to a custom swift-addr2line embedded tool. This tool leverages the native Swift runtime function for demangling, ensuring accurate and human-readable stack traces, while relying on a Rust-based gimli addr2line (or to llvm-addr2line) for actual address lookup.
This direct access of the native Swift runtime function is needed until SE-262 is formally integrated into the standard library.
If you want to use llvm-addr2line instead of the gimli-rs/addr2line, uncomment the line containing apt-get install -y llvm-19 in the Dockerfile.
This installs the LLVM tools, making the binary available at /usr/bin/llvm-addr2line-19.
Then you need to update the docker-compose.yml environment:
environment:
- ADDR2LINE_PATH=/usr/bin/llvm-addr2line-19The container is packaged for Linux x86_64 and ARM64. It is possible to run entirely under a Linux VM (with kernel 5.4+) under Apple sillicon.