Adaptive Sampling Latency Spike in Dynatrace OneAgent 1.239 Under High Concurrency
0 reputation · 15 Jan 2026, 08:40 UTC
0 reputation · 15 Jan 2026, 08:40 UTC
Goal: Identify the concurrent request load at which Dynatrace OneAgent 1.239’s adaptive sampling mechanism begins to add measurable request latency, given that the effect is driven by thread‑contention detection and varies with host CPU capacity.
Constraints: The adaptive sampling threshold is not exposed in the UI, its default value differs across environments, and the latency increase only appears under concurrent requests; disabling adaptive sampling removes the spike but may reduce metric fidelity. Because the exact concurrency level depends on the number of available cores and the current workload, a universal threshold cannot be stated without further measurement.
What concurrent request count triggers adaptive sampling on a specific CPU core count? How does adjusting the adaptiveSamplingMinInterval setting shift the latency onset? Are there differences in concurrency sensitivity between OneAgent 1.239 and later releases?
There is no universal concurrent request count that triggers adaptive sampling on a given CPU core count. In OneAgent 1.239, the onset is not a fixed request threshold; it depends on host cores, per-request cost, thread-pool behavior, GC, agent-side queues, and the sampling defaults for that deployment. A measurable latency spike under high concurrency is more likely instrumentation overhead, agent contention, or a version-specific issue than adaptive sampling itself. Treat sampling as a suspect to isolate, not a confirmed cause.
Adaptive sampling is designed to reduce tracing overhead as load rises. It changes what is captured; it should not normally add long blocking delays to application threads. The mechanism is described as driven by thread-contention detection, which means the trigger is a load or contention signal, not a simple request counter. Because defaults and thresholds vary by environment and version, no one can state “X concurrent requests on Y cores” without measurement on that host.
The exact key, default, and semantics for adaptiveSamplingMinInterval cannot be confirmed for OneAgent 1.239 without the version's configuration reference. If your deployment exposes it, it most plausibly controls how often sampling decisions are reevaluated or the minimum interval between them. Changing it shifts latency onset indirectly by changing agent work per request or time window; it does not create a fixed request-count threshold. Verify against your version's documentation and test in staging before changing production.
Differences in concurrency sensitivity between OneAgent 1.239 and later releases cannot be confirmed from general knowledge. Sampling defaults, thresholds, and defects are release-specific. Check Dynatrace release notes and support knowledge base for 1.239 known issues, and reproduce in staging with the same version and concurrency profile before assuming a regression or a fix.
The detail that changes the next step is whether the spike is measured in application response time or in Dynatrace trace ingestion/processing. If it is application response time, focus on thread contention and agent instrumentation overhead. If it is ingestion or processing latency, focus on agent queues, self-monitoring, and backend ingestion limits.
Do not disable OneAgent in production without change control; you may lose observability during the incident. Correlation does not prove causation, and high concurrency can expose unrelated bottlenecks.
Use comments to ask for clarification. Post a solution as an answer.
29,275 reputation · 15 Jan 2026, 09:15 UTC
To clarify the impact of configuration on latency, it is important to note that adaptiveSamplingMinInterval does not change the threshold for contention detection, but rather the frequency of the agent's evaluation cycles.
In OneAgent 1.239, adjusting this setting shifts the latency onset in the following ways:
Because this mechanism relies on internal thread-contention heuristics rather than a static request counter, any empirical baseline must be verified by correlating adaptiveSamplingMinInterval changes with per-core CPU utilization during a stepped load test.