Hi Frans,

I recently upgraded one of my larger web applications from 2.5 to the latest beta and performance has dropped significantly - the memory usage on the production server steadily increases until I have to restart the application. Using v2.5, the memory usage didn't go higher than approximately 500mb (the server has 2 gigs of ram). However, with the latest beta after 4-5 hours all the memory is being consumed by this application.

After running CLR Profiler, it appears that 40% of the memory being used by the application is being used by strings. I seem to remember that 2.6 makes changes to the string-uniquing behaviour inside the DataAccessAdapter...do you think this could have such a drastic affect or am I going down the wrong path?

Jeremy

It should decrease the memory usage by strings due to the uniquing. However, the cache is per adapter.

Do you keep an adapter object alive in your application? Or do you create/dispose the dataaccessadapter after every action? if you keep a dataaccessadapter alive, you keep the cache alive.

Your profiler should show if the strings are referenced by a central object (i.e. all referenced by a collection/adapter)

Currently my adapters live per web request, so my IoC container creates an Adapter instance at the start of each http request and disposes of it when the request has finished.

I don't find CLRProfiler particularly easy to work with - but as far as I can tell the majority of the strings are coming from SqlServerSpecificCreator.CreateObjectName and SqlServerSpecificCreator.CreateFieldName. I'm going to install a better profiler and see if it can produce more useful information.

Jez wrote:

Currently my adapters live per web request, so my IoC container creates an Adapter instance at the start of each http request and disposes of it when the request has finished.

I don't find CLRProfiler particularly easy to work with - but as far as I can tell the majority of the strings are coming from SqlServerSpecificCreator.CreateObjectName and SqlServerSpecificCreator.CreateFieldName. I'm going to install a better profiler and see if it can produce more useful information.

Those are the strings used in the queries, which aren't cached.

You are sure this leak is only in teh latest beta, or did you also see this in earlier betas?

Otis wrote:

Those are the strings used in the queries, which aren't cached.

Ok, that was a red herring then.

Otis wrote:

You are sure this leak is only in teh latest beta, or did you also see this in earlier betas?

Not sure...this app has only ever been used with the latest beta. I'll see if using an older version makes any difference. Unfortunately, this is a bit of a pain to troubleshoot as the problem only appears on our live server (most likely due to the load).

I'm going to add some additional logging to the app to see if I can further isolate the issue...I'll let you know if I make any progress.

Leaks should reveal themselves also in smaller profiles... The memory profiles we did all showed proper cleanups of memory, in fact memory pressure is lower than it was in 2.5, especially during transactions.

If the query strings are kept alive, please check which objects refer to those...

Thinking more about it... if strings created by the sqldbspecific creator are kept in memory, I wonder if the garbage collector runs at all... I mean: those strings are very temporary: created, returned to caller and there they're put into a stringbuilder.

Right, I've done some more investigating and have come up with some interesting results.

First off, it doesn't look like LLBLGen is the problem at all, but I thought you might be interested in my findings nonetheless.

At the same time I upgraded to the latest llblgen beta I also upgraded to the latest CTP of Microsoft's new ASP.NET MVC framework. I'm not sure how familiar you are with ASP.NET MVC, but in order to pass data from the controllers to the views you'd use the ViewData dictionary like so:

public class MyController : Controller {
    private IStudentRepository students = new StudentRepository();

    public ActionResult Index() {
        ViewData["someData"] = students.FindAll();
        return RenderView();
    }
}

It appears to be that anything put into the ViewData dictionary seems to live forever. Clearing the ViewData dictionary in the controller's dispose method seems to relieve the issue.

Thats what I get for using beta software

I'll release a new version of my application later today and fingers crossed the problem will go away

Interesting indeed! Glad it's not our fault

Did you report this to Microsoft? It might be it's a bug in their framework. I don't think you would want to have things live forever in containers in a web framework

v2.6 beta will be released later today btw.

Yeah, I think I'll report it but I'll do some more experiments first just to ensure that I've not done something stupid somewhere

Otis wrote:

v2.6 beta will be released later today btw.

Woohoo