參考：https://www.elastic.co/guide/cn/elasticsearch/guide/current/heap-sizing.html
不要超過 32 GB！編輯
這里有另外一個原因不分配大內存給 Elasticsearch。事實上 ， JVM 在內存小於 32 GB 的時候會采用一個內存對象指針壓縮技術。
在 Java 中，所有的對象都分配在堆上，並通過一個指針進行引用。 普通對象指針（OOP）指向這些對象，通常為 CPU 字長 的大小：32 位或 64 位，取決於你的處理器。指針引用的就是這個 OOP 值的字節位置。
對於 32 位的系統，意味着堆內存大小最大為 4 GB。對於 64 位的系統， 可以使用更大的內存，但是 64 位的指針意味着更大的浪費，因為你的指針本身大了。更糟糕的是， 更大的指針在主內存和各級緩存（例如 LLC，L1 等）之間移動數據的時候，會占用更多的帶寬。
Java 使用一個叫作 內存指針壓縮（compressed oops）的技術來解決這個問題。 它的指針不再表示對象在內存中的精確位置，而是表示 偏移量 。這意味着 32 位的指針可以引用 40 億個 對象 ， 而不是 40 億個字節。最終， 也就是說堆內存增長到 32 GB 的物理內存，也可以用 32 位的指針表示。
一旦你越過那個神奇的 ~32 GB 的邊界，指針就會切回普通對象的指針。 每個對象的指針都變長了，就會使用更多的 CPU 內存帶寬，也就是說你實際上失去了更多的內存。事實上，當內存到達 40–50 GB 的時候，有效內存才相當於使用內存對象指針壓縮技術時候的 32 GB 內存。
這段描述的意思就是說：即便你有足夠的內存，也盡量不要 超過 32 GB。因為它浪費了內存，降低了 CPU 的性能，還要讓 GC 應對大內存。