由于ES构建基于lucene,而lucene设计强大之处在于lucene能够很好的利用操作系统内存来缓存索引数据，以提供快速的查询性能。lucene的索引文件segements是存储在单文件中的，并且不可变，对于OS来说，能够很友好地将索引文件保持在cache中，以便快速访问；因此，我们很有必要将一半的物理内存留给lucene ;另一半的物理内存留给ES（JVM heap )。
所以， 在ES内存设置方面，可以遵循以下原则：
-
当机器内存小于64G时，遵循通用的原则，50%给ES，50%留给lucene。
-
当机器内存大于64G时，遵循以下原则
- 如果主要的使用场景是全文检索,那么建议给ESHeap分配4~32G的内存即可；其它内存留给操作系统,供lucene使用（segments cache),以提供更快的查询性能。
- 如果主要的使用场景是聚合或排序， 并且大多数是numerics, dates, geo_points以及not_analyzed的字符类型， 建议分配给ES Heap分配4~32G的内存即可，其它内存留给操作系统，供lucene使用(doc values cache)，提供快速的基于文档的聚类、排序性能。
- 如果使用场景是聚合或排序，并且都是基于analyzed字符数据，这时需要更多的heap size,建议机器上运行多ES实例，每个实例保持不超过50%的ES heap设置(但不超过32G，堆内存设置32G以下时，JVM使用对象指标压缩技巧节省空间)，50%以上留给lucene。
-
禁止swap，一旦允许内存与磁盘的交换，会引起致命的性能问题。
通过在elasticsearch.yml中bootstrap.memory_lock: true，以保持JVM锁定内存，保证ES的性能。 -
GC设置原则：
- a.保持GC的现有设置，默认设置为：Concurrent-Mark and Sweep (CMS)，别换成G1GC，因为目前G1还有很多BUG。
- b.保持线程池的现有设置，目前ES的线程池较1.X有了较多优化设置，保持现状即可；默认线程池大小等于CPU核心数。如果一定要改，按公式（（CPU核心数* 3）/ 2）+ 1设置；不能超过CPU核心数的2倍；但是不建议修改默认配置，否则会对CPU造成硬伤。