Memory is not released when using TransactionScope with async option

[frencsi]

Sample code

while (true)
{
    using (var scope = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled))
    {
        scope.Complete();
    }
}

Memory usage grows, and response times increase until the web api halts. Removing the async option resolves the issue, but async is required in my case. 😞

Workaround (not perfect, see comment)

I created a factory (singleton) around it to manually trigger GC, something like this simplified:

public class TransactionScopeFactory
{
    private const int GcThreshold = 200_000;
    private static int _createdScopes = 0;

    public TransactionScope CreateScope()
    {
        int currentCreatedScopes = Interlocked.Increment(ref _createdScopes);

        if (currentCreatedScopes >= GcThreshold)
        {
            if (Interlocked.CompareExchange(ref _createdScopes, 0, GcThreshold) >= GcThreshold)
            {
                GC.Collect(2);
            }
        }

        return new TransactionScope(TransactionScopeAsyncFlowOption.Enabled);
    }
}

Questions

• Is the workaround okay? I'm a bit hesitant about manual GC, as the docs advises against it without a clear purpose and the TransactionScope docs doesn't mention anything about manually invoking GC.
• Why does the workaround only work in release mode? It doesn't seem to work in debug mode.

Used versions: .NET 8, 9

Thank you 😄

[roji]

@neymecc if GC.Collect() makes the memory go down again, that means that there's no memory problem with TransactionScope - simply that the GC hasn't kicked in yet to reclaim unneeded memory. In .NET (like other GC languages), memory isn't released immediately, but at arbitrary points, when the GC actually kicks in, based on a variety of considerations. For example, if memory on your machine becomes low, it's very likely that the GC will kick in at that point. You can try to keep doing the above in a loop, and eventually memory usage will go down (a real leak would produce an OutOfMemoryException).

I suggest reading the GC docs for more information; if you think you're application is using too much memory, you may want to tweak the GC settings (take a look at workstation vs. server mode for instance).

[frencsi]

@roji, I might have worded this badly sorry about that, but the app is in fact gets killed by the OS with OOM. I created a sample repo for this that can reproduce this issue every time:

https://github.com/neymecc/runtime-issue-108447

I used these commands to setup a docker container with only 2GB of ram & no swap + start the app.

You might have to install libicu (apt-get update &c apt-get install -y libicu-dev)

• docker run -d --memory="2g" --memory-swap="2g" --name="runtime-issue-108447" -p 32999:5000 ubuntu:latest tail -f /dev/null
• dotnet publish -r linux-x64 --self-contained -c Release -o .build
• docker cp "{project-location}\runtime-issue-108447\src\RuntimeIssue108447\.build" runtime-issue-108447:/opt/.build
• docker exec -it runtime-issue-108447 bash
• cd /opt
• chmod +x .build
• cd /opt/.build
• ./RuntimeIssue108447 --urls "http://0.0.0.0:5000"

(optional) Do a benchmark with http benchmarking app like bombardier

• .\bombardier -c 125 -n 10000000 http://localhost:32999/weatherforecast

See the memory charts in this test, the memory is only increasing, latency is degrading, on my system the app gets killed after about a minute. If you increase the RAM, it just delays the kill. GC is trying to do something I can see that but it's like stuck, keeps collecting nothing.

If you remove the async option, it is going to be stable.

I know the test could be better, but without the workaround I have to restart the app like every week.

[frencsi]

@roji, I edited you into the comment above, I’m not sure if it sends a notification after the edit, but just in case, thank you! 😄

[roji]

So just so I understand, is the GC.Collect workaround that you ask about in your original list in fact a workaround, i.e. does it actually prevent the OOM?

[frencsi]

Yes, it does prevent the OOM. In the test above, using that workaround keeps the memory usage ~200 MB (with the used threshold).