Zero-instrumentation eBPF profiler that finds blocking code in Tokio async runtimes by measuring OS scheduling latency.
hud is an eBPF-powered profiler that detects blocking operations in Tokio async runtimes by measuring OS scheduling latency. It helps developers identify performance bottlenecks like CPU-heavy tasks or synchronous I/O that degrade throughput in cooperative scheduling environments. Unlike instrumentation-based tools, hud attaches directly to running processes without requiring code changes.
Rust developers working with Tokio async runtimes who need to diagnose performance issues in production or staging environments without modifying their codebase. It's particularly useful for DevOps engineers and SREs performing quick triage during load testing or incident response.
Developers choose hud for its zero-instrumentation approach, allowing immediate profiling of live processes without rebuilds or code changes. It provides a quick way to confirm blocking issues before investing in more precise but invasive instrumentation tools like tokio-console.
Find code blocking your Tokio workers. eBPF-powered, no instrumentation.
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Attaches to any running Tokio process without code changes or rebuilds, ideal for quick triage in staging or production environments, as highlighted in the README's philosophy.
Uses Linux kernel eBPF to monitor OS-level scheduling latency, providing system-wide insights without modifying the application, enabling detection of blocking operations like CPU-heavy code or sync I/O.
Supports profiling by process name or PID with customizable thresholds and time windows, plus headless mode for CI integration with export capabilities, making it flexible for automation.
Identifies Tokio worker threads by name or stack frames, reducing manual configuration and adapting to custom thread naming, as mentioned in the usage section.
Measures scheduling latency as a symptom of blocking, not the direct cause, which can lead to false positives from system CPU pressure or misleading stack traces from victim tasks, as admitted in the limitations.
Requires debug symbols in the target binary, which adds 10-20% to binary size and slight runtime overhead, making it impractical for some production deployments without temporary swaps.
Only works on Linux 5.8+ with root privileges, excluding macOS, Windows, and environments without elevated access, limiting cross-platform or secure use cases.
Specifically designed for Tokio 1.x runtimes with worker detection heuristics, not compatible with other async runtimes or older Tokio versions, as noted in the limitations.