Hi,

I have been trying to pin down a memory leak in my wep app these past few weeks - and digging into my application with WinDbg revealed something fishy with the NHibernate SessionFactory in memory.

Context: It's a standard ASP.NET application using NHibernate 2.0.0.4000. I only use 1 SessionFactory since that seems to be the defacto standard - and my Sessions are disposed using something along the lines of Ayende's unit of work.

I have been analyzing a memory dump of a ~800mb .NET heap to figure out why it kept growing. One thing I found was around 1.9 million NHibernate.SqlCommand.SqlStrings and ~90000 HQLQueryPlans

MT Count TotalSize Class Name 0f7fb3e4 92382 3695280 NHibernate.Engine.Query.HQLQueryPlan 0eafd714 1939496 31031936 NHibernate.SqlCommand.SqlString

Digging down into the roots of one of these SqlStrings revealed that it was being stored in the query plan cache in the SessionFactoryImpl:

067016bc(NHibernate.Impl.SessionFactoryImpl)-> 06702470(NHibernate.Engine.Query.QueryPlanCache)-> 06703050(NHibernate.Util.SoftLimitMRUCache)-> 067030a0(NHibernate.Util.LRUMap)-> 067030d4(System.Collections.Hashtable)-> 0c8af170(System.Collections.Hashtable+bucket[])-> 02e30ccc(NHibernate.Util.SequencedHashMap+Entry)-> 02e2efdc(NHibernate.Engine.Query.HQLQueryPlan)-> 02e2f1dc(System.Object[])-> 02e2f1f0(NHibernate.Hql.Classic.QueryTranslator)-> 02e2f4c4(System.Collections.Generic.List`1 [[NHibernate.SqlCommand.SqlString, NHibernate]])

I checked and there was exactly 1 instance of the SessionFactoryImpl in the dump - checking it's size took a few hours, which is not surprising:

sizeof(067016bc) = 716798348 bytes (NHibernate.Impl.SessionFactoryImpl)

That is one big SessionFactory :-) Still tracking the SqlString I explored the query plan cache and ended up at the LRUMap, which according to the code is supposed to keep the last (128 in this case) most recently used queries in cache. The LRUMap looked like this:

Name: NHibernate.Util.LRUMap Fields: MT Field Offset Type VT Attr Value Name 0f76a554 4000e40 c ...ncedHashMap+Entry 0 instance 067030bc _sentinel 79101fe4 4000e41 10 ...ections.Hashtable 0 instance 067030d4 _entries 790ffcc8 4000e42 4 System.Int64 1 instance 104874 _modCount 79102290 4000e51 14 System.Int32 1 instance 128 maximumSize

That is, 128 max size. Examining the hashtable called Entries in the LRUMap revealed this though (some lines removed):

Name: System.Collections.Hashtable Size: 56(0x38) bytes Fields: MT Field Offset Type VT Attr Value Name 7912d9bc 400092b 4 ...ashtable+bucket[] 0 instance 0c8af170 buckets 79102290 400092c 1c System.Int32 1 instance 92382 count 79102290 400092d 20 System.Int32 1 instance 35331 occupancy 79102290 400092e 24 System.Int32 1 instance 112634 loadsize 79102290 4000930 2c System.Int32 1 instance 92391 version

Supposedly it contains ~90000 objects (count field) and a big (reachable) object size: sizeof(067030d4) = 716798264 bytes (System.Collections.Hashtable)

I have examined the LRUMap source and can't find any glaring mistakes, I looked at the LRUMapFixture, which didn't seem to contain any tests that verify that it actually is limited to it's max size. However, I made a unit test in my own test project:

[Test] public void LRUTest() { LRUMap map = new LRUMap(10);

for (int i = 0; i < 20000; i++) map.Add("str" + i, i);

Assert.AreEqual(10, map.Count); }

and this passed just fine.

Now this is where I am stumped, somehow my application manages to squeeze all these objects into the cache, but I haven't been able to reproduce it with simple tests.

Does anyone have an idea what could be the culprit?