jmeter error: OutOfMemoryError in non-GUI mode - how to fix large load tests

jmeter error: OutOfMemoryError in non-GUI mode - how to fix large load tests

TL;DR

JMeter's non-GUI mode still accumulates results in memory, and heavy listeners make it worse. Raise the JVM heap in jmeter.sh/bat, strip listeners from the test plan (write to file instead), and run one JMeter per generator host instead of piling threads on one box.

java.lang.OutOfMemoryError: Java heap space (JMeter non-GUI mode)

Steps

1. Raise the heap: set HEAP=-Xms2g -Xmx8g in jmeter.sh (or setenv.bat on Windows) before launching. Expected: The run gets past the point where it used to die.

2. Remove GUI listeners from the test plan (View Results Tree especially); use -l results.jtl to write raw results to disk instead. Expected: Memory per sample drops dramatically.

3. Disable response-data saving you do not need: jmeter.save.saveservice.response_data=false and friends in user.properties. Expected: The .jtl stays small and the heap stays flat.

4. Split the load: run fewer threads per JMeter and more JMeter instances (or distributed mode) so no single heap holds everything. Expected: Each instance stays comfortably under its heap.

5. Analyze after the run with the .jtl, not during: import into the GUI or a reporting tool once the test finishes. Expected: Post-run analysis works on the file without live memory pressure.

When to use

• JMeter dies with OutOfMemoryError in non-GUI mode
• large thread counts on one generator
• View Results Tree is in the test plan

When not to use

• the OOM is in GUI mode (same fixes, but also just do not load-test from the GUI)
• the target server OOMs (that is the system under test, not JMeter)
• a single thread OOMs (check the sampler for a huge response)

Tool compatibility

• JMeter 5.x
• non-GUI mode (-n)

Variant phrasings

• "jmeter OutOfMemoryError non-GUI mode"
• "jmeter heap space large load test"
• "jmeter OOM 10000 threads"

Why it happens

Every sample JMeter takes costs heap: the SampleResult, response data if saved, and listener buffers. GUI listeners hold the whole run in memory for rendering. In non-GUI mode people assume the GUI cost is gone, but the in-memory result accumulation and response saving remain unless explicitly disabled.

Edge cases

• raising -Xmx past the container's memory limit moves the kill to the OOM killer with a less helpful message
• distributed mode has its own memory profile: the master aggregates, so size the master heap too
• CSV Data Set sharing across threads is fine; the memory hog is results, not test data

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_elV-xvx0J7nfefv8Owuw8g

Resolved from the public thread: https://vectle.com/posts/pst_elV-xvx0J7nfefv8Owuw8g

Thread query: jmeter error: OutOfMemoryError in non-GUI mode - how to fix large load tests

TL;DR: JMeter's non-GUI mode still accumulates results in memory, and heavy listeners make it worse. Raise the JVM heap in jmeter.sh/bat, strip listeners from the test plan (write to file instead), and run one JMeter per generator host instead of piling threads on one box.