Re: [h2] MVStore with MVCC performance degradation

Hi Thomas, We am getting the "Missing lob entry ... " exception quite frequently on concurrent update and read of a row. My connection URL is as follows: "jdbc:h2:/data/database;MVCC=true;CACHE_SIZE=2621440;PAGE_SIZE=4096;ALLOW_LITERALS=NUMBERS;LOCK_TIMEOUT=1;" We were on 1.3.176, but updati

Re: [h2] MVStore with MVCC performance degradation

All tests pass now except on related to concurrency testing, and I haven't analyzed that one yet. The performance is definitely in the acceptable range, but I haven't been able to do a direct comparison of run times. On Thursday, August 6, 2015 at 11:02:45 PM UTC-7, Noel Grandin wrote: > > Sorr

Re: [h2] MVStore with MVCC performance degradation

Sorry this took so long, I have pushed a performance fix for the metadata query in your trace. -- 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+unsubsc

Re: [h2] MVStore with MVCC performance degradation

I had emailed you the trace file, but haven't got a reply, so here it is on Google drive shared to you: https://drive.google.com/open?id=0B7fRq__lUQbCRXJIM2NCVVdpZGM On Thursday, July 30, 2015 at 6:21:12 AM UTC-7, Noel Grandin wrote: > > > > On 2015-07-28 06:10 PM, Wes Clark wrote: > > Link to

Re: [h2] MVStore with MVCC performance degradation

On 2015-07-28 06:10 PM, Wes Clark wrote: Link to trace file: https://drive.google.com/open?id=0B7fRq__lUQbCRXJIM2NCVVdpZGM Can't access this. -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving

Re: [h2] MVStore with MVCC performance degradation

Link to trace file: https://drive.google.com/open?id=0B7fRq__lUQbCRXJIM2NCVVdpZGM This is the trace from running one test class with four test methods. Serious DDL and catalog queries going on. Run with JDBC URL options ";AUTO_SERVER=true;mv_store=false;mvcc=false;TRACE_LEVEL_FILE=3;". Timi

Re: [h2] MVStore with MVCC performance degradation

On 2015-07-28 01:42 AM, Wes Clark wrote: I build a new jar (twice), and reran the offending suite, and the performance problem was still evident. Should I get another trace? Yeah, let's see what it looks like now. -- You received this message because you are subscribed to the Google Groups

Re: [h2] MVStore with MVCC performance degradation

I build a new jar (twice), and reran the offending suite, and the performance problem was still evident. Should I get another trace? On Thursday, July 23, 2015 at 9:36:39 AM UTC-7, Wes Clark wrote: > > Wow. Great. So I'll assume I would grab the latest nightly build. > > On Thursday, July 23,

Re: [h2] MVStore with MVCC performance degradation

Wow. Great. So I'll assume I would grab the latest nightly build. On Thursday, July 23, 2015 at 12:46:40 AM UTC-7, Noel Grandin wrote: > > HI > > I have pushed a fix for this - this particular query should be about 10x > faster now. > > Regards, Noel. > > -- You received this message becau

Re: [h2] MVStore with MVCC performance degradation

HI I have pushed a fix for this - this particular query should be about 10x faster now. Regards, Noel. -- 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-datab

Re: [h2] MVStore with MVCC performance degradation

Is running in three times a bug? I traced the same tests against both versions, so our code is the same. On Thursday, July 16, 2015 at 11:11:12 PM UTC-7, Thomas Mueller wrote: > > Hi, > > Thanks for the new trace file. The same query is run. It also takes around > 3 seconds. 3 seconds is very s

Re: [h2] MVStore with MVCC performance degradation

Hi, Thanks for the new trace file. The same query is run. It also takes around 3 seconds. 3 seconds is very slow for such a query, so I think this needs to be fixed. In the previous (version 1.3.x / 1.4.x) traces, the same query is run, but run 3 times, and not just once. That's why it takes 10 se

Re: [h2] MVStore with MVCC performance degradation

I sent you a trace of the same processes, but this time on H2 1.2, where the metadata queries run so much faster. On Thu, Jul 16, 2015 at 10:17 AM, Wes Clark wrote: > I agree the problem is not related to MVCC or MVStore. We are still > running on version 1.2.147 of H2, and that version does no

Re: [h2] MVStore with MVCC performance degradation

I agree the problem is not related to MVCC or MVStore. We are still running on version 1.2.147 of H2, and that version does not exhibit the problem. What is different in that version? Can I send you a trace from that version? This is blocking our move to the latest version of H2. Perhaps

[h2] MVStore with MVCC performance degradation

Hi, Sorry for the delay. So, as far as I see, it is still slow even if the MVStore and MVCC are both disabled. Is this what you see as well? With MVStore + MVCC: 105 seconds Without MVStore + MVCC: 99 seconds I think it doesn't matter if you use an old version of H2, it would also be slow. So in

Re: [h2] MVStore with MVCC performance degradation

Ping. On Thursday, July 9, 2015 at 3:54:02 PM UTC-7, Wes Clark wrote: > > I just sent you an email with a link. Please confirm you got it. > > On Wednesday, July 8, 2015 at 10:44:10 PM UTC-7, Thomas Mueller wrote: >> >> Hi, >> >> Yes, that makes sense. I can reproduce the problem with a simple te

Re: [h2] MVStore with MVCC performance degradation

I just sent you an email with a link. Please confirm you got it. On Wednesday, July 8, 2015 at 10:44:10 PM UTC-7, Thomas Mueller wrote: > > Hi, > > Yes, that makes sense. I can reproduce the problem with a simple test case > (that creates many tables and indexes). I have an idea how this could b

Re: [h2] MVStore with MVCC performance degradation

Hi, Yes, that makes sense. I can reproduce the problem with a simple test case (that creates many tables and indexes). I have an idea how this could be solved by changing the database metadata code (MetaTable.java), but it is a bit complicated. Just to confirm that this is not a MVStore or MVCC p

Re: [h2] MVStore with MVCC performance degradation

select count(*) from INFORMATION_SCHEMA.TABLES; COUNT(*) 1713(1 row, 34 ms) select count(*) from INFORMATION_SCHEMA.INDEXES; COUNT(*)

[h2] MVStore with MVCC performance degradation

Hi, You first indicate that the query can be sped by taking into account the > schema name. > I'm sorry! Yes, first I thought changing the query would help, but then I found out there is no easy way to do that in this case. Even adding the schema name as a condition will not help. That is, if you

Re: [h2] MVStore with MVCC performance degradation

You first indicate that the query can be sped by taking into account the schema name. (We leave the user id null or blank in the connection URL.) Later you indicate I should change the metadata, for example to use materialized metadata tables. What is the simplest way to make this query eff

Re: [h2] MVStore with MVCC performance degradation

Hi, Thanks! I combined the files and run the ConvertTraceFile tool. The *.sql file contains statistics about statements that were run. More than 80% of the time was spent in custom database metadata queries (reading the table names, column names and so on). The queries don't take into account the

Re: [h2] MVStore with MVCC performance degradation

(Sent as a separate private email to thomas.tom.muel...@gmail.com.) Here is the trace files that I hope let you see why the newer version of H2 can be much slower that the old one. I ran a suite of four or five test classes with various test methods from the suite that I mentioned times ou

Re: [h2] MVStore with MVCC performance degradation

Nevermind. You were obviously referring to the perf issue. Will send you the trace. On Mon, Jun 29, 2015 at 9:51 AM, Wes Clark wrote: > Do you want to focus on the missing LOB problem or the performance > slowdown for this trace? > > On Saturday, June 27, 2015 at 4:08:05 AM UTC-7, Thomas Muell

Re: [h2] MVStore with MVCC performance degradation

Do you want to focus on the missing LOB problem or the performance slowdown for this trace? On Saturday, June 27, 2015 at 4:08:05 AM UTC-7, Thomas Mueller wrote: > > Hi, > > Yes, could you append ";trace_level_file=3" to the database URL and send > me the .trace.db file(s)? > > Regards, > Thomas

Re: [h2] MVStore with MVCC performance degradation

Hi, Yes, could you append ";trace_level_file=3" to the database URL and send me the .trace.db file(s)? Regards, Thomas On Saturday, June 20, 2015, wrote: > I'll look at this, but I'm out next week. I flipped all my tests (~10,000) > back to MvStore and there are a few issues in addition to th

Re: [h2] MVStore with MVCC performance degradation

I'll look at this, but I'm out next week. I flipped all my tests (~10,000) back to MvStore and there are a few issues in addition to the pref issue. If you have any more analysis or debugging instructions for the perf issue, send them along next week. Sent from my Cyanogen phone On Jun 18, 2015 10:

Re: [h2] MVStore with MVCC performance degradation

Hi, The "missing lob entry" sounds like you try to access LOB after it has been deleted or updated, or after the result set has been closed. Do you know if that's possible? Please note the stack trace is missing in your error message. Regards, Thomas On Wednesday, June 17, 2015, Wes Clark wr

Re: [h2] MVStore with MVCC performance degradation

When I with ";mv_store=false", a sizeable percentage of the tests fail with java.lang.RuntimeException: com.guidewire.pl.system.exception.DBException: Nested: org.h2.jdbc.JdbcSQLException: IO Exception: "java.io.IOException: org.h2.jdbc.JdbcSQLException: IO Exception: ""Missing lob entry: 4""

[h2] MVStore with MVCC performance degradation

Hi, Looking at the thread dumps, the bottleneck seems to be reading metadata. There are two main cases: com.guidewire.pl.system.database.support.H2CatalogSupport.columnExists(H2CatalogSupport.java:81) com.guidewire.pl.system.database.upgrade.BeforeUpgradeColumnImpl.getTypeRepresentationInDatabas

Re: [h2] MVStore with MVCC performance degradation

Hi, I would be interested in the database URL(s) you use (any options you use), and a few full thread dumps (maybe 100 or so). I usually get full thread dumps like this: jps -l (to get the process id) jstack -l PID | gzip >> threadDumps.txt You can get the thread dumps in a loop (with a delay of

[h2] MVStore with MVCC performance degradation

We are testing the latest H2 version (from a recent nightly build, actually) in place of a rather ancient but serviceable version 1.2. We are seeing performance degradation of at least a factor of 6. We have suites of test. I can supply you with comparison timings, but for example a suite th