Hi, I think the problem is that H2 synchronizes on the table. I will add a feature request for "Improve concurrency for in-memory database operations", however this item is not a high priority for me, sorry. I guess you should use in-memory data structures that support more concurrency (concurrent hash map and so on).
Regards, Thomas On Fri, Sep 18, 2009 at 11:28 PM, GregB <[email protected]> wrote: > > Eric, > > Thanks for the suggestion. I am not sure about the MULTI_THREADED > setting for production use, but I gave it a try in the benchmark. > > I also reworked the benchmark so that the only action in the worker > threads is the DB insert. The results are the time in milliseconds to > insert 100,000 rows where each thread has a dedicated table. The jvm > was allowed to warm up and test were run multiple times then averaged. > > Original DB URL > 1 thread - 2725 > 2 thread - 2838 > 4 thread - 2796 > 8 thread - 2761 > > MULTI_THREADED DB URL > 1 thread - 2702 > 2 thread - 2041 > 4 thread - 1447 > 8 thread - 1667 > > The results look better using MULTI_THREADED but the 8 thread was > slower than the 4 thread on every test run. This was unexpected as I > am testing on a true 8 core server, no hyperthreading. Also, running > MULTI_THREADED where multiple threads insert into the same table did > not increase performance at all. > > To check my benchmark I replaced the DB insert with a random number > generator just to see best case scenario for scaling. > 1 thread - 4374 > 2 thread - 2632 > 4 thread - 1471 > 8 thread - 1158 > > > It looks like there is no easy way to increase insert performance into > a single table. You can use multiple threads - but not too many - > along with the MULTI_THREADED setting along with multiple tables, but > this make queries that much more difficult to implement (could views > help with this?). > > Any other ideas? > > > Thanks, > > Greg > > > > > On Sep 18, 3:35 pm, Eric Faulhaber <[email protected]> wrote: >> Greg, >> >> Try this: >> >> jdbc:h2:mem:testdb;MULTI_THREADED=1 >> >> Any improvement in the multi-threaded tests? >> >> Thanks, >> Eric >> >> On Sep 18, 11:43 am, GregB <[email protected]> wrote: >> >> >> >> > First off thanks Thomas for all the great work - after switching from >> > Derby to H2 everything runs twice as fast! >> >> > Still I find that we are limited by insert performance. I wrote up a >> > small test to insert 100,000 rows and found - >> > with single thread and single table - 11,000 rows per second >> > with 8 threads and single table - 14,000 rows per second >> > with 8 threads and 8 tables - 14,000 rows per second >> >> > Tests were done on an 8 core Linux server with an embedded in-memory >> > database. With the multi thread tests CPU usage was around 30%-40% >> > per for each core. The db url is jdbc:h2:mem:testdb. >> >> > My biggest surprise was that the 8 table test was no faster. I would >> > expect with no contention for table locks this would scale better. Is >> > there any recommended configuration to allow better insert >> > performance? >> >> > Thanks, >> >> > Greg > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/h2-database?hl=en -~----------~----~----~----~------~----~------~--~---
