背景
某日线上一个6.4.3版本的Elasticsearch集群，规模只有2核4G*3节点，分片有大约10000个，因为JVM堆内存使用率过高，导致节点频繁掉线，在重启了该集群后，分片逐渐恢复，但是最后只剩不到300个分片迟迟无法恢复，通过GET _cluster/allocation/explain 看到如下原因：
failed to write index state
java.nio.file.FileSystemException: /data1/containers/1568005591000623209/es/data/nodes/0/indices/YoM9bi5vSgW2pm8L4o9dzw/_state: Too many open files in system
从表面上看是系统打开的文件描述符过多，导致分片无法恢复，但是我们线上集群都会把启动es进程的用户的ulimit各种限制调的比较大，最大文件描述符为655360，难道这个限制也超过了吗？
问题定位与解决
1. 查看系统资源的使用情况
对ES进程执行lsof命令：lsof -p 3383 |wc -l， 结果为387220， 说明ES本身占用了将近40w个文件描述符。
再通过netstat命令，查看到ES进程的http或者tcp连接都只有几十条，排除网络原因造成的过多文件描述符占用。
2. 查看ES目录
ES本身占用了将近40w个文件描述符，进入到ES的data目录后，发现translog目录下有大量的文件.tlog和.ckp文件，应该就是这些文件占用了大量的文件描述符。而为什么会产生这么多的translog文件，发现就是因为节点只有4G内存，节点内存使用率过高，频繁触发系统的OOM-killer将ES进程杀死，进程被kill掉以后保活agent又将ES进程重启，而每次重启后都会产生新的translog文件，最终把系统的文件描述符耗尽。
3. 临时解决办法
问题是线上集群所用的centos系统我们默认会通过修改/etc/security/limits.conf文件把启动ES进程的用户的文件描述符限制调的很大，如下所示：
elasticsearch - nofile 655360
* - as unlimited
* - nproc 2056474
* - fsize unlimited
elasticsearch - memlock unlimited
为什么还会出现文件描述符耗尽的情况呢？通过Google, 发现系统级别的最大文件描述符数量还受限于file-max参数，通过执行"cat /proc/sys/fs/file-nr"命令可以看到如下结果：
379648 0 379380
上述结果中三个至分别为当前系统已经分配的文件描述符数量，已经分配但未使用的文件描述符数量，系统最大能分配的文件描述符数量。从这个结果中可以看出，ES进程消耗的文件描述符数量已经超过了系统最大能分配的文件描述符数量。
因此，通过临时调大系统最大文件描述符数量限制:
sysctl -w fs.file-max=579380;
sysctl -p;
然后重启ES进程，后续集群所有的分片都逐渐恢复，集群恢复正常。
从上面的解决办法我们看到，虽然我们调整了elasticsearch用户的文件描述符限制为655360， 但是这个只是用户级别的，还有系统级别的总的文件描述符数量限制，这个是和所使用的机器规格有关的，因为节点只有4G内存，所以最大文件描述符限制比较低，只有不到40w。
4. 为什么ES没有自动清理translog文件
ES进程每次重启后都会产生新的translog文件和ckp文件，为什么没有清理这些过期的旧文件呢？
ES清理translog文件是由"index.translog.retention.size"和"index.translog.retention.age"两个参数控制，默认值分别为512MB和12h, 也即translog文件总的大小超过512MB之后会清理最老的文件，以及超过12小时的文件也会被清理。但是在本例中，实际上老的translog文件的修改时间早已经超过12小时，但是为什么没有被清理呢？实际上这是ES 6.x的bug，因为ES进程不断的重启，重启后进程还有触发flush，就被kill掉，导致translog generation始终为1，所有的文件都被保留下来，最终触发了系统级别的最大文件描述符限制。
这个问题在github上有issue: https://github.com/elastic/elasticsearch/issues/49970, 最终在7.x版本被修复，PR为：https://github.com/elastic/elasticsearch/pull/51905。
