Add this line to your .csproj file
as a part of the property group holding your target framework, like so
<PropertyGroup> <TargetFramework>netcoreapp3.1</TargetFramework> <ServerGarbageCollection>false</ServerGarbageCollection> </PropertyGroup>
So, one of the things behind running microservices, or any service at all, is the constant use of memory.
Somewhere out there, you might be running a service or two, and depending on the environment and the programming language behind that service, it might require more or less memory just to stay alive, and running an Asp.Net Core service is no different.
Just spinning up a small service in Asp.Net Core requires up to 150MB of memory, so picture you're running a microservice setup containing just a couple of services will quickly require atleast 1GB of memory.
As you might already be thinking, this will quickly add up, so how ca we fix this?
Well, Microsoft themselves has a nice post about Garbage Collection in .Net - Here they explain that there are two different types of Garbage Collection in .Net WorkStation GC and Server GC.
To tell it short, WorkStation GC is more aggressive than Server GC and therefore collects more often.
Testing WorkStation GC we took a simple Asp.Net Core Crud Api and moved from Server to Workstation GC. This Api is serving around 500 requests a minute and swallowed around 230MB of memory.
After moving to Workstation GC the api fell to around 85MB of memory, with no noticeable performance degrading or increased CPU usage on the machines.
This is not a miracle cure, you might have different needs, throughput and so on, that could mean that moving from Server to WorkStation GC could have a performance impact on your service
Do you already run WorkStation GC? If not, try it out - And please share your results