背景:公司有个项目服务器为CentOS Linux release 7.6.1810 (Core) 通过supervisor 控制程序启动,最近频繁出现程序假死的情况,经过追加程序日志看到 :
accept() failed. Error: Too many open files[24]
统计当前进程打开文件数,发现只有1000个左右
lsof -p PID | wc -l
查看当前系统级最大文件数参数:
ulimit -a open files (-n) 1000000
查看/etc/security/limits.conf
# End of file * soft nproc 1000000 * hard nproc 1000000 * soft nofile 1000000 * hard nofile 1000000
查看/etc/security/limits.d/20-nproc.conf
* soft nproc 4096 root soft nproc unlimited
根据以上信息,暂时看不出问题,毕竟系统级打开文件数1000000 而进程设置至少也是4096,按理说不可能出现文件数不够的情况,继续排查当前进程的 limits文件
cat /proc/14453/limits Max open files 1024 1024 files
这里就看出问题来了,当前这个进程的最大打开文件数只有1024,不管哪个层面的设置都没有对其生效,由于是supervisor 管理的进程,所以联想到是否supervisor 对其进行了设置,查了官方文档信息的到了一个“minfds”参数,用于设置默认supervisor进程分配打开文件数,修改默认1024参数后重启supervisor
vim /etc/supervisord.conf minfds=10240
再次查看进程的limits信息就变更了。
centos7使用系统级设置不能全部控制所有应用的设置,而这个被supervisor 控制的程序更显得绕了个坑出来,supervisor在Linux中用于程序的控制还是很广泛,也算是积累了个经验。
转载请注明:菜鸟运维网 » supervisor 默认进程最大打开文件数的坑