I'm developing an web app using asp.net core. When I run the app in VS 2017 (15.5.5) with Diagnostic tools enabled, memory is constantly increasing at-least 10 to 20MB per click. I thought the app has a memory leak and troubleshooting the app for many hours and I've landed on this link https://blog.markvincze.com/troubleshooting-high-memory-usage-with-asp-net-core-on-kubernetes/
I have created a new project from ASP.NET Core - Web Application Template which has few razor pages and returns HTML. When I refresh the page continuously (like a smoke test) the memory gradually increases from 200MB to 500MB and even more...
have a look on this
As suggested in Mark Vincze blog, I've added following config in .csproj
<PropertyGroup>
<ServerGarbageCollection>false</ServerGarbageCollection>
</PropertyGroup>
Unfortunately it doesn't help. Memory still increases gradually.
All ASP.NET Packages are up-to-date https://www.screencast.com/t/iaQVx9bH5Y1
OS: Windows 10 (1709)
IDE: Visual Studio 2017 (15.5.5)
ASP.NET 2.0.5
Steps to reproduce:
1) Create a project in Visual Studio (ASP.NET Core - Web Application)
2) Run the project with Diagnostic tools enabled
3) Refresh the page continuously and watch the diagnostic tool
4) Memory will increase gradually.
Hi @karthicksu.
Thanks for reporting this issue. One of our engineers will investigate this and get back to you as soon as we'll get more data.
/cc: @DamianEdwards, @Eilon , @rynowak, @danroth27
@pranavkm, can you please look into this one? Thanks
@karthicksu How long did you run the experiment for? I'd expect to see the memory grow up to a point and stay constant even with additional requests after that. I'd be curious to understand why if not.
@muratg I got it! The last two experiments was without the following tag in .csproj, and the solution was not properly built.
<PropertyGroup> <ServerGarbageCollection>false</ServerGarbageCollection> </PropertyGroup>
When I run the project without the tag ServerGarbageCollection, memory usage increases from 200MB to 579MB, after that it stays constant. This time the experiment ran up to 7min. 579MB is still higher when compare to ASP.NET MVC 5 in .NET framework.
However, when using the tag ServerGarbageCollection in .csproj it memory usage stays less as 98MB. This is expected result which is nice.
Do you we need to use tag ServerGarbageCollection false always to reduce the memory usage? and will this work in hosting environments (shared hosting, docker)?
@karthicksu It depends on what you want your performance goals are, what your load profile looks like and probably other factors. Having "high memory usage" is not necessarily bad thing on itself and there are good reasons for ServerGarbageCollection feature (for more information, see https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/gcserver-element)
@muratg Thanks for the reply, provided link helps to understand the behavior of GC. It seems, in .NET Framework, by default ServerGarbageCollection is set to false. Therefore, it doesn't increase the memory usage.
It would be great if the same default value (ServerGarbageCollection set to false) in .NET Core also.
@karthicksu ASP.NET applications on .NET Framework set it to true by default as well.
@davidfowl
Is this https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/gcserver-element different from ASP.NET configuration?
Yes. ASP.NET uses server GC by default.
Thanks everyone. Closing the issue as the behavior observed is by-design.
We have the same issue of growing memory. On Microsoft azure Ubuntu 16.04 VM - memory consumption grows up to 8GB during the day. Same app on Windows Server 2016 - memory does not grow at all. I have both servers via load balancer. So requests hit both servers with 50% probability. Is there any best practices on doing things with memory for Linux. Like it was when we had threads growing and appeared that we had to use HttpClient as a singletone instance or use using(var c = new HttpClient()) construction which I personally thank you @davidfowl for clarifying that case for us...
@amigin Please open a new issue in the Home repo with details about your app so that we can try to investigate the issue.