OrientDb allocates massive disk cache on large systems

OrientDB uses an automatic tuning algorithm to determine the upper size of its native memory disk cache. This algorithm assumes that serving Orient is the primary function of the box, and on larger system can end up allocating gigantic caches (on a system with a 1TB drive and 32Gb memory, Orient set an upper cache size of 29Gb).

A pmap will show a large number of 'anon' segments:

{{00007f67dc000000 65508K rw--- [ anon ]
00007f67dfff9000 28K ----- [ anon ]
00007f67e0000000 65508K rw--- [ anon ]
00007f67e3ff9000 28K ----- [ anon ]
00007f67e4000000 65508K rw--- [ anon ]
00007f67e7ff9000 28K ----- [ anon ]
00007f67e8000000 65508K rw--- [ anon ]
00007f67ebff9000 28K ----- [ anon ]
00007f67ec000000 65504K rw--- [ anon ]
00007f67efff8000 32K ----- [ anon ]
}}

Stuart McCulloch points out that a system property can be used to set an explicit cache size (in Mb):

storage.diskCache.bufferSize=4096

We should consider:

• Setting an appropriate maximum
• Writing an algorithm that will replace Orient's tuning calculation, given that we're using Orient in an embedded mode
• Documenting this property as something clients might tune on large installations