Excessive memory usage on Transaction Controller using parent sample

[jgaalen]

Expected behavior

When 'generate parent sample' is enabled on a Transaction Controller, it should clear the data once the transaction is finished and processed by the listeners. This is to avoid unnecessary excessive memory usage per thread.

Actual behavior

When 'generate parent sample' is enabled on a Transaction Controller, it looks like it doesn't clean the data after the transaction is finished. When there are samplers with very large bodies (ie. large java scripts), the memory piles up for the duration of the Thread. When generate parent sample is disabled, it does clear the sample data as memory usage is significantly low

Steps to reproduce the problem

Place 30 samplers/ HTTP requests to large objects (1MB) in a Transaction Controller with Generate parent sample enabled. With a 1 second think time in between, 30 threads, it will use up to 3 GB of memory.
When disabling the generate parent sample, it will reduce memory usage to 500MB.

Based on calculations and playing around with different values it feels like the body is kept in memory 3 times for the duration of the thread

JMeter Version

5.6.3

Java Version

17

OS Version

Ubuntu

[jgaalen]

I made a heapdump and looked at it. It seems that the responseData is filled up for the transactionSampleResult.subResults. Somehow the transactionSampler needs to be cleared right after the data is sent to the listeners, but it isn't and kept in memory until the end of the thread. With large responseData/subresults this can pile up.
I've started researching as I've had tests with just 300-500 concurrent Vusers but many requests in transactions with memory exceeding 16GB and ending in OOM everytime.

[BrightSummer]

We attempted to upgrade JMeter from version 5.2.1 to 5.6.3, but encountered the same problem. Specifically, when using the same scripts and resource configuration, JMeter version 5.6.3 experiences an OOM issue.

[vlsi]

I thought SampleResult should be discarded after the transaction finishes. If that is the behaviour, then releasing subresults should not change much.

On the other hand, if the listener can access subResults, we can't really nullify it. Unfortunately, we can't tell for sure if there will be a sampler that accesses subResults or not, so I think it is the reason JMeter conservatively keeps subResults in memory.

[vlsi]

Could you share a test case to reproduce the failure?

[jgaalen]

Could you share a test case to reproduce the failure?

I've shared test results in the PR with the fix. Done a lot of testing against it. It lowers memory uses so much, and listeners still has all the data

[vlsi]

We need a test to reproduce the failure, and it would be nice to include the test into the regression suite.

[jgaalen]

We need a test to reproduce the failure, and it would be nice to include the test into the regression suite.

There's actually an issue I just found out:

prev.getResponseDataAsString()

This isn't working anymore :( So we can only clean up the data after the 2nd root sample/parent, or use a setting if you don't need the prev results for memory optimisation (there are not a lot of scripts that use the prev results).
But the measurements show there is so much memory to be gained here! Let me try to fix that