# 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.

```text
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