一 單個程式開啟檔案控制程式碼數過多
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"。
