4:28 a.m.
Hi Andrej,
On Sun, May 6, 2018 at 11:03 PM, Andrej Golovnin <andrej.golovnin(a)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
8:52 a.m.
New subject: SingleTableEntityPersister memory footprint in 5.3
Hi Guillaume,
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.
I have also a lot of tables with high number of columns. The biggest
one has 254 columns. So what?
If we can come up with some patches, it would be nice if you could test them
with your workload.
When you are ready, sent me links to the pull requests and I'll test them.
Best regards,
Andrej Golovnin
9:37 a.m.
New subject: SingleTableEntityPersister memory footprint in 5.3
On Mon, May 7, 2018 at 2:52 PM, Andrej Golovnin <andrej.golovnin(a)gmail.com>
wrote:
> 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.
I have also a lot of tables with high number of columns. The biggest
one has 254 columns. So what?
So it's not the average 20 columns table.
Not saying it's not a case we should be grateful with.
--
Guillaume
2:11 a.m.
New subject: SingleTableEntityPersister memory footprint in 5.3
Hi Guillaume,
> > 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.
>
> I have also a lot of tables with high number of columns. The biggest
> one has 254 columns. So what?
So it's not the average 20 columns table.
Not saying it's not a case we should be grateful with.
--
Guillaume
What you should really do is write a generator that would generate
models with a configurable number of entities, abstract entities,
mapped supper-classes, embeddables, relationships, fields, and so on.
You could integrate it into the build process to verify memory
consumption after every change in the Hibernate code. This would allow
you to find problems before you ship a new version of Hibernate.
It should be a good job for a student. :-)
Best regards,
Andrej Golovnin
2178
days inactive
2179
days old
3 comments
2 participants
participants (2)
-
Andrej Golovnin -
Guillaume Smet