I am profiling while loading my SessionFactory and find that after loading 800+ mapping files Hibernate is using approximately 475MB of heap space. Is this normal?
Is it possible to have the EntityLoaders and SQL strings (which are taking up so much memory) allocated when the particular mappings are first used rather than during SessionFactory initialization?
In general only a small set of the hibernate mappings will be used by each application. The set of mappings used by each application isn't static so I can't just break up my configuration into independent sets of mappings.

Also, this problem got a lot worse after upgrading from Hibernate 3.3.1 to Hibernate 3.5. In Hibernate 3.3.1, the memory usage was 225MB and in 3.5 it has increased to 475MB!

thanks, I didn't test it with 800 mapping files.
It would be nice if you could post your findings, possibly attaching some stats from your profiler, to the developer mailing list?
"hibernate-dev" is the appropriate place: http://hibernate.org/community/mailinglists

There's some work going on about this in Hibernate4, the first alpha was just released so this information would be useful and with a good timing

Hi!

Some time ago we move from hibernate 3.3.2 to hibernate 3.6 and we realized that the sessionFactory is consuming much more memory now.
I´m suscribed to the developement list (I've collaboreated on envers component) and I don't remember any discussion about this...
I'm going to make some analisys and then try to send the results to the list. If you have any suspect about where to point the analisys, please let me know.

Regards. Hernán.

Hi Hernán,
that would be very interesting indeed!
But please could you work on the Hibernate 4.x series? that's where we are going to push innovations, 3.6 is in maintenance (bug fix only).
I also believe that some of the design choices in Hibernate4 where tackling some memory issues, so you would avoid some duplicate work.

Regards

Hi Sanne, thanks for your reply!

I can make some tests on hibernate 4.x series but the main issue i'm facing is that our system is already productive and the memory comsumption is in the current release.
Moving the whole architecture to the 4.x series is not a short term option because it is on beta releases (and we're using spring framework and we would need a spring-hibernate4.x compatible version).
I guess if maybe I could try to find a workaround on 3.6.x series and then come back with hibernate team to validate it...

Again, thanks a lot!

Regards. Hernán.

We are worried about similar issues with the following setup:

• Hibernate 3.3.1
• 5 persistence-units
• 286 entities (amongst 3 applications: 230, 22, 34 entities per application respectively)

That makes a total of about 1400 mapped entities, each entity being mapped in each persistence-unit.

The profiler shows that Hibernate classes take about 250 MB (a similar memory usage to the one of Hernán's setup), but with almost 2 times more entities. But still, 250 MB is about 20% of the application server total memory usage: quite a lot only for mappings. So we are also interested by reducing the Hibernate mapping memory usage (and having dynamic datasource selection on a single SessionFactoryImpl as suggested by Jeff Nadeau is not applicable: we need the cache).

Most of the memory usage is in the SessionFactoryImpl (about 20 MB per instance). The average SessionFactoryImpl contains:

• QueryCachePlan : about 0-8 MB (varies)
• EventListeners: about 6 MB (stable)
• other smaller objects

99% of the EventListeners memory usage is held by org.hibernate.validator.event.ValidateEventListener, which itself holds a EJB3ReflectionManager which holds about 4.8 MB.

So we turned Hibernate validation off by using Pascal Thivent's tips in the persistence.xml file :

This reduced Hibernate mappings memory usage by about 30%. Of course, we have no more Hibernate validation on inserts and updates: that's the price to pay...

We didn't check if the memory increases in 3.6.x and in 4.x as reported by Hernán, but disabling Hibernate validation could probably be used.

Hernán: do you have the details about the top memory usage classes ?

Kindly regards,

Julien

Hi Julien,
did you consider trying Hibernate 4? Even if the memory taken by a single SessionFactory might be a bit higher, you'll cut the cost for the model by five as you can reuse them.
TBH I'm not sure if this reuse is supported *yet*, I'll check for that, but even if it's not it will be soon, so you could start testing it you app on Hibernate 4.

Also we don't have a test having so many entities, it would be nice if someone could contribute one; that's the most practical way to make sure such a problem is solved, and stays solved in future versions.

Hi Sanne,

We are not considering to go on Hibernate 4 yet (there is still a lot of old JDO code to migrate before).
But we may consider it (cutting down the memory usage by the number of persistence-units would be great: we are on a machine where memory cost a lot).

BTW, I miscounted the number of entities: there are 1400 entities in total, not 2500. But it's still a lot.

BTW, there are two feature request with respect to the memory usage in SessionFactory:

• HHH-6794: sharing ReflectionManager amongst all persistence-units
• HHH-4857: sharing the whole Configuration amongst all persistence-units

Julien