Repository navigation
Memory leak related to OptionsMonitor<LoggerFilterOptions> and Serilog #63578
Description
Activity
Does it reproduce if you remove the Serilog logger?
Does it reproduce if you remove the Serilog logger?
Hi @eerhardt thanks for responding. I have not tried that yet. It would be non trivial so swap out Serilog and use something else as its using lots of the Serilog features. We have other services that use Serilog in the same way and don't have this issue but I could try go down that road. I was hoping from the info I extracted from the memory dumps someone might spot something basic I was missing.
I think that's where I'd start looking. Why are that many objects being created? Why are they all still in memory?
Also, consider trying to upgrade to .NET 6 and see if it still reproduces.
If we don't have a more condensed view of the issue with a minimal repro, there is not much we could do to progress here.
If we don't have a more condensed view of the issue with a minimal repro, there is not much we could do to progress here.
@maryamariyan ok it would be difficult to put a minimal repo together but I will try if I cant figure anything else out and raise another issue. Thanks for responding to this. I will close it for now.
- ghost locked as resolved and limited conversation to collaborators
on Feb 11, 2022
Hello,
I have what looks to be a memory leak in a production web service related to OptionsMonitor and Serilog. Over a period of about 10 days the memory usage gradually increases from starting point of ~200MB up to ~1GB at what point it hits Kubernetes limits and Out of Memory Exceptions start being thrown. K8s then restarts the pod as it is seen as unhealthy.
Environment
I got some dumps from the production container and was able to analyse with JetBrains dotMemory tool. It is pointing to OptionsMonitor having the Largest retained size. There are ~300k instances of Serilog.Core.Logger being retained in memory also that are attached to the OptionsMonitor onChange event that gets fired. I think this happens when configuration updates. Although there is nothing explicitly updating the configuration files so I am not sure why this keeps firing. I am not sure why these objects are not being released from memory. I saw from a few years back there was a memory leak fixed in OptionsMonitor but that was prior to the version of asp.net core being used dotnet/extensions#868 .Here is a couple of screenshots from dotMemory with the overview and then a retention graph which shows Serilog.Core.Logger attached to OptionsMonitor. Any ideas what is going on here?