The same asp.net core application runs on windows and linux, the workspace memory usage is doubled

[dorthl]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

dotnet sdk version 7.0.100-preview.6.22352.1
windows version windows 11 22000.795
linux version Linux archlinux 5.18.12-arch1-1

Exact same asp.net core simple application
run as dotnet xxx.dll
Use dotnet-counters monitor to view Working Set (MB) windows:108.343,linux:215.679

Describe the solution you'd like

I know that this may be caused by the differences in the implementation of dotnet on different platforms, but I have not inquired about such differences and explanations in dotnet, asp.net core documents and blogs.
This has brought me a lot of trouble. The application is developed on the windows platform and then deployed on the linux platform. The difference causes that when I publish the application to the running platform, the memory usage is twice or even larger than expected. difference

Additional context

My English is not good, please forgive me

[javiercn]

@dorthl thanks for contacting us.

Have you tried capturing a couple of memory dumps and checking the heaps for differences?
Can it be that you are building/running 32 bits on windows and 64 bits on Linux?

[adityamandaleeka]

Transferring to dotnet/runtime since this is likely a difference at the CoreCLR level.

@dorthl Can you also confirm whether this is on the same machine? Do you have the same number of cores and same amount of RAM when you're running on Linux and Windows?

In general, it's not unexpected that you'd see some differences in working set and such on different OS's.

[dorthl]

@adityamandaleeka thank you for your reply

I have tested it on multiple computers with windows and linux systems. I know that there are differences in the implementation of CoreCLR on different operating systems, but this difference is too huge in practice, resulting in the development and deployment of multiple platforms. Unpredictable

The latest test result is to create the simplest asp.net core application

### csproj
<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net7.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

</Project>

### Program.cs
var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.Run();

### publish
#### windows
dotnet publish -c Release -r win-x64 --self-contained
##### run
.\WebApplication.exe
#### linux
dotnet publish -c Release -r linux-x64 --self-contained
##### run
./WebApplication

Use dotnet-counters monitor
Windows Working Set (MB) 45.298,linux Working Set (MB) 144.118

windwos system: windows 11 22000.795 cpu: intel i5-7500(4 cores 4 threads) Ram 16GB
linux system archlinux 5.18.12-arch1-1 cpu intel m3-7Y30(2 cores 4 threads) Ram 4GB

It has also been tested on the cloud server, and the cloud server for linux results is the same as the local linux, so I think it is a system implementation difference

Or maybe it could be a difference at the CoreCLR level.
I initially thought that this was caused by differences in the implementation of http servers in asp.net core on different operating systems

The point is that the difference in memory usage is double or even more. My asp.net core is usually deployed on a linux server through docker, and usually a few or a dozen asp.net cores are deployed application, the difference is quite obvious

I just feel that this huge difference needs to be explained in the documentation or blog so that in development deployment this situation is expected

[mangod9]

@dorthl this should be resolved in preview7 with this fix: #71164. preview7 will release in a few weeks. Thx.

[dorthl]

Thanks, looking forward to the release of preview7

[mangod9]

If you would like you can try out the preview7 builds from here: https://github.com/dotnet/installer, to ensure the issue is indeed resolved for you. Thx!

[dorthl]

@mangod9 It is a pity that after updating the sdk there is no change on the linux-64 platform

environment

sdk: 7.0.0-preview.7.22375.6
archlinux: 5.18.14-arch1-1 x64

dotnet-counters Working Set (MB) 229.765, windows 100~mb

[dorthl]

@mangod9 Still a simple asp.net core application

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();

sdk: 7.0.0-preview.7.22375.6 run windows Working Set (MB) 44.306 linux Working Set (MB) 140.988
Reported by dotnet-counters

[mangod9]

Hmm.. is your linux container still running with 4gb of memory available?

[mangod9]

Also, are you noticing any difference between preview6 and preview7 when measured on linux?

[dorthl]

@mangod9 If there is a difference, I see no difference, everything remains the same
Running on linux on a local test machine and not having 4gb of memory available
It runs directly on the test machine without using docker

linux local test machine top

MiB Mem :   3807.7 total,    666.9 free,    906.7 used,   2234.1 buff/cache
MiB Swap:   4096.0 total,   3771.0 free,    325.0 used.   2542.2 avail Mem 

The cloud server is only a test machine, so only 2GB of total memory is actually about 1.8GB, and the available memory is about 800MB, the result is the same

The production environment has a larger memory environment, but I can't test in the production environment

[mangod9]

hmm, that is interesting. We have seen a drop in working set for our asp.net benchmarks. @mrsharm fyi.

[danmoseley]

@dorthl did you close because this is resolved for you?

[dorthl]

@danmoseley i didn't solve it

But I did a lot of tests and found that the smaller Working Set of windows is just an optimization of .net for windows
For a simple asp.net core Working Set, it is normal at 100M~,Partial memory application in windows to use shared memory or some windows-specific~
The usual explanation for linux is that there is no relevant alternative api on this platform
The main support of .net is not linux, I understand that