当业务不是特别重要的时候，往往升级配置的需求不是很强烈。
说明
- 系统环境说明
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小时前。
申明
Elasticsearch官方强烈要求关闭交换内存，目的是为了减少请求延迟。这里是由于业务场景的特殊性，对性能没有要求，所以可以接受请求延迟。
截图来自 —— swapping 是性能的坟墓
方案三：解决异常插件问题（水落石出，彻底根治）
通过一系列的分析，目前看函数调用链，偏向于是QQ分词器的问题。
确认这些函数是QQ分词器里面的。卸载QQ分词器之后，问题解决。
注意：
如果业务需要使用QQ分词器，无法卸载该插件，则可以临时采用方案二，QQ分词器BUG的修复，正在紧张进行中，届时发布后更新此插件即可彻底修复。
