[hibernate-dev] SingleTableEntityPersister memory footprint in 5.3

Sanne Grinovero sanne at hibernate.org
Tue May 8 05:42:32 EDT 2018


Hi Andrej,

you're right, I found the most interesting email from you now (reading
the whole thread) :
 - http://lists.jboss.org/pipermail/hibernate-dev/2012-May/008410.html

I'm not sure why the discussion stopped, I'm sorry.
Let's try to fix it this time, to make sure of that we need a JIRA.
Someone created one? Guillaume?

summary:
 - problem introduced by https://hibernate.atlassian.net/browse/HHH-4546
 - great results applying Andrej's
https://github.com/golovnin/hibernate-orm/commit/1cc8a23d1d5f4079fb090cca63a44e8660f05c7f
 - the patch could be improved today with Java8
   -- I'd like to have some degree of upfront validation at boostrap still
   -- hopefully explore an array based structure
   -- do not extend CHM
   -- ideally have no read barriers at all at runtime

Thanks,
Sanne


On 6 May 2018 at 22:03, Andrej Golovnin <andrej.golovnin at gmail.com> wrote:
> Hi,
>
>> 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.
>
>> but it
>> would be nice to be more gentle with this type of configuration. I don't
>> think it's something new to 5.3 though as it's not the first time we have
>> this type of reports.
>>
>>> From my observations, the problem mostly comes from:
>> LegacyBatchingEntityLoader
>> \_ loaders - EntityLoader
>>     \_ staticLoadQuery - EntityLoadQueryDetails
>>         \_ rootReturn - EntityReturnImpl
>>
>> The largest LegacyBatchingEntityLoader I have in the dump takes more than 2
>> MB.
>>
>> Keep in mind that with a batch size of 50, we have 13 EntityLoaders for
>> batch sizes of 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 20 and 50, each loader
>> taking ~ 200 KB.
>>
>> We discussed some ideas yesterday with Steve.
>
> 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.
>
> 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.
>
> Best regards,
> Andrej Golovnin



More information about the hibernate-dev mailing list