Hi Roman, Nice write up. One thing I noticed is that you are mixing up page cache information from 2.2, with earlier Neo4j versions. We rewrite the page cache from scratch in 2.2, and that’s where the 8192 byte page size was introduced. It’s a sensitive number because it both controls the unit of IO with the underlying storage subsystem, and it controls the coarseness of the page locks.
We did consider relying on OS memory mapping, but Java will only let you map 2 GBs in one go, so you’d have to do something to support files larger than that anyway. Another issue is that freeing the native memory held by a MappedByteBuffer requires two GCs. With our own page cache, we are better able to reuse the allocated native memory, so we don’t have to worry about the freeing. We also gain simpler, and more controlled failure handling. I hadn’t seen this one coming, but it turned out to be a nice surprise. -- Chris Vest System Engineer, Neo Technology [ skype: mr.chrisvest, twitter: chvest ] > On 03 Feb 2015, at 17:12, Roman Leventov <leventov...@gmail.com> wrote: > > I've done some Neo4j architecture analysis: > http://key-value-stories.blogspot.com/2015/02/neo4j-architecture.html > > Corrections and answers to open questions from Neo4j developers are welcome. > > -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to neo4j+unsubscr...@googlegroups.com > <mailto:neo4j+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to neo4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
