- 2 minutes to read

JMX, FAQ, Troubleshooting, Common Questions JMX, FAQ, troubleshooting, common questions 9. What's the difference between monitoring JVM at OS level vs JMX level?

9. What's the difference between monitoring JVM at OS level vs JMX level?

9. What's the difference between monitoring JVM at OS level vs JMX level?

OS-level monitoring ([Windows Server Monitoring Agent][], Task Manager, Performance Monitor):

  • Metrics: Process memory (Working Set, Private Bytes), Process CPU %, handle count, thread count (OS threads)
  • Pros: No JVM configuration required, monitors any process, includes native memory (heap + non-heap + OS overhead)
  • Cons: Cannot distinguish Java heap vs native memory, no GC metrics, no heap "used vs committed" visibility, cannot detect thread deadlocks (only thread count)

JMX-level monitoring (Nodinite JMX Agent):

  • Metrics: Java heap usage (used/committed/max), GC frequency/pause times, Java thread count (application threads), heap allocation rate, Old Gen vs Young Gen
  • Pros: Java-specific insights (heap exhaustion detection, GC storm detection, thread deadlock detection), proactive alerts before OutOfMemoryError, correlates with Java application behavior
  • Cons: Requires JMX enabled in JVM, only monitors Java applications (not .NET, C++, Python processes)

When to use both:

  • OS-level: Initial triage (is process using too much memory? CPU? Is process alive?)
  • JMX-level: Deep dive Java troubleshooting (why is heap 95% full? Is GC thrashing? Which threads deadlocked?)

Example: Windows Server monitoring shows "Java.exe process: 8 GB Working Set, 95% CPU". Question: Is this heap exhaustion or native memory leak? OS metrics cannot answer. JMX monitoring shows "Heap used: 3.8 GB of 4 GB (95%, near limit), GC time 85% of CPU (GC storm)". Answer: Heap exhaustion causing GC storm, increase heap to 8 GB or investigate memory leak.

See all FAQs: [Troubleshooting Overview][]