说明

本文描述问题及解决方法同样适用于 腾讯云 Elasticsearch Service（ES）。

• 系统环境说明

Linux环境：CentOS Linux release 7.2 (Final)

Elasticsearch： 7.10.1

Java：1.8.0_181

• 机器配置

机器数量：5

内存：8G

硬盘：200G

CPU核心数：2

背景

节点反复下线

当业务不是特别重要的时候，往往升级配置的需求不是很强烈。但是低配机器通常伴随集群不稳定等问题，严重的情况还会直接导致集群无法使用。

问题

节点轮番下线，2分钟下线一个节点，集群无法使用，状态一直RED。即便有副本也无济于事，主分片下线，副本分片被紧急提升为主分片，然而副本分片还没来及恢复，主分片所在的节点又下线了，此时高可用失去意义。

图中可以明显看出节点离线十分频繁。

问题原因

机器配置过低

进一步分析，发现节点下线是因为反复发生OOM。机器配置确实很低，但由于业务场景的原因，这个集群只要保障可用即可，对性能没有要求。基于这些现状，我决定曲线救国。

图中可以看出发生了OOM。

解决方案

方案一：解决堆外使用率过高的问题

问题的根因是因为内存不足，经过分析，发现是堆外内存使用比较严重，一直在疯涨，达到100%发生OOM。

禁止堆外：

curl -H "Content-Type:application/json" -XPUT http://localhost:9200/_cluster/settings -d '{
  "persistent" : {
    "indices.segment_memory.off_heap.enable" : false
   }
}'

禁止堆外之后，明显发现离线频率降低了，但是偶尔还是容易发生两个节点同时离线，导致集群变红。

方案二：解决内存不足的问题（不推荐）

由于业务场景的缘故，对集群性能要求不高，但求集群能够使用即可，这里我想到了增加交换内存。

dd if=/dev/zero of=/opt/swap bs=8192 count=1024000
chmod 600 /opt/swap
mkswap /opt/swap
swapon /opt/swap

在增加了交换内存之后，离线的频率明显降低，由之前的分钟级变为了小时级，完全可以满足业务需求。

图中可以看出uptime最近一次重启是21分钟前，最久一次的重启是5小时前。

方案三（探索中）

以上两个方案都只是缓解OOM问题，不能彻底解决OOM。所以解决问题的最佳方案，还需进一步探索。

申明

Elasticsearch官方强烈要求关闭交换内存，目的是为了减少请求延迟。这里是由于业务场景的特殊性，对性能没有要求，所以可以接受请求延迟。

截图来自 —— swapping 是性能的坟墓