Re: Oak 1.0.29 vs 1.4.10 memory mapping.

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

Re: Oak 1.0.29 vs 1.4.10 memory mapping.

Hi, 2017-03-23 16:13 GMT+01:00 Alex Parvulescu : > 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

Re: Oak 1.0.29 vs 1.4.10 memory mapping.

Hi, I'm pretty sure that this method is the one introducing the extra full mapping of the repository: FileStoreHelper.checkFileStoreVersionOrFail We should probably run this check with memory mapping disabled anyway. Nothing to gain here but probably this would fix the double mapping and

Re: Oak 1.0.29 vs 1.4.10 memory mapping.

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

Re: Oak 1.0.29 vs 1.4.10 memory mapping.

Hi, Based on the page fault behaviour, I think the areas mapped and reported by pmap are being actively accessed by the JVM. The number of page faults for Oak 1.4.11 is well over 2x the number of page faults for Oak 1.0.29 on the same VM, with the same DB when performing an oak-run offline

Re: Oak 1.0.29 vs 1.4.10 memory mapping.

You might be hitting OAK-4274, which I discovered quite some time ago. I'm not aware of a way to resolve this issue at the moment. 2017-03-22 16:47 GMT+01:00 Alex Parvulescu : > Hi, > > To give more background this came about during an investigation into a slow >

Re: Oak 1.0.29 vs 1.4.10 memory mapping.

Hi, To give more background this came about during an investigation into a slow offline compaction but it may affect any running FileStore as well (to be verified). I don't think it's related to oak-run itself, but more with the way we map files, and so far it looks like a bug (there is no

Oak 1.0.29 vs 1.4.10 memory mapping.

Hi, I am looking at Oak-run and I see 2x the mapped memory between 1.0.29 and 1.4.10. It looks like in 1.0.29 each segment file is mapped into memory once, but in 1.4.10 its mapped into memory 2x. Is this expected ? Its not great for page faults. Best Regards Ian