Performance issue on vertex cache with Guava implementation

[ministat]

JanusGraph's GuavaVertexCache will cause memory leak in 100% read and heavy read scenario, especially used in OLAP cases. The Guava cache should be replaced by Caffiene cache to fix this issue according to Guava's community feedback.
See google/guava#2408 and google/guava#2063.

In my local JanusGraph, after I replaced Guava cache with Caffeine cache, the OLAP case, for example, g.V().count() takes 18 minutes to finish the scan of a graph with 500 million vertex and 6 billion edges. Before this fix, it takes 45 minutes. So, the fix gets ~3X benefit.

For confirmed bugs, please report:

• Version: All versions before 0.6.2, including 0.6.2
• Storage Backend: hbase, inmemory, cql
• Mixed Index Backend:
• Link to discussed bug: Guava LocalCache recencyQueue is 223M entires dominating 5.3GB of heap google/guava#2408, Cache performance google/guava#2063
• Expected Behavior: vertex cache should not be the top 1 memory leak suspect
• Current Behavior: Guava vertex cache caused leak suspects from JVM heap dump
• Steps to Reproduce: develop a java app which initialize GuavaVertexCache with 30 element size, and launch multiple threads to call get() in a loop. The loop should be, for example, 1,000,000. Use

Stack Trace (if you have one)

paste stack trace here

[li-boxuan]

Thanks for reporting @ministat! Seems a duplicate of #871 (which was created by the author of Guava, interesting!). Usually, we close newer issues if they are duplicates, but your discovery and experiments are very valuable so I'd like to keep both issues open. Would you like to contribute your implementation back to the community by submitting a PR? That would be very helpful!

[ministat]

Yes, I have submitted the PR. But I'm blocked by CLA.

[porunov]

Identified 8 Guava caches in JanusGraph. Posted them here: #871 (comment)

[porunov]

Fixed in #3188
The continuation of work to replace other 7 Guava caches will be tracked in the next issue: #871