昨天提交了一个CAP的PR发现通过了^_^，那我在提交一个 仅仅是我个人认为可能解释不太全面地方

文章地址：https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/es-optimizing-query-performance.md
不太严谨观点：

某个公司 es 节点有 3 台机器，每台机器看起来内存很多，64G，总内存就是 64 * 3 = 192G 。每台机器给 es jvm heap 是 32G ，那么剩下来留给 filesystem cache 的就是每台机器才 32G ，总共集群里给 filesystem cache 的就是 32 * 3 = 96G 内存。而此时，整个磁盘上索引数据文件，在 3 台机器上一共占用了 1T 的磁盘容量，es 数据量是 1T ，那么每台机器的数据量是 300G 。这样性能好吗？ filesystem cache 的内存才 100G，十分之一的数据可以放内存，其他的都在磁盘，然后你执行搜索操作，大部分操作都是走磁盘，性能肯定差。

这个原因解释并不全面，这里只是其中一个原因，通过我实际试验以及官方文档 设置不要超过32G，因为JVM限制当内存到达 40–50 GB 的时候，有效内存才相当于使用内存对象指针压缩技术时候的 32 GB 内存

中文解释：https://www.elastic.co/guide/cn/elasticsearch/guide/current/heap-sizing.html
因为解释：https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html

The moral of the story is this: even when you have memory to spare, try to avoid crossing the 32 GB heap boundary. It wastes memory, reduces CPU performance, and makes the GC struggle with large heaps.

通过我实际经验下面几点是比较简单且有效提高效率几个措施：

• 购买不超过32G机器，对半设置jvm
• 一个机器挂载多个磁盘，设置磁盘写性能，丢掉一些不太重要的设置
• 通过索引模板，建立自动rollover归档机制减少大index
• 另外归档策略可以自动删除过期的数据
• 如果预先知道索引类型可以通过手动创建映射，避免使用自动创建mapping
• 利用自带jdk避免使用系统jdk
• 如果想要加快索引可以增加副本，如果只是日志系统一个主索引即可