ES报错too-many-open-files解决

ElasticSearch 服务挂了，挂可不是进程没了，因为有 Supervisor 保护，而是服务不可用了。以前曾经出现过一次因为 ES_HEAP_SIZE 设置不当导致的服务不可用故障，于是我惯性的判断应该还是 ES_HEAP_SIZE 的问题，不过登录服务器后发现日志里显示大量的「Too many open files」错误信息。那么 ElasticSearch 设置的最大文件数到底是多少呢？可以通过 proc 确认：

shell> cat /proc/<PID>/limits

结果是「4096」，我们还可以进一步看看 ElasticSearch 打开的都是什么东西：

shell> ls /proc/<PID>/fd

问题看上去非常简单，只要加大相应的配置项应该就可以了。此配置在 ElasticSearch 里叫做 MAX_OPEN_FILES，可惜配置后发现无效。按我的经验，通常此类问题多半是由于操作系统限制所致，可是检查结果一切正常：

shell> cat /etc/security/limits.conf

* soft nofile 65535
* hard nofile 65535

问题进入了死胡同，于是我开始尝试找一些奇技淫巧看看能不能先尽快缓解一下，我搜索到 @-神仙- 的一篇文章：动态修改运行中进程的 rlimit，里面介绍了如何动态修改阈值的方法，虽然我测试时都显示成功了，可惜 ElasticSearch 还是不能正常工作：

shell> echo -n 'Max open files=65535:65535' > /proc/<PID>/limits

此外，我还检查了系统内核参数 fs.file-nr 及 fs.file-max，总之一切和文件有关的参数都查了，甚至在启动脚本里硬编码「ulimit -n 65535」，但一切努力都显得毫无意义。正当山穷水尽疑无路的时候，同事 @轩脉刃 一语道破玄机：关闭 Supervisor 的进程管理机制，改用手动方式启动 ElasticSearch 进程试试看。结果一切恢复正常。为什么会这样呢？因为使用 Supervisor 的进程管理机制，它会作为父进程 FORK 出子进程，也就是 ElasticSearch 进程，鉴于父子关系，子进程允许打开的最大文件数不能超过父进程的阈值限制，但是 Supervisor 中 minfds 指令缺省设置的允许打开的最大文件数过小，进而导致 ElasticSearch 进程出现故障。此故障原因本来非常简单，但我却陷入了经验主义的固定思维，值得反思。

在Linux下面部署应用的时候，有时候会遇上Socket/File: Can’t open so many files的问题；这个值也会影响服务器的最大并发数，其实Linux是有文件句柄限制的，而且Linux默认不是很高，一般都是1024，生产服务器用其实很容易就达到这个数量。下面说的是，如何通过正解配置来改正这个系统默认值。

查看方法

我们可以用ulimit -a来查看所有限制值
[root@centos5 ~]# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
max nice                        (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 4096
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
max rt priority                 (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 4096
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited||<

其中 "open files (-n) 1024 "是Linux操作系统对一个进程打开的文件句柄数量的限制

(也包含打开的SOCKET数量，可影响MySQL的并发连接数目)。

 

正确的做法，应该是修改/etc/security/limits.conf
里面有很详细的注释，比如
Hadoop  soft   nofile   32768
hadoop hard nofile 65536

hadoop soft   nproc   32768
hadoop hard nproc 65536
就可以将文件句柄限制统一改成软32768，硬65536。配置文件最前面的是指domain，设置为星号代表全局，另外你也可以针对不同的用户做出不同的限制。

注意：这个当中的硬限制是实际的限制，而软限制，是warnning限制，只会做出warning；其实ulimit命令本身就有分软硬设置，加-H就是硬，加-S就是软
默认显示的是软限制，如果运行ulimit命令修改的时候没有加上的话，就是两个参数一起改变。

RHE6及以后 nproc的修改在/etc/security/limits.d/90-nproc.conf中

补充说明：

soft nproc: 可打开的文件描述符的最大数(软限制)

hard nproc： 可打开的文件描述符的最大数(硬限制)

soft nofile：单个用户可用的最大进程数量(软限制)

hard nofile：单个用户可用的最大进程数量(硬限制)