thank you for the test case, fix is in master​
--
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, se
Thank you sir!
--
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegr
Hi
I run attached test at AWS r3.8xlarge instance (32 core, 256 GB RAM). The
test has 100 threads which perform inserts into one simple table
*Test #1 - TCP server*
dbUrl =
"jdbc:h2:tcp://localhost:9002/nioMemFS:db;DB_CLOSE_DELAY=-1;MULTI_THREADED=1"
At the very beginning I get 25K inserts/sec
Test attached
--
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegro
Sorry, that's not something I can analyze myself. I suggest you hook up a
profiler like visualvm and take CPU sampling profiles of both cases. Then
we could compare them to see what the problem is. Also take a heap dump of
the tcp case so we can see if there is a memory leak.
On Sun, 11 Dec 2016 at
Please see flight recordings taken from TCP:
1. after 30 mins run:
https://drive.google.com/file/d/0BzUtLq_vDgHWT3dadkk5ajBBZms/view?usp=sharing
2. after server restart:
https://drive.google.com/file/d/0BzUtLq_vDgHWWEd5SjJfT3pydXc/view?usp=sharing
On Sunday, December 11, 2016 at 5:37:41 PM
thanks.
looks like we are bottlenecking on the locking on the undoLog object in
TransactionStore, particularly in the commit() method.
I see a comment there
// TODO could synchronize on blocks (100 at a time or so)
which means perhaps Thomas had some ideas how this could be improved.
Bit late
How can I select pageStore in 1.4? I haven't found the option in the docs.
If I've written the file with 1.3, perhaps 1.4 will find an engine setting
in the db?
So I understand, is getPage() fetching from disk? Using a profiler,
getPage() is the top hot-spot. I'm not sure why the profiles don't
Not getting far with 1.4. I realized I could use PageStore by setting
MVCC=FALSE, but the performance is pathologically slow, for me. My test,
which takes 28 seconds in 1.3, has run for 20 minutes without completing,
with 1.4.
I rebuilt the database table, to be sure it wasn't a 1.3 vs. 1.4 da
(a) you need to use MV_STORE=FALSE to select PageStore in 1.4​
(b) we have not done any work on making MULTI_THREADED work better with
PageStore, nor do we intend to.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group
In fact this test shows 3 problems:
1. Bad scalabity even with embedded server: H2 can't use more then 10% of
PU due to locking
2. Slow TCP exchange even with localhost
3. Degradation of TCP server performance, probably due to a leak
I would very appreciate your input for each of the problems
11 matches
Mail list logo