现网近期发现一台业务主机进程频繁挂掉,然后会被watchdog自动拉起,运行一小段时间后又挂掉,不断重新启动,排查日志发现"Too many open files" ,打开文件数量超过文件句柄数了。
使用ulimit -a检查,配置的open files数量为100万,查看/etc/system.conf里面的fs.file-max=999999,ulimit检查是单进程允许打开文件数,system.conf检查是操作系统允许打开的文件数,使用lsof查看打开的文件和进程情况,发现增长较快,进程启动后很快能涨到30万左右,然后没到100万的情况下就又报错重启了,对30万打开文件进行分析,发现有很多都是不同线程打开的同一个文件,这种情况其实只消耗一个open files,那就还远没有达到100万的限制,日志与实际情况不吻合。
求助组内操作系统专家,指出了当前使用lsof查看已使用的文件句柄和使用ulimit -a查看进程允许打开的文件的方式并非完全可靠的,正确的方式应该是通过cat /proc/pid/limits来查看进程允许文件句柄数,并使用ll /proc/pid/fd | wc -l 来统计进程当前已打开的文件数量,发现limits下面的Max open files配置Soft Limit是1024,而Hard Limit是4096,远小于100万,而通过ll /proc/pid/fd | wc -l 查看也正是在接近4096时日志报错,进程重启,问题清晰了。
但为何进程的最大文件句柄数是4096不是unlimit -a 查看的100万呢,和操作系统专家进一步分析,业务进程是通过watchdog拉起的,用同样的方式查看watchdog的配置,Hard Limit也是4096,查看watchdog启动时间是最近一周,因为watchdog是配置过开机启动的,随即检查了主机启动时间,发现主机本周重启过,而watchdog正是主机重启后被自动拉起的。
业务使用CentOS操作系统,并配置使用systemctl方式的开机启动,所以watchdog进程被自动拉起时应该是使用的/etc/systemd/system.conf中的配置而非unlimit -a查看到的配置,unlimit -a查看的实际是/etc/security/limit.conf中的配置,此处配置是针对shell的,如果crontab 定时任务通过shell去拉起watchdog,则文件句柄限制应该是100万,但是使用systemctl方式就与此100万的配置无关了,为验证猜想,执行cat /etc/systemd/system.conf | grep -i "open file",果然得到DefaultLimitNOFILE=4096的配置,此时执行systemctl show xxxx.service | grep FILE 查看,果然得到LimitNOFILE=4096
解决方案:
1. 修改操作系统配置:sudo vi /etc/systemd/system.conf 改为100万,然后执行sudo systemctl daemon-reload重亲加载配置
2. 修改业务配置,sudo vi /etc/systemd/system/xxxx.service,添加LimitNOFILE=1000000,然后执行sudo systemctl daemon-reload重亲加载配置
疑问:
被watchdog拉起的业务进程需要和watchdog的limit一致吗,是什么机制?
备注:
1. Soft Limit只作出警告,Hard Limit是实际限制
2. 系统总限制:/proc/sys/fs/file-max,也可以在system.conf中查看file-max,可以通过cat查看目前的值,echo来立刻修改
/proc/sys/fs/file-nr,只读,可以看到整个系统目前使用的文件句柄数量