Hi everyone,

Every time we touch the size of JVM heap for Elasticsearch we can

meet indisputable statement "don't let the heap to be bigger than 32GB -

this is a magical line". Of course making heap bigger than 32G means that

we lose OOPs. There are tons of blogs posts and articles which shows how

switching OOPs influence on application heap usage (eg.

https://blog.codecentric.de/en/2014/02/35gb-heap-less-32gb-java-jvm-memory-oddities/).

Lets ask ourselves a question if this is a very big problem for ES&Lucene

too.

I analyzed a few heap dumps from ES. The maximum size of the heap was set

below magical boundary (Xmx was 30GB). In all cases I can see similar

pattern but let's discuss it based on a single example. One heap dump I

took had around 16GB (slightly more) of reachable objects in it. There were

about 70M objects. Of course I cannot just take 70M to see how much of the

heap I can save by having OOPs enabled but I also tried to analyze the

number of references to objects (because some objects are referenced

multiple times from multiple places). This gave me a number around 110M

inbound references so OOPs let us save about 0.5GB of memory so when we try

to estimate, this would mean around *1GB* when whole the heap is currently

in use (as I wrote earlier only 16GB of reachable objects were in heap) -

for analyzed case. Moreover I can observe this:

2M objects of type long[] which take 6G of heap

280K objects of type double[] which take 4.5G of heap

10M objects of type byte[] which take 2.5G of heap

4.5M objects of type char[] which take 500M of heap

When we sum all of sizes we can see 13.5GB of primitive arrays pointed by

less than 20M references. As we can see ES&Lucene use a lot of arrays of

primitives.

Elasticsearch is very "memory-hungry" especially when using aggregations,

multi-dimensional aggregations and parent-child queries. I think sometimes

it is reasonable to have a bigger heap if we have enough free resources.

Of course we have to remember that the bigger heap means more work for GC

(and currently used in JVM: CMS or G1 are not very efficient for large

heaps), but ... Is there really a magical line (32GB) after crossing we get

into "JVM troubles" or we can find a lot of cases where crossing the

magical boundary makes sense?

I'm curious what are your thoughts in this area?

--

Paweł Róg

--

You received this message because you are subscribed to the Google Groups "elasticsearch" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAHngsdhSiXbdzYxss25f-JMpe5E5J545zLrW8tnK1e74K%3D4tqg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.