近期使用Linux操作系统的时候用到了多进程，导致同一时间内文件打开数量超过限制，从而导致进程卡死问题，在网上找到了以下解决方法

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

ulimit中的nofile表示单进程可以打开的最大文件句柄数，可以通过ulimit -a查看，子进程默认继承父进程的限制（注意，是继承，不是共享，子进程和父进程打开的文件句柄数是单独算的）。
网上还有一种解读是nofile表示单用户可以打开的文件句柄数，因为他们在limit.conf中看到类似于openstack soft nofile 65536，便认为是openstack用户最多可以打开的文件句柄数。该解读是错误的，openstack soft nofile 65536表示的含义是当你执行su - openstack切换到openstack用户后，你创建的所有进程最大可以打开的文件句柄数是65536。
要查看一个进程可以打开的文件句柄数，可以通过cat /proc/<pid>/limits查看。

要修改ulimit中的nofile，可以通过修改/etc/security/limits.conf文件，在其中加入类似openstack soft nofile 65536的语句来进行修改。修改完成后，可以通过su - openstack切换用户，或者重新登录，来使该配置生效。

要动态修改一个进程的限制，可以使用prlimit命令，具体用法为：prlimit --pid ${pid} --nofile=102400:102400。

操作系统打开的文件句柄数过多

整个操作系统可以打开的文件句柄数是有限的，受内核参数fs.file-max影响。
可以通过执行echo 100000000 > /proc/sys/fs/file-max命令来动态修改该值，也可以通过修改/etc/sysctl.conf文件来永久修改该值。

systemd对该进程进行了限制、

该场景仅针对被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。