我有一个在9个节点5 data 3 master上运行的elasticsearch集群。
最初，在每个节点上分配的弹性堆空间为2g，每个节点都是一个大约58g内存的VM。
昨天我的一个节点发生了故障，整个群集停电了。我在ES日志中找到的所有内容都是：
[WARN ][o.e.m.j.JvmGcMonitorService] [xxxxxXXxxxx] [gc][young][4109765][392598] duration [13.5s], collections [1]/[3.9s], total [13.5s]/[50.5m], memory [1.4gb]->[1.5gb]/[1.9gb], all_pools {[young] [456.8mb]->[543.3mb]/[546.1mb]}{[survivor] [9mb]->[9mb]/[68.2mb]}{[old] [1gb]->[1gb]/[1.3gb]}
现在我甚至无法登录（ssh）到这个实例中，并且它在整个群集中支持赎金。打破整个管道。
当我检查服务器日志时，我可以看到内存消耗量在几个小时内从仅仅30％上升到99.98％。这是在重启后处理的
这里我有以下问题
当我为进程分配2g内存时，该进程如何超过并消耗高达90％的可用内存。
如果我的某个节点出现故障，我如何保证我的群集不会失败。
对于第二部分，我从https://github.com/elastic/elasticsearch/issues/23939
获得了一些信息哪个州： 在长时间GC /网络断开连接后再次形成集群，并且主服务器将分片分配给有问题的节点时，该节点首先必须正确关闭现有的分片资源。这可能需要一段时间，具体取决于先前运行的操作。这表现在ShardLock失败中，因为新的分片实例在旧的分片实例未完全清理时无法创建。我们目前正在研究如何更深入地了解哪些类型的操作阻止了旧的分片实例的发布，这将需要更改代码。
如何防止此问题导致群集中断？
答案 0 :(得分：1)
几个问题：
1：＆＃34;最初在每个节点上分配的弹性堆空间为2g＆＃34;。这是否意味着你只设置＆＃39; -Xms2g＆＃39; ??不是-Xmx？
2：为什么在58GB可用时，Elasticsearch只有2GB内存？
3：＆＃34;当我为进程分配2g内存时，该进程如何超过并消耗高达90％的可用内存。＆＃34;你怎么注意到它消耗更多？ （还与第一个问题相关）
问题背后的推理：
1：＆＃34;确保min（Xms）和max（Xmx）大小相同，以防止堆在运行时调整大小，这是一个非常昂贵的过程。＆＃34; （来自ES documentation）
2：尝试将half of your memory提供给ES，将另一半提供给操作系统