Study guide
6.2 Method Hotspots, CPU Profiling & Memory Allocation Thread Analysis
Dynatrace Certified Associate Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Overview, Deployment Models & Architecture
1.1 Dynatrace Platform Capabilities, Web UI Navigation & the Dynatrace Hub 1.2 SaaS vs. Dynatrace Managed Architecture & Security 1.3 Core Telemetry Components: OneAgent, ActiveGate & Grail Lakehouse 1.4 Licensing Models: Dynatrace Platform Subscription (DPS) & Davis Data Units (DDUs)
2 Chapter 2: ActiveGate Architecture & Network Topologies
2.1 ActiveGate Types: Environment vs. Cluster ActiveGates 2.2 ActiveGate Capabilities: Proxying, Private Synthetic, Cloud Integrations & Extensions 2.3 Network Zones, Multi-DC Routing & Firewall Traversal
3 Chapter 3: OneAgent Deployment, Configuration & Management
3.1 OneAgent Architecture, Components & Automatic Injection 3.2 Host Installation on Linux, Windows & Containerized Hosts 3.3 Cloud-Native Deployment: Dynatrace Operator on Kubernetes & OpenShift 3.4 Kubernetes Observability: Clusters, Nodes, Namespaces, Workloads & Events
4 Chapter 4: Monitoring Modes, Process Groups & Infrastructure Observability
4.1 Monitoring Modes: Full-Stack vs. Infrastructure-Only vs. Discovery 4.2 Process Groups, Process Instances & Custom Process Group Detection Rules 4.3 Host Groups, Host Naming Rules & Environmental Metadata Extraction 4.4 Infrastructure & Operations: Host Health, Disk, Network & Availability Analysis 4.5 Database Observability: The Databases App, Connection Pools & Storage Latency
5 Chapter 5: Smartscape Topology & Service Flow
5.1 The 5-Layer Smartscape Topology: Datacenter to Application 5.2 Service Detection: Web Services, Background Tasks & Custom Services 5.3 Service Flow, Backtrace Analysis & Horizontal/Vertical Dependency Mapping
6 Chapter 6: PurePath Distributed Tracing & Code-Level Diagnostics
6.1 PurePath Architecture, Distributed Tracing & Request Context Propagation 6.2 Method Hotspots, CPU Profiling & Memory Allocation Thread Analysis 6.3 Database Service Diagnostics, Slow Queries & Exception Analysis
7 Chapter 7: Davis AI Engine, Baselining & Causation
7.1 Davis Deterministic Causation Engine vs. Pure Correlation 7.2 Automated Dynamic Baselining, Percentiles & Traffic Seasonality 7.3 Event Ingestion, Event Types & Event Hierarchy in Problem Evolution
8 Chapter 8: Problem Lifecycle, Root Cause Analysis & Alerting
8.1 Problem Lifecycle, Severity Categories & Root Cause Cards 8.2 Alerting Profiles, Delay Filters & Management Zone Routing 8.3 Problem Notification Integrations: Webhooks, Slack, ServiceNow & ITSM
9 Chapter 9: Digital Experience Monitoring: Synthetic Monitoring
9.1 Synthetic Monitors: HTTP, Single-Step Browser & Multi-Step Clickpaths 9.2 Private Synthetic Locations, ActiveGate Engines & Credential Vault 9.3 Outage Detection, Performance Baselining & Maintenance Suppression
10 Chapter 10: Digital Experience Monitoring: Real User Monitoring (RUM)
10.1 RUM Architecture, OneAgent Script Injection & Mobile/OpenKit Telemetry 10.2 User Actions: Load vs. XHR/Fetch Actions, Visually Complete & Speed Index 10.3 Apdex Performance Ratings, User Sessions & Session Replay Masking
11 Chapter 11: Log Management and Analytics on Grail with DQL
11.1 Log Management on Grail: Storage, Ingestion Pipelines & Log Masking 11.2 Dynatrace Query Language (DQL): Fetch, Filter, Fields & String Operations 11.3 DQL Aggregations: Summarize, MakeTimeseries, Sorting & Visualizations
12 Chapter 12: Platform Governance, OpenTelemetry & Automation
12.1 Management Zones: Scoping Observability, Dashboards & Access Control 12.2 Tagging Strategies: Automated Rule-Based Tags, Manual Tags & AWS/K8s Metadata 12.3 OpenTelemetry Ingestion, OpenPipeline & Dynatrace Workflows Automation
13 Chapter 13: Cloud Integrations & Agentless Infrastructure Ingestion
13.1 AWS, Azure & Google Cloud Integrations 13.2 VMware vSphere, Extensions & Other Agentless Ingestion Paths
14 Chapter 14: Business Analytics & Business Events
14.1 Business Events: Capture, Ingestion & the bizevents Grail Table 14.2 Business Analytics: Connecting Performance to Revenue, Conversion & KPIs
15 Chapter 15: Notebooks, Dashboards & Data Visualization
15.1 Notebooks: Section-Based Investigation & Shareable Analysis 15.2 Dashboards: Tiles, Variables, Segments & Continuous Monitoring 15.3 Choosing Visualizations: Data Explorer, Chart Types & Metric Selection
16 Chapter 16: Reporting, Metrics & User Behavior Analysis
16.1 Metrics on Grail: Built-in Metrics, Granularity & Retention 16.2 Dashboard Reports, Subscriptions & Exporting Data via APIs 16.3 User Behavior Analysis: Bounce Rate, Landing & Exit Pages, Conversion Goals 16.4 Session Segmentation, User Journeys & Funnel Drop-Off Analysis
17 Chapter 17: Security, Vulnerability Analytics & Application Protection
17.1 Platform Security: Data Privacy, Encryption & Access Control 17.2 Third-Party Vulnerabilities, the Davis Security Score & Security Advisor 17.3 Code-Level Vulnerabilities, Attacks & Runtime Application Protection 17.4 Security Investigator, Notifications & the Remediation Workflow
6.2 Method Hotspots, CPU Profiling & Memory Allocation Thread Analysis
Key Takeaways Explain This Topic AI
Dynatrace combines lightweight bytecode instrumentation at transaction boundaries with continuous, statistical CPU thread sampling (<1.5% overhead) for 24/7 production profiling.
Method Hotspots cleanly separate execution time into distinct performance categories: CPU time, Lock Wait time, System Suspension time, and Network/Disk I/O time.
The Top-Down call tree traces execution paths from the service entry method down to leaf methods, whereas the Bottom-Up call tree aggregates expensive leaf methods across all execution paths.
Suspension time specifically highlights execution delays caused by external runtime halts, most commonly JVM/CLR stop-the-world Garbage Collection pauses.
Built-in thread dump analysis isolates thread synchronization bottlenecks, identifying active locks, blocked worker threads, and circular deadlock conditions without requiring third-party diagnostic tooling.
Last updated: September 2026
When application response times degrade or host CPU consumption spikes, high-level infrastructure metrics (such as average CPU utilization or network throughput) are insufficient to pinpoint the underlying root cause. Engineering teams require code-level visibility into exactly which software algorithms, classes, and method signatures are consuming processor cycles or holding locks.
Dynatrace provides deep code diagnostics through Method Hotspots , Continuous CPU Profiling , Memory Allocation Analysis , and Thread State Diagnostics . Unlike traditional profilers that require reproducing issues in development environments, Dynatrace code diagnostics run continuously in production with negligible overhead.
Continuous Production Profiling vs. Traditional Profiling
Traditional application profilers (such as JProfiler, VisualVM, or dotTrace) operate by injecting instrumentation hooks into every method boundary or capturing high-frequency stack traces. In production, this approach introduces severe CPU overhead (frequently 20% to 100%), introduces thread serialization delays, and risks crashing sensitive applications. As a result, operations teams traditionally disable profilers in production, leaving them blind during intermittent performance degradations.
The Dynatrace Hybrid Profiling Model
Dynatrace solves this trade-off using a patented two-tier hybrid profiling engine :
Deterministic Bytecode Sensors (Transaction Boundaries): OneAgent injects bytecode probes strictly at key architectural boundaries: framework controllers (e.g., Spring, Express, ASP.NET), database drivers (JDBC, ADO.NET), HTTP client libraries, and message queue interfaces. These sensors record precise wall-clock execution times, payload attributes, and exceptions.
Continuous Statistical Thread Profiling (In-Method Execution): For the custom application logic executing between boundary sensors, OneAgent uses continuous, ultra-lightweight thread sampling (typically at millisecond intervals). It samples the call stacks of active worker threads to detect which methods remain on the CPU core over time.
This hybrid architecture delivers complete code-level visibility with less than 1.5% CPU overhead and zero manual configuration, enabling 24/7 continuous profiling across all monitored production processes. +-----------------------------------------------------------------------------------------+
- | TRADITIONAL PROFILING VS. DYNATRACE HYBRID |
- +-------------------------------------------------------------+---------------------------+
- | TRADITIONAL PROFILERS (JProfiler, VisualVM) | DYNATRACE HYBRID MODEL |
- +-------------------------------------------------------------+---------------------------+
- | • Extreme CPU overhead (20% - 100%+) | • Low overhead (<1.5% CPU)|
- | • Must be manually started, stopped, and managed | • Runs 24/7 continuously |
- | • Requires server restarts or debug port exposure | • Zero-restart dynamic |
- | • Disconnected from network, host, and database context | • Bound to Smartscape |
- | • Generates massive snapshot files requiring manual analysis| • Davis AI automated root |
- | | cause integration |
- +-------------------------------------------------------------+---------------------------+
- Deconstructing Execution Time in Method Hotspots
When investigating slow requests in the Dynatrace Method Hotspots view, total response time is broken down into four distinct, mutually exclusive execution time categories:
Execution Time Category Underlying Mechanism Diagnostic Meaning & Common Causes
CPU Time Thread is actively running on a physical/virtual CPU core executing computational instructions. Algorithmic inefficiencies, complex regex parsing, unoptimized JSON/XML serialization, tight loops, cryptographic hashing.
Wait Time (Sync) Thread is paused waiting for a monitor lock, mutex, database response, or external socket. Database query latency, thread contention, excessive synchronized blocks, connection pool exhaustion.
Suspension Time Thread execution is forcibly halted by an external runtime supervisor or hypervisor. Garbage Collection (GC) pauses (Stop-the-World), hypervisor CPU throttling/steal time, JVM safe-point bias revoking.
I/O Time (Disk/Network) Thread is blocked waiting for operating system filesystem read/write or socket data transfer. Slow storage disks, unbuffered disk logging, network saturation, DNS lookup latency.
Exam Key Point: High Suspension Time is the primary signature of JVM or .NET Garbage Collection issues. When the garbage collector halts all application threads to perform memory compaction (Stop-the-World phase), Dynatrace records this delay as Suspension Time, not CPU or Wait time.
Call Tree Analysis: Top-Down vs. Bottom-Up Views
Within the Method Hotspots interface, engineers analyze the execution hierarchy using two distinct perspectives: the Top-Down Call Tree and the Bottom-Up Call Tree . +-----------------------------------------------------------------------------------------+
- | CALL TREE ANALYSIS PERSPECTIVES |
- +-----------------------------------------------------------------------------------------+
- | TOP-DOWN VIEW (Natural Execution Flow) |
- | [OrderServlet.doPost()] (100% total time - 2,500 ms) |
- | └── [OrderService.processOrder()] (95% - 2,375 ms) |
- | ├── [PaymentClient.authorize()] (10% - 250 ms) |
- | └── [TaxCalculation.calculate()] (85% - 2,125 ms) |
- | └── [BigDecimal.pow()] (80% - 2,000 ms CPU) <--- Offending Leaf Method |
- | |
- | BOTTOM-UP VIEW (Aggregated Method Impact Across All Requests) |
- | [BigDecimal.pow()] (2,000 ms aggregate CPU time across all calling threads) |
- | └── Called by: [TaxCalculation.calculate()] (2,125 ms) |
- | └── Called by: [OrderService.processOrder()] (2,375 ms) |
- | └── Called by: [OrderServlet.doPost()] (2,500 ms) |
- +-----------------------------------------------------------------------------------------+
- Top-Down Call Tree
Mechanics: Preserves the natural architectural hierarchy of the call stack, originating at the service entry point (e.g., doGet , handleRequest ) and expanding downward toward nested helper methods.
Best Used For: Understanding the end-to-end architectural flow of a specific transaction and identifying which high-level business functions or modules trigger sub-operations.
Bottom-Up Call Tree
Mechanics: Inverts the call stack to surface the most expensive individual leaf methods at the very top of the list, aggregating their execution time across all calling paths.
Best Used For: Rapid root-cause discovery during CPU saturation incidents. If a utility method (such as string formatting or XML deserialization) is invoked by hundreds of different services, the Top-Down view fragments its impact across many branches, whereas the Bottom-Up view immediately aggregates the total CPU drain into a single visible hotspot.
Memory Allocation Profiling and Garbage Collection Impact
Memory issues manifest in two distinct patterns: progressive Memory Leaks (leading to eventual OutOfMemoryError crashes) and High Memory Churn (allocating and destroying millions of short-lived objects, triggering catastrophic Garbage Collection pauses).
Memory Allocation Analysis
OneAgent tracks object allocation rates directly inside running process heaps. In the Memory Allocation Hotspots view, Dynatrace reveals:
The exact classes and arrays consuming the highest memory volume (e.g., byte[] , java.lang.String , java.util.HashMap ).
The specific methods responsible for allocating those objects.
Object allocation rates correlated with individual PurePaths and service requests.
Correlating Garbage Collection Pauses with Service Degradation
When high allocation rates overwhelm the young generation heap, the runtime triggers frequent garbage collection cycles. If objects survive into the old generation, full garbage collection cycles occur, halting all application threads.
Dynatrace automatically correlates process memory metrics with transaction response times:
The Process Group Instance view displays Garbage Collection Time (%) , GC Suspension Count , and Memory Pool Allocation (Eden, Survivor, Tenured / Old Gen).
If GC suspension exceeds baselines, Davis creates a performance problem indicating that service response time degradation is driven by runtime suspension rather than database or code bottlenecks.
Thread Dumps and Concurrency Lock Analysis
When applications become completely unresponsive while CPU utilization remains low, the issue is almost always Thread Lock Contention or Deadlocks .
On-Demand and Automated Thread Dumps
Dynatrace OneAgent can trigger on-demand thread dumps directly from the web console without requiring SSH access, command-line utilities ( jstack , gdb ), or server restarts. Dynatrace automatically analyzes the thread dump and categorizes threads into standard operational states:
Runnable / Running: Threads currently executing instructions on a CPU core.
Waiting / Timed Waiting: Threads paused waiting for a notification from another thread ( Object.wait() , Thread.sleep() , or waiting on a concurrency latch/semaphore).
Blocked: Threads halted waiting to acquire an operating system monitor lock held by another thread ( synchronized block or mutex lock). +-----------------------------------------------------------------------------------------+
- | THREAD CONTENTION & DEADLOCK |
- +-----------------------------------------------------------------------------------------+
- | THREAD 1: (Blocked) |
- | Holds Lock: Monitor Object A (0x00007f9c2a01) |
- | Waiting to acquire: Monitor Object B (0x00007f9c2a02) <-------- DEADLOCK DETECTED! |
- | | |
- | THREAD 2: (Blocked) | |
- | Holds Lock: Monitor Object B (0x00007f9c2a02) | |
- | Waiting to acquire: Monitor Object A (0x00007f9c2a01) <-------+ |
- +-----------------------------------------------------------------------------------------+
- Automated Deadlock Detection
When two or more threads enter a circular dependency waiting for locks held by each other, Dynatrace's thread analysis engine automatically isolates the circular dependency, flags the Deadlock , identifies the involved threads by name, and exposes the exact line numbers where the locks were acquired.