【踩坑日记】Docker elasticsearch too many open files问题处理

项目场景：

使用单机ES作为日志存储数据库，每日生成一个日期索引，由于每日的数据量可能较大，有时候需要进行磁盘扩容操作，本次问题记录还未找到根本的触发原因，后续找到原因后再进行记录

问题描述

每日创建es索引时发现报错：elasticsearch. java.net.SocketTimeoutException: 30,000 milliseconds timeout；查询es数据时也出现请求返回较慢和连接超时的情况

原因分析：

猜测问题产生的情况

1. 大量请求插入es

2. 内存不足

3. 磁盘不足

解决方案：

1,停止插入请求，排除大量请求问题

2.查看内存和磁盘使用情况，排除内存和磁盘问题影响

3. 查看docker中ES的日志发现有大量的：too many open files 错误日志，经过查询可能是打开句柄书超过系统设置的句柄总数导致。

详细排查流程如下：
查看系统总句柄数
ulimit -Sn
#【结果：65536】

查看ES容器进程详情(获取ES的进程pid）
docker top <ES容器ID>
#【结果：2205】

查看ES进程目前的文件打开数以及限制
cat /proc/2205/limits
#【结果：65536】

查看进程使用句柄数
ls -l /proc/2205/fd/* |wc -l
#【结果：65535】

#可以看出ES容器使用的句柄数已经基本等于系统最大的句柄总数，所以才导致too many open files的异常出现

#临时动态修改ES当前进程的nofile限制
prlimit --pid 2205 --nofile=655360:655360    #将pid进程的nofile限制调整为655360 

# docker run 方式修改进程句柄数限制
docker run -d -p 9200:9200 -p 9300:9300  --restart=always \
-e "discovery.type=single-node" \
-e ES_JAVA_OPTS="-Xms31g -Xmx31g" \
-e "xpack.security.enabled=false" \
--name elasticsearch \
--ulimit nofile=655350:655350  \...

作者这里是使用：临时修改进程最大句柄数的方式解决问题，修改后创建索引和查询数据的问题得到解决；

总结

这边只是记录作者这边问题的处理方式，目前为何句柄数会使用这么多还没找到问题，

查看了一篇文章的说法是：在系统扩容的过程中，会有大量的数据被平衡到新的节点，这样会消耗大量的IO，同时，elk集群中的新数据，由于没有对数据节点做冷热区分，会源源不断的写入到新节点，这就造成了新节点中的段会非常多，旧的段无法合并，新的数据又在源源不断的写入，这就造成了文件数会越来越多，因此出现了上述问题；目前不确定是不是这个原因，因为我是单机ES

参考链接：解决elasticsearch“Too many open files in system”问题-腾讯云开发者社区-腾讯云