Answering my own question: use compactFile() to compact. I'm also getting good results with regularly calling compact() with a target fill rate of 80 (prioritising size over write speed).
And I'm no longer flushing the cache concurrently (superstitiously - just in case). On Friday, July 16, 2021 at 9:06:05 AM UTC+9:30 Matthew Phillips wrote: > Hello Andrei, > > thanks very much for your reply. > > Yes, I'm aware I'm on an old version: if it's not broken, don't fix it ;) > Version 1.4.197 has been rock-solid for us for years, and I'm always loathe > to change things for no reason. But you have given me a good reason, so > I'll give the latest MVStore a try. > > Can you recommend the best way to 'manually' compact the database in the > latest release? > > And just to be sure: could there be any data-loss issues from flushing the > cache? > > Cheers, > > Matt. > > On Friday, July 16, 2021 at 4:45:12 AM UTC+9:30 [email protected] wrote: > >> Hi Matt, >> >> If you are experiencing a problem, which looks and smells like a >> cuncurrency issue, then there is definitely a good reason to suspect a >> concurrency issue. 8-) >> The real question here is: if you care enough about those problems, why >> are you still on version 1.4.197. MVStore's concurrency / synchronization >> was totally re-designed since then (and we are talking years here), for >> example you will not even find MVStore.compactRewriteFully() method >> anymore, but instead it might just do all that space management, so you >> won't need that background operation at all. >> In any case, I would not expect that someone will look at 1.4.197 issues >> at this point. On the other hand, if you will find similar problem with >> current trunk version, and will be able to reproduce it, I will be more >> than happy to work on it. >> >> Cheers, >> Andrei. >> >> On Thursday, July 15, 2021 at 3:39:40 AM UTC-4 [email protected] wrote: >> >>> Hello, >>> >>> I'm trying to track down a perplexing problem when using an MVStore, >>> where it appears that a write using MVMap.put() is being dropped (H2 >>> 1.4.197). It's only happened twice, but both of those times have been after >>> a series of cache flushes, and where the .put() is done *concurrently* with >>> a long-running call to compactRewriteFully() (which takes around 90s for >>> this DB). We're not using rollback, or transactions or anything fancy, just >>> raw put(), get(), commit(). >>> >>> My question: is there any reason to suspect that the cache flushes or, I >>> think more likely, the concurrent compactRewriteFully() might somehow be >>> causing the write to be dropped? >>> >>> If so, I'm open to compacting the DB in some other way, but >>> compactRewriteFully() has been the most reliable at keeping the DB size >>> stable, despite its overhead (it's currently being run from a background >>> thread that runs once a day in the wee hours). >>> >>> Cheers, >>> >>> Matt. >>> >> -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/h2-database/71635b93-0774-4134-b3f3-8ab610b1f893n%40googlegroups.com.
