- 3 minutes to read

OS-Level vs JVM-Level Monitoring

This troubleshooting guide provides a monitoring comparison between OS monitoring and JVM monitoring so you can choose the right level of resource monitoring and process monitoring for each Java workload.

Key Differences

Metric OS-Level (Windows WMI) JVM-Level (JMX)
CPU Usage Total CPU for the Java process JVM CPU time only (excludes GC threads)
Memory - Physical Total physical RAM used by Java process N/A
Memory - Heap Not available Heap Used, Heap Committed, Heap Max
Garbage Collection Not available GC count, GC duration, GC overhead
Thread Count Total OS threads JVM thread count, deadlock detection
Class Loading Not available Loaded classes count
JVM Uptime Process start time JVM uptime in milliseconds
graph TD subgraph "OS Layer" A[" Windows Server"] B["Physical CPU (WMI)"] C["Physical RAM (WMI)"] D["Process List (WMI)"] end subgraph "JVM Layer" E["fab:fa-java Java Process"] F["Heap Memory (JMX)"] G["CPU Time (JMX)"] H["GC Metrics (JMX)"] I["Thread Count (JMX)"] end A --> E E --> F E --> G E --> H E --> I style F fill:#90EE90 style G fill:#90EE90 style H fill:#90EE90 style I fill:#90EE90

Diagram: OS-layer metrics from Windows monitoring and WMI versus JVM-layer metrics from JMX, showing that JMX provides heap and GC visibility that OS monitoring cannot.

When to Use OS-Level Monitoring

Use Windows WMI and Windows monitoring for:

  • Overall server health: disk space, total physical memory, server CPU
  • Multiple processes on the same server, not just Java
  • Detecting operating system resource exhaustion that affects all applications
  • Monitoring non-Java applications on the same server

When to Use JVM-Level Monitoring

Use the Nodinite JMX Monitoring Agent for:

  • Detecting Java OutOfMemoryError before it occurs
  • Monitoring heap memory consumption per JVM application
  • Tracking garbage collection pressure and GC overhead
  • Monitoring Boomi Atom, Spring Boot, and other JVM-based integration applications

Using Both Together

For critical Java infrastructure, use both monitoring layers simultaneously:

  • OS monitoring detects server-wide issues such as disk full, network saturation, and OS crashes
  • JMX monitoring detects Java-specific issues such as heap exhaustion, GC storms, and thread deadlocks

Tip

If OS CPU shows 100% but JMX CPU is normal, the issue is with a non-Java process. If JMX CPU is high but OS CPU is normal, a JVM-specific thread is causing overhead. Use both metrics together for root cause analysis.

Physical Memory vs Heap Memory

A common confusion is that OS monitoring shows physical memory used by the Java process, while JMX monitoring shows heap memory managed inside the JVM. These are different:

  • Physical memory = heap + off-heap (direct buffers, Metaspace, stack, JIT code)
  • Heap memory = only the objects managed by the garbage collector
  • A JVM with 2 GB Xmx may use 3 GB+ of physical memory when off-heap is included

Important

Monitor heap memory via JMX to detect OutOfMemoryError risk. Monitor physical memory via OS tools to ensure the server has sufficient RAM for the JVM and other processes.

Next Step

Docker Container Monitoring
Enable JMX Remote Monitoring

Multi-JVM Monitoring
Heap Used vs Committed
JMX Monitoring Agent JMX Troubleshooting Overview