You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for this analysis that has been really helpful to understand garbage collection behavior in .NET core.
We have been investigating some weird memory issues on docker containers running aspnet core 2.1.5. I have been using your bigstring endpoint example as benchmark...
What we're finding is that in .NET core 2.1, when constraining container memory to 256MB or less and applying some load, the memory quickly jumps up until the container dies.
If only limiting to 512MB, the memory jumps all the way to 480MB, then drops to 280MB and stays stable...
Changing <ServerGarbageCollection> to false solves the problem but given the fact it seems the surge only happens initially, it seems something should be fixed at .NET Core level to make sure it respects the memory limit set.
Finally, please note that when running the same service on .NET Core 2.0, the memory only jumps to 200MB (80%) ... so this behavior seems to be new in 2.1
Is this a known issue?
I might post an issue in the dotnet repo but given your history on this topic, I though I would post this here first...
Thanks,
Patrick
The text was updated successfully, but these errors were encountered:
Hi Sebastien,
Thanks for this analysis that has been really helpful to understand garbage collection behavior in .NET core.
We have been investigating some weird memory issues on docker containers running aspnet core 2.1.5. I have been using your bigstring endpoint example as benchmark...
What we're finding is that in .NET core 2.1, when constraining container memory to 256MB or less and applying some load, the memory quickly jumps up until the container dies.
If only limiting to 512MB, the memory jumps all the way to 480MB, then drops to 280MB and stays stable...
Changing
<ServerGarbageCollection>
to false solves the problem but given the fact it seems the surge only happens initially, it seems something should be fixed at .NET Core level to make sure it respects the memory limit set.Please also note that if we are also constraining the CPU, the memory stays under control (around 130MB). Memory limit therefore seems linked to number of CPUs available (as indicated in https://blog.markvincze.com/troubleshooting-high-memory-usage-with-asp-net-core-on-kubernetes/)
Finally, please note that when running the same service on .NET Core 2.0, the memory only jumps to 200MB (80%) ... so this behavior seems to be new in 2.1
Is this a known issue?
I might post an issue in the dotnet repo but given your history on this topic, I though I would post this here first...
Thanks,
Patrick
The text was updated successfully, but these errors were encountered: