gatling simulation out of memory: heap tuning

Not specified by the original author.

TL;DR

Gatling holds virtual-user state and response data in the heap, and the default JVM heap is sized for small runs. Raise the max heap, reduce what each user retains (especially response bodies), and confirm with GC logging. The simulation then survives its own peak.

Error

gatling simulation out of memory: heap tuning

Gatling simulation dies with java.lang.OutOfMemoryError: Java heap space at peak user injection.

Steps

1. Capture the OOM type from the crash: heap space versus metaspace point at different fixes. Expected output: you know whether to grow the heap or the metaspace.
2. Raise the max heap: set it in the Gatling launch config or JAVA_OPTS to a value the machine actually has. Expected output: the JVM starts with the larger heap.
3. Trim per-user retention: avoid storing full response bodies in checks or session attributes unless the scenario needs them. Expected output: heap per virtual user drops.
4. Re-run the simulation and watch GC logs for long pauses or a climbing old generation. Expected output: GC keeps up and the run completes.
5. If it still OOMs at peak, lower the peak injection rate or split the scenario across runs. Expected output: a load profile the heap can sustain.

When to use

• Gatling dies with OutOfMemoryError during a run.
• OOM happens only at peak user counts.
• You are sizing Gatling for a new load profile.

When not to use

• The application under test OOMs (tune the app, not Gatling).
• The simulation is slow but completes (that is tuning, not OOM).
• Metaspace errors on startup (that is classpath bloat, not heap).

Variant phrasings

OOM only at ramp peak

Peak concurrency is the memory high-water mark; size the heap for the peak, not the average.

Metaspace OOM

Too many classes loaded, often from huge feeders or scripts; raise MaxMetaspaceSize or trim the classpath.

Heap dump analysis

A dump at OOM shows what the heap held; look for session attributes and check bodies first.

Why it happens

Each virtual user carries session state, and checks can pin response bodies in memory until the scenario ends. Memory grows with concurrent users, so a profile that fits at 100 users can exhaust the default heap at 1000.

Edge cases

• Setting the heap larger than available RAM causes swapping, which looks like a hang rather than an OOM.
• G1GC is the sane default for Gatling; exotic collectors need retuning of pause targets.
• Feeder files load fully into memory; huge CSV feeders belong in streaming or batched mode.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstjsSktS6MSIcHvezCFIFIA

Resolved from the public thread: https://vectle.com/posts/pstjsSktS6MSIcHvezCFIFIA

Thread query: gatling simulation out of memory: heap tuning

TL;DR: Gatling holds virtual-user state and response data in the heap, and the default JVM heap is sized for small runs. Raise the max heap, reduce what each user retains (especially response bodies), and confirm with GC logging. The simulation then survives its own peak.

Not specified by the original author.

Elasticsearch OutOfMemory on a small VPS: heap sizing and mlockall

TL;DR

[accepted answer]: this is a heap space issue. Rules of thumb: 1. Give Elasticsearch about half the box's RAM as heap, e.g.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

export ESHEAPSIZE=2g on a 4GB machine. Never set heap above ~50% of RAM (the OS needs the rest for filesystem cache), and never above ~32GB or you lose compressed object pointers. 2. Lock the memory for the JVM: set bootstrap.mlockall to true in the config so the heap never gets swapped out. 3. Investigate the disk: with only 30 small articles a 26GB data folder means something is off. Run GET cat/indices to find which index is huge (old log indexes that never got deleted are the usual suspect), and GET /nodes/stats for detailed node info. Tiny VPS + defaults is the classic combo: the default heap is small and shards/indexes pile up silently until the node falls over.

Context: Stack Overflow #34601697 (accepted answer, 17 votes): a small blog on a 4GB VPS runs fine for two months, then Elasticsearch dies with an Out of Memory (heap space) error. The asker also notices the data folder is 26GB for just 30 small articles.

Source: Stack Overflow #34601697 (accepted answer, 17 votes): a small blog on a 4GB VPS runs fine for two months, then Elasticsearch dies with an Out of Memory (heap space) error. The asker also notices the data folder is 26GB for just 30 small articles.

Verified resolution: [accepted answer]: this is a heap space issue. Rules of thumb: 1. Give Elasticsearch about half the box's RAM as heap, e.g. export ESHEAPSIZE=2g on a 4GB machine. Never set heap above ~50% of RAM (the OS needs the rest for filesystem cache), and never above ~32GB or you lose compressed object pointers. 2. Lock the memory for the JVM: set bootstrap.mlockall to true in the config so the heap never gets swapped out. 3. Investigate the disk: with only 30 small articles a 26GB data folder means something is off. Run GET cat/indices to find which index is huge (old log indexes that never got deleted are the usual suspect), and GET /nodes/stats for detailed node info. Tiny VPS + defaults is the classic combo: the default heap is small and shards/indexes pile up silently until the node falls over.

Source URL: https://stackoverflow.com/questions/34601697

Not specified by the original author.

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.