The ViewState, the SessionPageStatePersister and the Memory Leak

 

We recently encountered frequent performance degradation due to high memory utilization in our ASP.NET application.  I won’t go into the details of how we actually identified the source of the leak, unless there’s a considerable public outcry for such an explanation.  Suffice it to say that we were able to track it down with Windbg and a few essential blog posts (below).  In this case what we learned is more noteworthy than how we learned it. 

What we found to be the cause of the memory leak was more or less a classic mistake, with a twist.  Deep in the bowels of a fairly complex page, nested several UserControls deep there lived a DropDownList control which was being assigned to ViewState.  That’s not a particularly good idea, but ordinarily that wouldn’t cause a memory leak, although it would create considerable ViewState bloat (if the DropDownList is even serializable which I never confirmed).  ViewState is serialized into gobbledygook and stuffed into a hidden field.  However, in this particular page ViewState persistence was being overridden to use the SessionPageStatePersister.   The twist being that the serialized ViewState gobbledygook is stuffed into Session instead of a hidden field, or so I assumed. 

After cracking open the SessionPageStatePersister with Reflector and comparing it to the HiddenFieldPageStatePersister I discovered a significant difference.  The SessionPageStatePersister wasn’t serializing ViewState, it was a straight variable assignment.  Therefore Session wasn’t storing a large string of serialized text, similar to what you’d find in the hidden field, instead it held a reference to the objects in ViewState.  Further, since in this case Session was ‘in-memory’, that meant that the DropDownList and its graph (i.e. parents and other references) were being held in memory for the duration of the Session.  I think you can see where this is going.

The confluence of ViewState misuse, a misunderstanding about the behavior of SessionPageStatePersister and the use of in-Memory Session conspired to create a troublesome memory leak.  Hopefully those of you using a similar combination  will heed our mishap and be wiser for it.

Identifying Memory Leak With Process Explorer And Windbg

Tess Ferrandez

Comments

  1. AnonymousSeptember 23, 2011 at 2:57 AM

    The procedure you used to find this would have been good as I suspect a similar problem in an production application we have causing problems now.

    ReplyDelete
  2. nappisiteSeptember 23, 2011 at 11:36 AM

    Its been a while and I'm a novice with Windbg but I do recall eventually finding a lot of references to one particular page and usercontrol in memory. After closer inspection of the usercontrol I found the dropdownlist being stuffed into viewstate. In retrospect a quicker option would have been to switch back to HiddenFieldPageStatePersister, which would force serialization, and any object like the dropdownlist (or its graph) that's not serializable would throw an exception and help pinpoint the issue. You might try that first, if not, refer to Tess Fernandez's blog.

    ReplyDelete

Post a Comment

Popular posts from this blog

RIF Notes #4

“It is better to be feared than loved, if you cannot be both” – Machiavelli “A well-stated problem is half-solved” – John Dewey jsFiddle - Cool javascript testing tool Modernizr - Modernizr is a small and simple JavaScript library that helps you take advantage of emerging web technologies (CSS3, HTML 5) while still maintaining a fine level of control over older browsers that may not yet support these new technologies. Why We’re Going With HTML(5) Instead Of Silverlight – More on the debate between Silverlight and HTML5.  A year ago I would have said Silverlight, hands down, for LOB development, now its not quite as clear.  At least not if your users need to access your apps from their iPads and Droids. Bootstrapped, Profitable, & Proud: Braintree – Braintree Payment Technologies was the first company I contacted when I first started investigating credit card tokenization a few years back.  Remote Desktop Protocol (RDP) -- Technical Analysis - Matt found this article, for an
Read more

RIF Notes #42

“In practice, problems are delegated but the power to address them is not.” - Maslach & Leiter Building the Object Model You Want with Entity Framework How you can improve your SQL with code analysis in SQL Prompt A growing number of young Americans are leaving desk jobs to farm – This is a head scratcher. Macro trends in the tech industry Technology Radar Vol 17 Essential .NET - C# 7.0: Tuples Explained – “What many folks didn’t realize when it was first introduced is that the new C# 7.0 tuple all but replaces anonymous types—and provides additional functionality.” Editor's Note – Misprint – “Any IT manager can regale you with stories of undiagnosable printer failures, but even at the home-office level printing is an exercise in fail” .NET Standard - Demystifying .NET Core and .NET Standard Devops - Continuous Data Migration Using Visual Studio and TFS
Read more

The greatest trick the AI ever pulled was convincing the world it wasn't THAT intelligent

Just listened to The AI Dilemma and it definitely elaborated on and articulated some of my own concerns, as did the news of OpenAI plugins. The synthesis of concern is: AI doesn't need to be that powerful to be destructive and destabilizing (e.g. social media algorithms) to people and society. These new LLM's are already much more powerful than social media algorithms. Many of the new LLM capabilities are emergent and poorly understood. The experts designing these systems don't fully understand them, and some of whom are already worried about what they've created. LLM's are being rapidly and recklessly deployed very broadly across society, in an arms race. The strongest argument against worry is that these LLM's aren't really intelligent, are really just a super-autocomplete that enables automating mundane tasks via natural language. But I don't think any of the companies developing or deploying these things are arguing that. Even if they were, see #1 &
Read more