database performance - Neo4j and Hugepages -
since neo4j works in memory, wondering if advantageous enable hugepages (https://www.kernel.org/doc/documentation/vm/hugetlbpage.txt) in linux kernel, , xx:+uselargepages or maybe -xx:+usehugetlbfs in (openjdk 8) jvm ?
if so, rule of thumb should use decide how many hugepages configured?
the neo4j performance guide (http://neo4j.com/docs/stable/performance-guide.html) not mention this, , google didn't turn else discussing (in first couple of search pages anyway), thought i'd ask.
i'm wrestling acceptable performance new neo4j instance (2.3.2-community). little bit help. want know if worth trying before bring down database change jvm flags... i'm hoping else has done experiments along these lines already.
thanks!
since neo4j own file paging , doesn't rely on os this, should advantageous or @ least not hurt. huge pages reduce probability of tlb cache misses when use large amount of memory, neo4j when there's lot of data stored in it.
however, neo4j not directly use hugepages though , nice addition. means have rely on transparent huge pages , whatever features jvm provides. transparent huge pages can cause more-or-less short stalls when smaller pages merged.
if have representative staging environment advise make changes there first, , measure effect.
transparent huge pages problem programs use mmap because i think can lead changing size of unit of io, make hard-pagefault latency higher. i'm not entirely sure this, though, please correct me if i'm wrong.
the jvm use mmap telemetry , tooling, through file in /tmp make sure directory mounted on tmpfs avoid gnarly io stalls, instance during safe-points (!!!). if don't use huge pages.
also make sure using latest linux kernel , latest java version.
you may able squeeze percentage points out of tuning g1, bit of black art.
Comments
Post a Comment