a. 如果主要的使用场景是全文检索, 那么建议给ES Heap分配 4~32G的内存即可；其它内存留给操作系统, 供lucene使用（segments cache), 以提供更快的查询性能。
b. 如果主要的使用场景是聚合或排序， 并且大多数是numerics, dates, geo_points 以及not_analyzed的字符类型， 建议分配给ES Heap分配 4~32G的内存即可，其它内存留给操作系统，供lucene使用(doc values cache)，提供快速的基于文档的聚类、排序性能。
c. 如果使用场景是聚合或排序，并且都是基于analyzed 字符数据，这时需要更多的 heap size, 建议机器上运行多ES实例，每个实例保持不超过50%的ES heap设置(但不超过32G，堆内存设置32G以下时，JVM使用对象指标压缩技巧节省空间)，50%以上留给lucene。
禁止swap，一旦允许内存与磁盘的交换，会引起致命的性能问题。 通过： 在elasticsearch.yml 中 bootstrap.memory_lock: true， 以保持JVM锁定内存，保证ES的性能。
调整JVM设置ES 是在 lucene 的基础上进行研发的，隐藏了 lucene 的复杂性，提供简单易用的 RESTful Api接口。ES 的分片相当于 lucene 的索引。由于 lucene 是 Java 语言开发的，是 Java 语言就涉及到 JVM，所以 ES 存在 JVM的调优问题。
调整内存大小。当频繁出现full gc后考虑增加内存大小，但是堆内存和堆外内存不要超过32G。
调整写入的线程数和队列大小。不过线程数最大不能超过33个（es控制死）。
ES非常依赖文件系统缓存，以便快速搜索。一般来说，应该至少确保物理上有一半的可用内存分配到文件系统缓存。
GC设置原则：
a. 保持GC的现有设置，默认设置为：Concurrent-Mark and Sweep (CMS)，别换成G1GC，因为目前G1还有很多BUG。
b. 保持线程池的现有设置，目前ES的线程池较1.X有了较多优化设置，保持现状即可；默认线程池大小等于CPU核心数。如果一定要改，按公式（（CPU核心数* 3）/ 2）+ 1设置；不能超过CPU核心数的2倍；但是不建议修改默认配置，否则会对CPU造成硬伤。
参考文档：
elasticsearch倒排表压缩及缓存合并策略
Frame of Reference and Roaring Bitmaps
elasticsearch 倒排索引原理
Elasticsearch性能优化总结
亿级 Elasticsearch 性能优化