High memory consumption of .Net 6 app on Linux #96091
Comments
|
Tagging subscribers to this area: @dotnet/gc Issue DetailsI encountered a very serious problem when switching from Windows to Linux (Ubuntu). The problem is very high memory consumption. I first noticed an increase in memory consumption on Windows when moving from .Net Framework to .Net Core 5. But then this was not much of a problem and was acceptable since the increase was not large. The .Net Framework application consumed approximately 150-200 megabytes and the .Net Core 5 application consumed approximately 250-350 megabytes. But when I switched to Linux, the consumption increased many times over. To make the transition, I switched to .Net 6. After running the application on Linux, I noticed that memory grows over time and does not decrease; with long-term operation of the application, memory consumption can reach 6-8 gigabytes. After doing a memory dump, I noticed that almost 90% was taken up by unmanagement memory. There are about 50 instances of this application running on my server, and they quickly consume all the memory, which leads to application crashes. I have no idea why this is happening, it seems that Garbage collection is not freeing the reserved memory. For information, on Windows under IIS the application worked in 32-bit on Linux in 64-bit. I tried changing Garbage collection settings such as (DOTNET_GCConserveMemory and DOTNET_gcServer), but it didn't help. My application is essentially a CMS hosted using nginx. Basically this is a site using liquid (https://mtirion.medium.com/using-liquid-for-text-base-templates-with-net-80ae503fa635) to parse content. It also runs several hosted services that periodically run tasks such as retrieving data from the database to send email if any, checking for changes in data in a file. Even when no requests are sent to my site (for example at night), memory usage does not decrease. I have done a few things like getting memory dump, dotnet-gcdump, dottrace and dotnetdump but I am not very knowledgeable about it and can provide as per need.
|
Do you have an idea what is allocating that? Are you loading any native libraries? You mention the GC - do you have reason to believe the GC is involved? Eg you are expecting something to be finalized and it's not. Generally unmanaged heap would not be a GC issue. |
|
I have no idea what fills the memory. But I don’t understand why this only happens on Linux; it works fine on Windows. The difference is that on Windows the application runs under .Net 5, and on Windows under .Net 6. |
|
@denislohachev1991 please see my comment here on a similar issue: #95922 (comment). |
|
@janvorli I’m not very good at this, in the comment to which you refer, I learned that I can share the dump file with you so that you can conduct your investigation. I created this dump file while the application was running and it was using a lot of memory. If I understand you correctly, tell me how I can give you the dump file. |
|
@denislohachev1991 you can place it to your onedrive or google drive or something like that and then send me a private email with details on how to access it. My email address my github name @ microsoft.com. |
|
I seem to have encountered a similar problem, have you resolved it? |
|
Is this on .NET 6 only, or does the same issue repro with 8? |
|
@mangod9 After moving to .Net 8, the problem has decreased a little compared to .Net 6. But it still consumes much more memory than on a Windows server. |
|
@janvorli I have encountered a similar problem in our microservice. On Windows, the app works fine, but on Linux, the memory usage keeps increasing. I gathered some dumps using heaptrack and dotnet-dump and sent them to your MS email. Please let me know if you could take a look. Thank you very much. |
|
We may also have the same issue, a lot of unmanaged memory usage, dotnet runtime version:
|
|
Upgraded from .NET8 to .NET9 and noticed the increased usage of unmanaged memory. The container was running fine on .NET8 with 256MB but since moving to .NET9 it get's restarted due to OOM. The managed memory is pretty low ~70-80MB but unmanaged memory is north of 250MB. |
I encountered a very serious problem when switching from Windows to Linux (Ubuntu). The problem is very high memory consumption. I first noticed an increase in memory consumption on Windows when moving from .Net Framework to .Net Core 5. But then this was not much of a problem and was acceptable since the increase was not large. The .Net Framework application consumed approximately 150-200 megabytes and the .Net Core 5 application consumed approximately 250-350 megabytes. But when I switched to Linux, the consumption increased many times over. To make the transition, I switched to .Net 6. After running the application on Linux, I noticed that memory grows over time and does not decrease; with long-term operation of the application, memory consumption can reach 6-8 gigabytes. After doing a memory dump, I noticed that almost 90% was taken up by unmanagement memory. There are about 50 instances of this application running on my server, and they quickly consume all the memory, which leads to application crashes. I have no idea why this is happening, it seems that Garbage collection is not freeing the reserved memory. For information, on Windows under IIS the application worked in 32-bit on Linux in 64-bit.
I tried changing Garbage collection settings such as (DOTNET_GCConserveMemory and DOTNET_gcServer), but it didn't help.
My application is essentially a CMS hosted using nginx. Basically this is a site using liquid (https://mtirion.medium.com/using-liquid-for-text-base-templates-with-net-80ae503fa635) to parse content. It also runs several hosted services that periodically run tasks such as retrieving data from the database to send email if any, checking for changes in data in a file. Even when no requests are sent to my site (for example at night), memory usage does not decrease. I have done a few things like getting memory dump, dotnet-gcdump, dottrace and dotnetdump but I am not very knowledgeable about it and can provide as per need.
The text was updated successfully, but these errors were encountered: