too many open files问题详解

一  单个进程打开文件句柄数过多linux

ulimit中的nofile表示单进程能够打开的最大文件句柄数,能够经过ulimit -a查看,子进程默认继承父进程的限制(注意,是继承,不是共享,子进程和父进程打开的文件句柄数是单独算的)。ide

网上还有一种解读是nofile表示单用户能够打开的文件句柄数,由于他们在limit.conf中看到相似于“openstack soft nofile 65536”,便认为是openstack用户最多能够打开的文件句柄数。该解读是错误的,“openstack soft nofile 65536”表示的含义是当你执行"su - openstack"切换到openstack用户后,你建立的全部进程最大能够打开的文件句柄数是65536。spa

要查看一个进程能够打开的文件句柄数,能够经过“cat /proc/<pid>/limits”查看。操作系统

要修改ulimit中的nofile,能够经过修改/etc/security/limits.conf文件,在其中加入相似openstack soft nofile 65536”的语句来进行修改。修改完成后,能够经过“su - openstack”切换用户,或者从新登陆,来使该配置生效。orm

要动态修改一个进程的限制,能够使用prlimit命令,具体用法为:“prlimit --pid ${pid} --nofile=102400:102400”。blog


二 操做系统打开的文件句柄数过多继承

整个操做系统能够打开的文件句柄数是有限的,受内核参数“fs.file-max”影响。进程

能够经过执行“echo 100000000 > /proc/sys/fs/file-max”命令来动态修改该值,也能够经过修改"/etc/sysctl.conf"文件来永久修改该值。ci


三 systemd对该进程进行了限制get

该场景仅针对被systemd管理的进程(也就是能够经过systemctl来控制的进程)生效,能够经过修改该进程的service文件(一般在/etc/systemd/system/目录下),在“[Service]”下面添加“LimitNOFILE=20480000”来实现,修改完成以后须要执行"systemctl daemon-reload"来使该配置生效。


四 inotify达到上限

inotify是linux提供的一种监控机制,能够监控文件系统的变化。该机制受到2个内核参数的影响:“fs.inotify.max_user_instances”和“fs.inotify.max_user_watches”,其中fs.inotify.max_user_instances”表示每一个用户最多能够建立的inotify instances数量上限,fs.inotify.max_user_watches”表示么个用户同时能够添加的watch数目,当出现too many open files问题而上面三种方法都没法解决时,能够尝试经过修改这2个内核参数来生效。修改方法是修改"/etc/sysctl.conf"文件,并执行"sysctl -p"。

转载自华为云社区

相关文章
相关标签/搜索