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
- create new console application
- 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));
}
- Verify that in your .csproj file you are targeting dotnet 7:
<TargetFramework>net7.0</TargetFramework>
- Switch to a
Release
configuration - Start it under linux, e.g. by select
WSL
in the dropdown to launch it. - Verify the used memory, e.g. by running
ps aux
in your wsl shell and taking a look at theRSS
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
- Realize in horror that the console process consumes 100+ MB
- Stop the debugging
- Target dotnet 6 by updating your csproj file to:
<TargetFramework>net6.0</TargetFramework>
- Start it under linux, e.g. by select
WSL
in the dropdown to launch it. - Verify the used memory, e.g. by running
ps aux
in your wsl shell and taking a look at theRSS
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
- 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)
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 of64mb
will no doubt raise significant complaints.After the update I get:
After rebuilding and running the executable I can see the memory usage dropped from 100MB to 30MB:
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 of64mb
hence its exaggerated for hello world style apps.It also shouldnt be an issue for memory constrainted containers