We have a fairly large site hosted in Azure. It uses the AzureCDNToolkit to manage media. We also make use of caching (to cache expensive node traversal operations).
On reading the change log for one of the recent Umbraco version updates (7.15.5) we thought Christmas had come early "Memory Leak in GetCacheItem cache dependency". We use that method for caching, and I think the AzureCDNToolkit does too. So we've just been through the pain of carefully updating our solution to 7.15.5, but unfortunately the problem remains.
The site runs for approximately 20 hours, gradually using more and more RAM - and then restarts (sometimes cleanly, but often requiring intervention).
Symptoms: If I look at the various graphs in the Azure portal, I can see that in the run up to the app restart, there's a higher than usual number of requests that have a 3xx response (no idea why).
Another symptom is that often the site won't restart whilst the AzureCDNToolkit is enabled. However, even when we run it with AzureCDNToolkit disabled, it still uses more and more RAM until the point it reaches a certain threshold (around 4Gb) and restarts.
Although I mentioned the site was quite large, its not exactly amazon.com - so I'd be staggered it if was really consuming all that memory (our previous Umbraco 4.x site used to use about 500Mb)
The problems are beginning to get us down - anyone got any pointers or thoughts on where we might start to look?
On App Services there is an option to collect a memory dump under 'Diagnose and solve problems' with that you can try figuring out whats sticking around in memory using PerfView.
No, not really :( We have someone looking at our codebase and memory dumps at the moment - to put a separate set of eyes on the problem. If they come up with something we've done that has caused the issue - I'll post about it.
Umbraco 7.15.5 site still leaking memory (or using more and more RAM until it crashes)
Hi all,
We have a fairly large site hosted in Azure. It uses the AzureCDNToolkit to manage media. We also make use of caching (to cache expensive node traversal operations).
On reading the change log for one of the recent Umbraco version updates (7.15.5) we thought Christmas had come early "Memory Leak in GetCacheItem cache dependency". We use that method for caching, and I think the AzureCDNToolkit does too. So we've just been through the pain of carefully updating our solution to 7.15.5, but unfortunately the problem remains.
The site runs for approximately 20 hours, gradually using more and more RAM - and then restarts (sometimes cleanly, but often requiring intervention).
Symptoms: If I look at the various graphs in the Azure portal, I can see that in the run up to the app restart, there's a higher than usual number of requests that have a 3xx response (no idea why).
Another symptom is that often the site won't restart whilst the AzureCDNToolkit is enabled. However, even when we run it with AzureCDNToolkit disabled, it still uses more and more RAM until the point it reaches a certain threshold (around 4Gb) and restarts.
Although I mentioned the site was quite large, its not exactly amazon.com - so I'd be staggered it if was really consuming all that memory (our previous Umbraco 4.x site used to use about 500Mb)
The problems are beginning to get us down - anyone got any pointers or thoughts on where we might start to look?
Thanks,
Steve.
On App Services there is an option to collect a memory dump under 'Diagnose and solve problems' with that you can try figuring out whats sticking around in memory using PerfView.
PerfView: https://github.com/Microsoft/perfview/blob/master/documentation/Downloading.md
I stumbled across this guide about the process, but havn't tried following it myself: https://khalidabuhakmeh.com/diagnosing-memory-leaks-in-azure-app-services-with-perfview
Hope it helps :)
Thank you for the pointers - we'll have a look.
Steve, did you find anything? We have a site with the same challenges.
No, not really :( We have someone looking at our codebase and memory dumps at the moment - to put a separate set of eyes on the problem. If they come up with something we've done that has caused the issue - I'll post about it.
is working on a reply...