【摘要】 Too many open files有四種可能:一 單個進程打開文件句柄數過多,二 操做系統打開的文件句柄數過多,三 systemd對該進程進行了限制,四 inotify達到上限.linux
領導見了孔乙己，也往往這樣問他，引人發笑。孔乙己本身知道不能和他們談天，便只好向咱們新員工說話。有一回對我說道，「你定位過問題麼？」我略略點一點頭。他說，「定位過，……我便考你一考。Too many open files，怎樣解決？」我想，考評墊底的人，也配考我麼？便回過臉去，再也不理會。孔乙己等了許久，很懇切的說道，「不能解決罷？……我教給你，記着！這些方法應該記着。未來作接口人的時候，定位問題要用。」我暗想我和接口人的等級還很遠呢，並且咱們領導也從不將問題定位記功；又可笑，又不耐煩，懶懶的答他道，「誰要你教，不是ulimit過小麼？」孔乙己顯出極高興的樣子，將兩個指頭的長指甲敲着白板，點頭說，「對呀對呀！……Too many open files有四種可能，你知道麼？」我愈不耐煩了，努着嘴走遠。孔乙己卻像是沒有看到，自顧自的在白板上畫了起來。url
一 單個進程打開文件句柄數過多
ulimit中的nofile表示單進程能夠打開的最大文件句柄數，能夠經過ulimit -a查看，子進程默認繼承父進程的限制（注意，是繼承，不是共享，子進程和父進程打開的文件句柄數是單獨算的）。spa
網上還有一種解讀是nofile表示單用戶能夠打開的文件句柄數，由於他們在limit.conf中看到相似於「openstack soft nofile 65536」，便認爲是openstack用戶最多能夠打開的文件句柄數。該解讀是錯誤的，「openstack soft nofile 65536」表示的含義是當你執行"su - openstack"切換到openstack用戶後，你建立的全部進程最大能夠打開的文件句柄數是65536。操作系統
要查看一個進程能夠打開的文件句柄數，能夠經過「cat /proc/<pid>/limits」查看。.net
要修改ulimit中的nofile，能夠經過修改/etc/security/limits.conf文件，在其中加入相似「openstack soft nofile 65536」的語句來進行修改。修改完成後，能夠經過「su - openstack」切換用戶，或者從新登陸，來使該配置生效。blog
要動態修改一個進程的限制，能夠使用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"來使該配置生效。get
四 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"。
做者：鯤鵬大賽-輔導老師