单台es内存不是越多越好
hai046 opened this issue · 4 comments
昨天提交了一个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
- 如果想要加快索引可以增加副本，如果只是日志系统一个主索引即可
如果单机多节点也行吧，我们就是这样部署的
32G内存只是单个实例的建议最大内存设置值，对于大内存的主机，是可以采用多个节点部署来避免资源浪费的情况，一个机器上多个es进程是可行的；不是说es就只能用廉价机器、
而且单独master节点（非data节点）,因为只参与选举和资源协调，可以用更低配的服务器代替
如果单机多节点也行吧，我们就是这样部署的
是的，可以在大内存机子上部署多个节点是可以的，链接地址里官方也说了；master一遍就指定便于集群稳定性
不过我们后来没有采用大内存分割是想便于物理隔离和便于维护，我们面向的是海量日志，主要强调写入能力，我们一个节点挂载了4+个磁盘
之所以我之所以说不全面，主要是说你提到的理由可能是一个方面，而对我自己部署过的应用场景来看这只是其中一个原因