Hey there! Let me walk you through how JMeter calculates CPU and memory usage for your Tomcat (and other server components), and how to make sense of those chart results you’ve collected.

JMeter doesn’t pull these metrics out of thin air—it relies on operating system-level data (for general process stats) or JMX/JVM APIs (for Java-specific apps like Tomcat). Let’s break down each metric:

CPU Usage: What the Numbers Mean #

How JMeter Calculates It #

For a given PID, JMeter grabs two time snapshots of:

1. The total CPU time the process has consumed (both user-mode and kernel-mode)
2. The total CPU time the entire system has used across all cores

It then calculates the delta (difference) between these two snapshots, and uses this formula to get the percentage:

(Process CPU Time Delta / System CPU Time Delta) * 100 * Number of CPU Cores

Key Interpretation Notes #

• Multicore servers mean CPU percentages can exceed 100%: If your server has 4 cores, a Tomcat process using 2 full cores will show as 200% CPU usage. This isn’t an error—it just means the process is utilizing multiple cores efficiently.
• Chart trends matter more than single data points: A spike to 150% for 10 seconds during peak traffic is normal, but sustained usage above 80% (per core, so 320% on 4 cores) signals a bottleneck—think slow database queries, unoptimized code, or thread pool issues.

Memory Usage: Decoding RSS, Heap, and More #

JMeter can collect two broad categories of memory metrics for your Tomcat process:

1. System-Level Memory (RSS/VSZ) #

• RSS (Resident Set Size): The actual physical memory the process is using (not including swap space). JMeter reads this from OS files like /proc/[pid]/status (Linux) or Windows Performance Counters.
  • Interpretation: If RSS grows steadily without dropping, your process might be leaking memory or holding onto unused resources. Compare this to your server’s total RAM—if it’s using 90%+ of system RAM, you’ll start seeing slowdowns or OOM errors.
• VSZ (Virtual Memory Size): The total virtual memory allocated to the process (including swap and unused memory pages). This is less useful for troubleshooting, since it often includes unused space.

2. JVM Heap Memory (Tomcat-Specific) #

If you’re using JMeter’s JMX sampler or a JVM monitoring plugin, you’ll get data about Tomcat’s Java heap:

• Used Heap: The amount of heap memory currently being used by your application.

• Max Heap: The maximum heap size configured for Tomcat (via -Xmx in startup scripts).

• The "heap usage percentage" JMeter shows is (Used Heap / Max Heap) * 100.

  • Interpretation: A steady 60-70% heap usage is healthy. If usage climbs close to 90% and only drops slightly when garbage collection (GC) runs, you might need to increase the max heap size, or investigate memory leaks (objects not being properly garbage collected).

Common Confusions & Quick Fixes #

• Q: Why does JMeter’s CPU percentage not match top or taskmgr?
  A: top shows CPU usage per core by default (so max 100% per core), while JMeter calculates total usage across all cores. Multiply top’s per-core percentage by the number of cores to match JMeter’s number.
• Q: Why is memory usage different between JMeter and jstat?
  A: jstat focuses on JVM heap/non-heap memory, while JMeter might be showing RSS (process-level memory) which includes heap, non-heap, and native libraries. Always check which metric your sampler is configured to collect.
• Q: How do I confirm which metrics JMeter is collecting?
  A: Look at your sampler configuration:
  • If using the Process Sampler, it explicitly lists CPU, RSS, and VSZ as collected metrics.
  • If using a JMX sampler, it will reference MBeans like java.lang:type=Memory (for heap stats).

内容的提问来源于stack exchange，提问作者Sunil Sunny