es oom kill（异常停止）---一种解决方案

前文

  前一阵子es突然挂了，这里简单说下部署：es没采用docekr，而是采用集群化部署，在三台虚拟机上通过systemd部署实例；通过定位发现是三台es中的两台异常关闭，导致剩一台使集群变成red无法使用。
  通过查看/var/log/elasticsearch/下的日志发现没有输出，通过journalctl -xeu elasticsearch，只能看到关停了（且是被kill -9杀死），但未显示详细原因；最后用dmesg -T查看到是因为oom（out of memory）导致elasticsearch被kill。
  通过加内存将32翻倍到64，在第二天仍旧因为oom被kill，但是此时能确定用户量和使用量并未突增，不可能会导致es内存不足。

解决

  在将es拉起的过程中，发现es的replica有部分编程unsigned（采用的是replica为1的备份机制），就顺手解决这个问题。
  查看分片unsigned原因：

GET _cat/shards?h=index,shard,prirep,state,unassigned.reason
GET _cluster/allocation/explain?pretty

  将replica先置为0，将unsigned的去除，然后再置为1使其重新分配。

重新分配replica：
PUT commits/_settings
{
  "number_of_replicas": 1
}

  回到主题，通过查看linux的负载、cpu、内存使用情况，发现除了内存外都不是很高，而内存也是按jvm.options里设置的大小来运行的，所以也并未超出限制；此时注意到swap的使用，在三台机的swap都使用很多，翻阅资料有看到建议es集群的swap要关闭，所以定位到是swap的问题，于是进行关闭：

# 临时关闭，因为本身已经被占用，所以要耗时，根据占用的量耗时不同，但不影响业务
swapoff -a
# 等临时关闭后，再执行永久关闭
vi /etc/fstab
# 将swap的所在行注释了即可，注释后可以开机验证