[hibernate-dev] SingleTableEntityPersister memory footprint in 5.3

[Guillaume Smet]

Hi Andrej,

On Sun, May 6, 2018 at 11:03 PM, Andrej Golovnin <andrej.golovnin at gmail.com>
wrote:

> > So, I analyzed the dumps yesterday evening. The problem is real, meaning
> > his SessionFactory is consuming more than 1GB of memory for 600+ tables,
> > some with a lot of attributes. So for sure, the model is a big one, …
>
> No, it is still a small one. I work on a project with 2145 tables. And the
> SessionFactory
> consumes on production systems ca 300-400MB with Hibernate 5.2. I haven’t
> tested the project with Hibernate 5.3. But I doubt it would consume more
> memory.
> Except the Hibernate team broke something again
>

It's not only the number of tables but also the number of columns per
table. The table I take as an example in my tests has 200+ columns, which
definitely doesn't help.

And I have discussed it with the Hibernate team 6 years ago:
>
> http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008341.html
>
> And my suggestion to create things lazily were ignored/rejected.
> And I have ignored the opinion of the Hibernate team and implemented
> my suggestions in my version of Hibernate and saved a lot of memory
> in my project.
>

See, we are improving.

I see a lot of conjectures in the thread but we should have analyzed the
memory dump more closely to understand exactly what was going on.

I think it would have led to a different outcome.


> Btw. please ask the user whether he has a lot of abstract entity classes.
> When yes, then ask him if it would be possible to convert this entity
> classes
> to mapped supper-classes. This may help to reduce memory consumption too.
>

Yeah, first, I would like to see if we can improve the situation by
changing the ORM code. I'm more for us improving the situation globally
rather than tweaking the model of each user.

If we can come up with some patches, it would be nice if you could test
them with your workload.

-- 
Guillaume