[m-o11y]

This is great news.

At the company I work at, OpsVerse, we offer a single-click, packaged, pre-configured OSS-driven observability stack [1] that makes heavy use of Grafana (UI + Loki) as well as Pyroscope so it's great to see them take the route of merging projects rather than building a whole new project. Continuous application profiling is such a game-changer and as eBPF becomes more popular, I'm sure tools like pyroscope will become bread and butter for devs.

As an addon, we recently published a blog on how we ended us dogfooding pyroscope to debug a pesky memory leak [2].

---

[1]: https://opsverse.io/observenow-observability/

[2]: https://opsverse.io/2023/02/09/pyroscope-to-the-rescue-debug...

[hu3]

Interesting!

What's the performance impact of continuous profiling in production for Node.js?

[m-o11y]

We've heard of 2-4% performance hit in terms of performance using pyroscope on Node, but in practice, we've seen ~1% hit in terms of perf (Though we're not running high-performance systems where we're trying to eke out every bit of perf from each pod, so YMMV)

[petethepig]

Dmitry here (Pyroscope cofounder)

This sounds about right.

My favorite little anecdote that I like to tell is that the first thing people often see when they add Pyroscope to their apps is that it takes way less CPU than other signals like tracing or logging. It's pretty common to see logging taking 5-10% of overall CPU utilization.

The other 90% is usually spent doing serialization / deserialization (half-joking).