Continuous Profiler: find the function that uses the CPU and memory in production

In Saudi banks, telcos and government entities, the hardest performance problems appear only in production: a service that uses more CPU after a release, a portal that slows at month-end payroll, a container restarted every few days because its memory keeps growing. Test environments rarely show them, and restarting a busy service to investigate is rarely allowed.

Code profiling in production therefore has to meet four conditions. It runs all the time, so last night's incident is already recorded. It is light enough to leave on. It shows the exact function and line, not only the service. And it compares one period, version or host with another, because the question is usually "what changed".

One library, one setting. Datadog Continuous Profiler is part of the Datadog tracing library for each language. In Java, for example, the same dd-java-agent.jar that sends APM traces collects profiles once -Ddd.profiling.enabled=true or DD_PROFILING_ENABLED=true is set; in PHP the datadog-setup.php installer adds it with --enable-profiling. The setting is read at start-up, so the service is restarted once, in a normal deployment. From then on profiles are collected continuously, with no further restarts. Datadog states that it is built to run in production with minimal impact on CPU and memory.

RelatedAPM set-up page for Java, .NET, PHP and Node.js

Datadog states that application processes running both APM distributed tracing and Continuous Profiler are linked automatically. An engineer opens a slow span, then its Profiles tab, and sees which methods ran on each thread during that request. "Open in Profiling" shows the same data as a flame graph, narrowed to the span and its children. Our distributed tracing page covers following a request across services; the profiler is the next step, inside one service.

Relateddistributed tracing page

A memory leak usually shows as container memory that climbs until a restart. Datadog provides a guided investigation for this on the APM service page, under a Memory Leaks tab: it narrows the data, names the integrations or upgrades needed, and explains how that runtime manages memory.

• CPU cost after a release. Compare the new version with the previous one on the same endpoint and see the function that changed.
• Peak days. Month-end payroll or a Ramadan campaign: wall time and lock profiles show where requests wait as traffic rises.
• Garbage collection pressure. Allocation profiles show the code that creates short-lived objects; in .NET Datadog also records garbage collector CPU use.
• Exceptions in a loop. The exception profile shows code that throws and catches errors silently, costing CPU without showing in error rates.

The profiler explains what your own code does inside a process. It does not show a slow query plan: query plans and database wait time belong to Database Monitoring. It does not show what a user's browser experiences, and it does not replace load testing. For Java, Datadog states that serverless platforms are not supported; we say so in the plan, before licences are bought.

Relatedquery plans and database wait time

Profiles carry function, file and thread names and your tags, and link to traces that can hold URLs and SQL. As of November 2026 Datadog lists no site in the Middle East, so profiling data is stored outside the Kingdom. Interkey agrees with your security team which tags are allowed before profiling starts. Our Datadog data residency guide covers the wider question. Support comes from Interkey's engineers in Riyadh, in Arabic and English.

RelatedDatadog data residency guide