Tmr / h2database

Automatically exported from code.google.com/p/h2database
0 stars 0 forks source link

multithreading #571

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I noticed there is an experimental feature for multithreading, is there any 
chance of that being stabilized in the near future? I tested this feature at 
one point but ran into query issues immediately afterwards (something about a 
"lock failure" or "lock timeout"?).

As well, our database can get large at times, and we like to run the entire 
database in ram. This means when we start H2 it loads the entire 30 gig (or 
whatever) file up first, which can take 20+ minutes before it's all ready. I 
noticed in the process viewer that the CPU barely moves during this import 
stage, and the disk usage sometimes spikes for a bit, but then large periods of 
no activity, then another spike etc.

Is there anything that can be done to multithread this initial load operation? 
We have 40 cores just idling during this process (none of our apps can run 
without H2 up and running), the disk reads are not maxing out either.

This is definitely just a nice-to-have (not a bug), but multithreading all 
around would greatly increase the utility of this wonderful database!

Original issue reported on code.google.com by localde...@gmail.com on 8 Jul 2014 at 7:20

GoogleCodeExporter commented 9 years ago
For questions, please use the Google Group.

> is there any chance of that being stabilized in the near future?

Sure, that's the plan for version 1.4.x

> we like to run the entire database in ram.

With version 1.4, off-heap memory can be used. Right now it's "wired" into the 
database engine, but I'm quite sure this is something others are also 
interested in.

Performance of import: that's a separate topic. This should be analyzed using a 
profiler (see the docs). I wouldn't use multi-threading until you are sure 
there is no other (unrelated) problem.

Original comment by thomas.t...@gmail.com on 9 Jul 2014 at 6:22