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 <steve....@gmail.com <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 <steve....@gmail.com> 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 <yone...@gmail.com> 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 h2-database...@googlegroups.com. >>>>>> To post to this group, send email to h2-da...@googlegroups.com. >>>>>> 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 h2-database+unsubscr...@googlegroups.com. >>>> To post to this group, send email to h2-database@googlegroups.com. >>>> 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 h2-database+unsubscr...@googlegroups.com. >> To post to this group, send email to h2-database@googlegroups.com. >> 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at https://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
