Hi, thanks for the feedback! I quickly tested the proposed solution (on both emails :) to disable mmapping for that check and it seems to very nicely alleviate the problem.
Bonus points: oak-segment-tar doesn't seem affected by this (all commands impls move to the segment-tar module), except a single command that is related to datastore consistency: 'datastorecheck'. I'll followup with an oak issue to disable mmaps for the version check. thanks, alex On Thu, Mar 23, 2017 at 4:28 PM, Francesco Mari <[email protected]> wrote: > Hi, > > 2017-03-23 16:13 GMT+01:00 Alex Parvulescu <[email protected]>: > > Hi, > > > > To add what I have found so far. This seems related to OAK-4274, but I > > think there might be a twist in there somewhere. > > I'm pretty sure that this method is the one introducing the extra full > > mapping of the repository: FileStoreHelper.checkFileStoreVersionOrFail > [0]. > > Disabling this method takes the 2x mapping away completely. > > I think your analysis matches with the 2x increase in memory mappings. > It might be that the memory mappings created while opening the > FileStore in read-only mode are never garbage collected, even if the > FileStore is correctly closed when checkFileStoreVersionOrFail() > returns. To avoid this, we might want to open the FileStore in > checkFileStoreVersionOrFail() with memory mapping disabled. > > > The reason I'm saying it is relate to OAK-4274 is because I looked at a > > heap dump to verify what is keeping the references to the readonly store > > and there are no live ones, the refs should be GC'ed, but for some reason > > they are not. > > > > I'm still poking around, did not create an oak issue yet. Still pending > is > > to verify if this affects other areas than oak-run. > > > > Feedback is more than welcome! > > > > best, > > alex > > > > [0] > > https://github.com/apache/jackrabbit-oak/blob/1.6/oak- > run/src/main/java/org/apache/jackrabbit/oak/plugins/ > segment/FileStoreHelper.java#L209 >
