Ok, after analyzing what's inside that 600M heap usage, I found where the problem is. Around 550M are occupied by the view metadata, org.h2.table.TableView. Many of them retained 800k - 1M heap for a view. I don't know if it's because it uses immutable objects or what. For our 2500+ views, this is really heavy load. It seems that many views are automatically expanded to "H2 suitable form", and a view definition could occupy 80-100k size. But 1M for a view metadata still sounds scary. I know our situation is not normal, but it's a real-life application scenario. May I suggest h2 engine to improve this view metadata memory usage at your convenient schedule? Thanks a lot.
On Thursday, November 21, 2013 11:28:17 AM UTC-5, Noel Grandin wrote: > On Thu, Nov 21, 2013 at 5:51 PM, Min Huang <[email protected]<javascript:>> > wrote: > > Is it possible to analyze what's in that 600MB of strings? To me, it's > more > > like the whole database is loaded as a in-memory database?! or more than > > that? And if it's the cache, it should be controllable and not prevent > the > > database loading when the heap memory is limited. What do you think? > > > > No, it really is just metadata, none of that is actual row data. > I'm afraid H2 is optimised for more normal use-cases, which means that > our metadata has a lot of fields. > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
