NH-3530 - memory when using default_batch_fetch_size

[nhibernate-bot]

Kris Desmadryl created an issue — 12th September 2013, 20:45:09:

As since NH3+ setting the default_batch_fetch_size to something has very bad impact on memory as soon the SessionFactory is created. I'm using 3 session factories in an web app (I'm accessing 3 db's). It uses 250MB without the setting but 750MB (default_batch_fetch_size=16) with the setting. When I switch back to 2.1.2 the problem is gone. My webserver recycles because the private memory is reached!

grtz,
Kris

---

Filip Duyck added a comment — 13th September 2013, 7:29:56:

In addition to what Kris said, I'd like to share some results from our dotTrace profiling session.

Performance trace can be seen at -- notice how in NHibernate 3, EntityLoader..ctor is called about 10x as much as in 2.1.2 (even though the calls to BatchingEntityLoader.CreateBatchingEntityLoader are more or less of the same order of magnitude).

We also did memory profiling which showed similar results, which you can see at . In this trace, you can see that BatchingEntityLoader.CreateBatchingEntityLoader creates many, many more objects in 3.3.3 than it did in 2.1.2.

I have looked at the code of both methods but I can't really identify a change. Our setup for NH2.1.2 and NH3.3.3 use virtually the same configuration. The problem is, as Kris mentioned, amplified by the fact that we have defaultbatch_fetchsize set to 16 which causes more looping inside the CreateBatchingEntityLoader method, but this setting is the same during 2.1.2 and 3.3.3 testing.

Can anyone from the NH team shed a light on this? Especially the memory problem is killing us in production.

---

Filip Duyck added a comment — 16th July 2014, 13:13:52:

It's been almost a year. Is anyone ever going to look at this?

[hazzik]

It seems like this is the regression of following: a35aaa6

[LeMaciek]

We wanted to start using default_batch_fetch_size, but after enabling it, our tests started to throw OutOfMememory exceptions. Investigation led me to this issue... This is the difference in memory usage in our case, we are using NH 5.2.3

with default_batch_fetch_size=20...

• alocations
  
• memory
  

without

• allocations
  
• memory
  

Unfortunately this issue prevents us from using this feature...

[fredericDelaporte]

You may use instead discrete batch-size settings (hbm attributes) on classes and collections requiring it, instead of enabling it for all of them through default_batch_fetch_size. This will reduce the memory impact, but it is also more work on the developer side.
That is of course a work-around. This feature should not have such a memory impact.

[maca88]

The memory impact is due to the BatchingEntityLoader creating many EntityLoader instances which have pre-built sql statements for fetching the entity for different batch sizes. When batch fetch size 20 is used the BatchingEntityLoader will create eleven EntityLoader instances with batch sizes: 20, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, which is the reason for the high memory usage. One way to solve the issue is to port HHH-7746 which contains an additional setting hibernate.batch_fetch_style that affect how batching of entities is done. By using BatchFetchStyle .DYNAMIC the memory usage would not be affected as the sql statements are created dynamically, which would solve the OutOfMemoryException for those that have a limited amount of memory, but it will use more cpu due to dynamic sql generation.

[fredericDelaporte]

Related: #1904, which would be an intermediate solution, maybe insufficient for some applications (if they usually end up using most loaders during their lifetime).

[hazzik]

Additional details in #2427