Bringing .NET application performance analysis to Linux

Microscopic analysis photo

Both the Windows and Linux ecosystems have a swath of battle-hardened performance analysis and investigation tools. But up until recently, developers and platform engineers could use none of these tools with .NET applications on Linux.

Getting them to work with .NET involved collaboration across many open source communities. The .NET team at Microsoft and the LTTng community worked together to bring .NET application performance analysis to Linux. Since one of this project's goals was to avoid reinventing the wheel—and to allow existing workflows to be used for .NET applications on Linux—the .NET team chose to enable usage of popular Linux tools such as LTTng and perf to enable performance analysis of .NET core applications.

membarrier system call performance and the future of Userspace RCU on Linux


Membarrier photo

A few months ago on the lttng-dev mailing list, Milian Wolff reported that his test application was seeing noticeable startup delays because it was linked against liblttng-ust. He didn't start a tracing session and his test program didn't call any code in liblttng-ust. In fact, the test program contained fewer lines of code than a standard Hello, World! application:

int main()
	return 0;

Preventing trace event record loss with LTTng-UST's blocking mode


blockade photo

If you've ever suffered from lost trace event records when using LTTng-UST then you might be interested to know that LTTng 2.10 includes a new feature to prevent that from happening: blocking mode support for channels.

This long-awaited feature makes it possible for LTTng-UST to wait until space becomes available in the trace buffers instead of losing existing event records when new ones arrive.

Create virtual LTTng environments with vlttng


In my day to day job at EfficiOS, I often have to manually test different versions and configurations of LTTng. The typical way to test LTTng 2.7 if LTTng 2.8 is installed, for example, is, for each of the three LTTng projects (LTTng-tools, LTTng-UST, and LTTng-modules):

  1. Uninstall the current version (2.8).
  2. Check out version 2.7.
  3. Configure, build, and install version 2.7.

This whole manual process becomes painful over time. I'm not even mentioning the situations where I also need to test different versions of the tools' dependencies, like Glib and Libxml2. The same laborious process applies to Babeltrace.

In an ideal world, I would have multiple environments containing different versions and configurations of the tools and dependencies which form the LTTng ecosystem. This is totally possible with the various environment variables and configure flags (--prefix, --with-lttng-ust-prefix, and the rest) of the projects. And this is exactly what vlttng exploits to achieve this. vlttng is a project I've been working on in my spare time.

In this article I explain what vlttng is exactly, after which I show a concrete example.