runtime: Huge memory usage regression in dotnet 7 on linux

Description

A dotnet 7 application consumes much more memory on linux than a dotnet 6 or dotnet 5 application.

After upgrading our application to dotnet 7 we noticed a huge increase in memory consumption in linux, services that used 100 MB were now using twice that amount.

The base issue can be easily reproduced

  1. create new console application
  2. make sure it does not exit instantly, e.g. by using a while loop like:
while (true)
{
    Console.WriteLine("Hello, World!");
    Thread.Sleep(TimeSpan.FromSeconds(1));
}
  1. Verify that in your .csproj file you are targeting dotnet 7:
<TargetFramework>net7.0</TargetFramework>
  1. Switch to a Release configuration
  2. Start it under linux, e.g. by select WSL in the dropdown to launch it.
  3. Verify the used memory, e.g. by running ps aux in your wsl shell and taking a look at the RSS column:
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      5335  2.5  0.4 273549912 103944 pts/6 Sl+ 17:17   0:00 /usr/bin/dotnet /mnt/c/projects/sources/DotNet7Test/DotNet7Test/bin/Release/net7.0/DotNet7Test.dll
  1. Realize in horror that the console process consumes 100+ MB
  2. Stop the debugging
  3. Target dotnet 6 by updating your csproj file to:
<TargetFramework>net6.0</TargetFramework>
  1. Start it under linux, e.g. by select WSL in the dropdown to launch it.
  2. Verify the used memory, e.g. by running ps aux in your wsl shell and taking a look at the RSS column:
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      5383  1.0  0.0 2961956 25504 pts/6   Sl+  17:21   0:00 /usr/bin/dotnet /mnt/c/projects/sources/DotNet7Test/DotNet7Test/bin/Release/net6.0/DotNet7Test.dll
  1. Wonder why the same process consumes only 25MB using dotnet 6.

Configuration

Dotnet 7 on Linux x64, see above

Regression?

Yes, this is a major performance regression in dotnet 7 compared to dotnet 5 or 6.

Other information

Notes: The memory consumption on windows on dotnet 7 is reasonable - it’s just a little higher, but not by crazy amounts. The difference between dotnet 5 and dotnet 6 on linux is negliable.

Take care, Martin

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 15
  • Comments: 28 (13 by maintainers)

Most upvoted comments

Hi @ilia-cy, this should be fixed as part of https://github.com/dotnet/runtime/pull/80173, so should be included in 7.0.3 which should be released next week. Thx.

It should ship one month from today, 3/14.

Would you test with a pre-release build to validate?

I never realized that Pi day is one month after Valentines.

Just to add a note that we deploy a single-file self-contained linux application to end-users machines, so cannot realistically set DOTNET_GCHeapHardLimit, and an unrequired increase of 64mb will no doubt raise significant complaints.

After the update I get:

dotnet --version
7.0.202

After rebuilding and running the executable I can see the memory usage dropped from 100MB to 30MB:

root@N900D90FB:~# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       157  0.3  0.1 273476000 30460 pts/1 Sl+  12:41   0:00 /usr/bin/dotnet /mnt/c/projects/sources/DotNet7Test/DotNet7Test/bin/Release/net7.0/DotNet7Test.dll

Thank you for the fix!

We can now complete the upgrade of our services to dotnet 7, thank you!

Take care, Martin

Hi @declard, your issue seems to be different than the original posted here. That was regarding a vanilla app consuming more memory. I suggest you create a new issue and provide some traces to compare 6 with 7. Would also be good to check if setting DOTNET_GCName=libclrgc.so has any effect on your scenario. Thx!

Hi @8, yeah this is something we are aware of for unconstrained memory environments. We are working on resolving it in a upcoming servicing release, a workaround is to set DOTNET_GCHeapHardLimit to something reasonable (based on expected app usage or physical memory). Its an absolute increase of 64mb hence its exaggerated for hello world style apps.

It also shouldnt be an issue for memory constrainted containers