There's also a theory of some H2 buffers that are shrunk as a result of runtime memory load - are you familiar with such behavior of H2?
Thanks for your help. On Monday, May 1, 2017 at 10:37:46 AM UTC+3, Avi Shefi wrote: > > Attached are a few consecutive stack traces of the thread that performs > the slow queries. > The queries that are used while taking these stack traces are recursive > queries using CTE (common table expressions) using H2's syntax: > http://www.h2database.com/html/advanced.html#recursive_queries > While the queries can be improved and optimized, this still doesn't > account for the difference between embedded H2 running standalone which > takes ~2 minutes and embedded H2 running within a Maven multi-module build > which takes ~1 hour for the same exact operations. > > I think there's an issue with how H2 is searching the pages inside the > memory, notice how most traces are in the binarySearch and comparison > operations. > I am also investigating a possible issue with a /dev/urandom seeding > problem, currently I'm using the following JVM setting without any results: > -Djava.security.egd=file:/dev/./urandom > > > I will keep looking into this. > > > On Saturday, April 29, 2017 at 11:46:34 PM UTC+3, Noel Grandin wrote: >> >> Sorry, then I'm out of ideas. I've run multiple H2 instances in the same >> VM without slowdown, so I don't know what is going on here. >> >> >> > -- 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 https://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
