Next Practical Step
Disable View Results Tree, set a larger HEAP for a pilot CLI run, and re-check with the Heap Estimator if you still OOM.
Fix JMeter OutOfMemoryError Java heap space: raise heap, cut threads, disable View Results Tree, trim result saving, and split injectors. Symptom and fixes.
OutOfMemoryError: Java heap space in JMeter
Section titled “OutOfMemoryError: Java heap space in JMeter”Symptom
Section titled “Symptom”- JMeter exits or freezes with
java.lang.OutOfMemoryError: Java heap space - Long GC pauses, injector becomes unresponsive
- In containers: pod/container OOMKilled even without a clear Java stack
- Often appears when increasing threads, enabling View Results Tree, or saving full responses
Common causes
Section titled “Common causes”Official best practices stress lean injectors:
| Cause | Detail |
|---|---|
| Heap too small for threads | Roughly more concurrent threads → more live objects; default heap may be too low |
| View Results Tree / heavy listeners | Keep detailed sample data in memory - debug only |
| Too many threads on one JVM | Need more engines (distributed) or lower concurrency |
| Saving too much | XML results, response data, large bodies |
| Heavy scripts | BeanShell/JavaScript on hot paths; prefer JSR223 Groovy with compile cache |
Container limit below -Xmx | cgroup kills the process (Docker/K8s) |
Fix (ordered)
Section titled “Fix (ordered)”-
Switch to non-GUI for load
Terminal window jmeter -n -t plan.jmx -l results.jtl -e -o report/ -
Disable View Results Tree, View Results in Table, and other heavy listeners for the load run (best practices).
-
Size heap for the injector using the Heap Estimator as a starting point; set
HEAP/JVM_ARGS(for example-Xms512m -Xmx2048m) per your launch scripts, then restart JMeter. -
Reduce threads per engine; scale out with multiple CLI instances or remote workers rather than one huge JVM.
-
Prefer CSV result files and only the saveservice fields you need (dashboard requirements).
-
Replace expensive scripting with JSR223 + Groovy, cache compiled scripts, use
vars.get("x")not embedded\${x}in cached scripts (best practices). -
In Docker/K8s: set memory limits above
-Xmxplus native overhead. -
Re-test with a pilot; watch GC logs if problems continue.
Related tools and topics
Section titled “Related tools and topics”| Resource | Use when |
|---|---|
| Heap Estimator | Starting -Xmx guess |
| Thread Calculator | Fewer threads if RPS allows |
| Distributed testing | Spread load across engines |
| Docker / Kubernetes | cgroup OOM |
| Best practices | Lean plan rules |
Frequently asked questions
Section titled “Frequently asked questions”Is OutOfMemoryError a server problem?
Section titled “Is OutOfMemoryError a server problem?”Often it is the JMeter injector. Confirm with injector GC/heap metrics before blaming the SUT.
Why does GUI mode OOM faster?
Section titled “Why does GUI mode OOM faster?”GUI rendering plus listeners keep more objects alive. Official guidance: use GUI to build, CLI for load.
How much heap do I need?
Section titled “How much heap do I need?”It depends on threads, response sizes, scripting, and listeners. Start from the Heap Estimator, then validate under a pilot run.
People Also Ask
How do I fix OutOfMemoryError Java heap space in JMeter?
Run non-GUI load, disable View Results Tree, increase HEAP or -Xmx, reduce threads per engine, save fewer result fields, prefer Groovy over heavy scripts, and ensure container memory limits exceed the heap.
Is JMeter OutOfMemoryError always the server under test?
Often it is the injector JVM. Check JMeter heap and GC behaviour before blaming the application servers.
Was this page helpful?
Thanks for the feedback!Tell us what's missing on GitHub