Hi, It's not an anomaly. If you overwrite existing entries, as you do in B), then the old value is first read. Which means reading from disk. There are currently no "blind writes".
> Used cache size calculation seems to be incorrect It depends on the key and value data types you use. You didn't say which one you use, so I can't say. Regards, Thomas On Tue, Mar 14, 2017 at 11:10 AM, Roland Lohner <loc...@gmail.com <javascript:_e(%7B%7D,'cvml','loc...@gmail.com');>> wrote: > Hi Thomas, > > Thank you for your answer. > > Yes, I am using MVStore.cache. > The MVStore object is instantiated like this: > > > store = MVStore.open(file.getPath()); > > store.setAutoCommitDelay(0); > > store.setReuseSpace(true); > > store.setVersionsToKeep(0); > > store.setCacheSize(descriptor.getCacheSizeMb()); > > I investigated the cache miss problem more detailed and it turned out that > it is caused by an unstable calculation of used cache size in MVStore. > Depending on the situation A. and B. (see below) different cache size is > returned by method store.getCache().getUsedMemory(). > > A.) An empty data file is opened with MVStore and a new dataset is > imported (put ~ 1 million entries in different MVMaps). Then a search > function is executed against the dataset (MVMap.get operations). During > search, cache hits=1.1 million, cache misses=0, cache size=1336MB. (value > reported by store.getCache().getUsedMemory() / 1024 / 1024) > > B.) Close MVStore and reopen using data file created and written to disk > in case A. Run same search function as in case A. The first run loads > caches, so subsequent runs are faster. During search, cache hits=1.1 > million, cache misses=0, > > *cache size=5032MB.*Data stored in MVStore in both cases A, B are the > same and the same search function is executed. Cache miss is zero in both > cases. Used cache size calculation of MVStore is still very different in > these cases. How is it possible? Do you think we found a bug? Or some more > special configuration on caching should be done? > > If a maximum cache size of (for example) 3000MB is set up then all needed > map entries are cached in case A. but only a part of them are cached in > case B. This difference in cache misses is reflected also in highly > increased execution time of the search function in case B. > > Another anomaly: In case B. when used cache size is reported to be 5032Mb, > the whole java process allocates only 1.7GB of memory. Consequently it is > impossible to cache ~5G of data. Used cache size calculation seems to be > incorrect. This incorrect calculation prohibits proper cache size > configuration. > > Each versions: 1.4.193, 1.4.180 and 1.3.175 has this behavior. > Java: Oracle JDK 1.8.0_121 on Linux 64bit > > Thanks for any help. > Regards, Roland > > > > -- > 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 > <javascript:_e(%7B%7D,'cvml','h2-database%2bunsubscr...@googlegroups.com');> > . > To post to this group, send email to h2-database@googlegroups.com > <javascript:_e(%7B%7D,'cvml','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.
