9

We implemented the Autofac to work with Sitecore default DI implementation by following the guide below: https://doc.sitecore.net/sitecore_experience_platform/developing/developing_with_sitecore/dependency_injection

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection

And here's the code snippet:

public class AutofacServiceProviderBuilder
  : BaseServiceProviderBuilder
    {
        protected override IServiceProvider BuildServiceProvider(IServiceCollection serviceCollection)
        {
            var builder = new ContainerBuilder();

            builder.Populate(serviceCollection);

            // Register our custom services via a module.
            builder.RegisterModule<ServicesModule>();

            // Register all MVC controllers in the current assembly.
            builder.RegisterControllers(Assembly.GetExecutingAssembly());
            RegisterServices(builder);
            //builder.RegisterFilterProvider();
            IContainer container = builder.Build();
            Platform.ServiceLocator.SetLocator(container);
            return container.Resolve<IServiceProvider>();
        }
    }

While doing a load testing, we are seeing a steady increase of memory usage for our asp.net mvc application hosted in azure web app. Once memory hits 90% site become unresponsive and crashes.

Looking at memory dump we noticed a top large objects are related to autofac. enter image description here enter image description here

By analyzing the memory dump we found that ALL of our Controllers are referencing to the Root scope hence they never get garbage collected and eventually fills up the memory.

Would be good if I can get any suggestions on what we are doing very wrong that makes all our controllers hanging off Root.

  • 1
    I think you might be reading the memory dump incorrectly. Inclusive Size (Bytes) includes the sizes of referenced objects (see here). So the Autofac entities don't really take up much memory, it's the objects they reference that might be the issue. Could you show us the same table, but sorted by Size (Bytes) instead? This would show which objects take up the most memory. – Dmytro Shevchenko Jun 7 '17 at 13:48
  • 1
    And might I add; a single snapshot of memory does not indicate a memory leak. For it to be a memory leak, the number would have to be growing continuously over time - never coming back down again. – Mark Cassidy Jun 7 '17 at 15:36
  • Just to add onto what @MarkCassidy said, monitoring that data overtime is very important to understanding what the data is actually telling you. For example, if you experience instances where the memory use builds up and then takes steep drops, this could be a sign that your application is making heavy use of caching and responsively (and correctly) evicting caches when short on machine resources. When executing any load testing, it is important to spend some of your time running heavy, unrelated processes on the server to see how the application reacts to system resource usage. – Zachary Kniebel Jun 8 '17 at 16:22
  • Its definitely a bug. I am waiting for patch – Nil Pun Jun 8 '17 at 21:04
4

We managed to identify the root cause of our memory leak. With help of MS and Sitecore, memory dump had lots of our controller and services hanging off of Root scope.

By design the sitecore disposes the objects on request end. Given that the controllers injected by Autofac were not compatible with Sitecore controllers, the objects didn't get disposed. As a result our controllers built over time, reached 100% memory limit and app pool got restarted. As a result 500 error.

How to fix? Ask support to provide the patch applicable to your DI.

| improve this answer | |
  • did sitecore provide you with a knowledge base page link or something similar. We are running in exactly the same issue. – marto Oct 11 '17 at 15:56
  • Has anyone got solution for this problem? we are facing the exact same issue. Or is below article help in resolving this? kb.sitecore.net/articles/535948 – PaRsH Oct 17 '17 at 17:39
1

There was a bug fix for this in Sitecore 8.2:

https://github.com/sitecoresupport/Sitecore.Support.166675/releases

It didn't make it into Sitecore 9.0, so ask support for the new fix if you experience similar memory leak issues in v9.

| improve this answer | |
0

The problem is in not registered ISitecoreServiceLocatorScope service when you inherit from the BaseServiceProviderBuilder class.

Try to inherit from the DefaultServiceProviderBuilder class. It launches ServicesScopeConfigurator. I did so, and there were no controller instances in memory.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.