Hi Thomas, Thanks for investigating. I'm on the road for a couple of weeks; when I get a quiet evening soon, I'll check database size before and after compaction.
Do let me know if I can help further in profiling and analyzing this problem. Regards, Steve On Tuesday, 10 May 2016 17:52:05 UTC+1, Thomas Mueller wrote: > > Hi, > > I found out, for your case, a lot of time is spend on garbage collection > of unused chunks. In your case this is about 40%, maybe this gets slower > and slower the larger the file. > > In the past, reference counting garbage collection was used, which is > fast, but it was not always accurate (the main problems are concurrency and > rollbacks). I need think how to best solve this. > > To use reference counting GC, a simple way might be to use one immutable > tree, but that would reduce concurrency somewhat (not sure if that's > important). It would also solve another (unrelated) rollback problem. But > it's quite a big change. > > Just trying to make the existing GC faster is probably easier, but doesn't > scale quite as good. The same goes for doing GC only once in a while (at > most once every 10 seconds for example). > > Could you tell me what is the size of your database file (before and after > compaction)? > > Regards, > Thomas > > > > > > > On Wednesday, May 4, 2016, Steve McLeod <[email protected] <javascript:>> > wrote: > >> Hi Thomas, >> >> I'll send you a private email with this info. >> >> Regards, >> >> Steve >> >> >> On Tuesday, 3 May 2016 07:45:55 UTC+2, Thomas Mueller wrote: >>> >>> Hi Steve, >>> >>> I wonder, did you test with a spinning disk or a solid state disk? Also, >>> I would be interested to know how much the difference is. >>> >>> Of course it would be nice to have a reproducible test case, but if now, >>> then could you get full thread dumps (once per second for example) and heap >>> histograms (once every 20 seconds is enough)? I usually use the command >>> like way: "jstack -l <pid> >> jstack.txt" and "jmap -histo <pid> >> >>> jmap.txt". I would use an endless loop with "sleep 1" as a shell script. >>> >>> Regards, >>> Thomas >>> >>> >>> >>> On Thursday, March 31, 2016, Steve McLeod <[email protected]> wrote: >>> >>>> Hi Thomas, >>>> >>>> If keeping performance on par with the page store is an aim before >>>> removing the beta status, I'd say 1.4 is not ready. >>>> >>>> I did some performance tests today with my product against 1.4 with the >>>> MV Store and 1.4 with the page store. The page store is still much faster >>>> for a large number of inserts and updates. >>>> >>>> When building up a database that is 5 GB in size, inserts and updates >>>> seem to get progressively slower. >>>> >>>> Let me know if any specific performance analysis would be useful. >>>> >>>> Regards, >>>> >>>> Steve >>>> >>>> >>>> >>>> >>>> On Wednesday, 30 March 2016 19:34:27 UTC+2, Thomas Mueller wrote: >>>>> >>>>> Hi, >>>>> >>>>> The MVStore I consider stable. What is relatively new is the table >>>>> engine that uses the MVStore, but even that one I would say is stable >>>>> now. >>>>> Unfortunately I didn't have time lately to do a release, I'm sorry about >>>>> that. >>>>> >>>>> Regards, >>>>> Thomas >>>>> >>>>> On Mon, Mar 28, 2016 at 9:20 AM, yone <[email protected]> wrote: >>>>> >>>>>> Hi. >>>>>> >>>>>> >>>>>> Now I'm measuring H2MV performance. And the result is very nice. >>>>>> >>>>>> The benchmark of compaction ratio/read/write are better than LevelDB!! >>>>>> >>>>>> My product just use put/get/commit with synchronization. >>>>>> >>>>>> Is my simple operation stable or not? >>>>>> >>>>>> >>>>>> If you decide the date when remove beta, please let us know. >>>>>> >>>>>> # There are already similar topic. I'm sorry if you feel bad >>>>>> >>>>>> Best regard, >>>>>> >>>>>> -- >>>>>> 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. >>>>>> >>>>> >>>>> -- >>>> 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. >>>> >>> -- >> 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. >> > -- 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.
