Linux最大檔案開啟數的正確修改姿勢__Linux

原貼地址：

https://segmentfault.com/a/1190000006880817

前幾天查看heka日誌的錯誤記錄檔的時候，發現報錯資訊 too many open files，很明顯開啟檔案數過多了。

第一個問題來了，如何查看當前進程開啟的檔案數和最大開啟檔案數呢。

當前進程開啟檔案數 

ls /proc/[pid]/fd|wc -l

當前進程最大開啟檔案數
cat /proc/[pid]/limits|grep open

可以看到如下所示的輸出：

Max open files            1024                 4096                 files

當前系統最大開啟檔案數
ulimit -n

第二個問題是我該如何修改進程的最大檔案開啟數呢。
找到最大檔案開啟數的設定方法，這個問題也就解決了，通常有下面幾種修改方式：
1)ulimit -n 102400 直接使用ulimit命令修改，但這個只會對當前會話生效，終端關閉後，設定丟失。
2)/etc/security/limitd.conf 檔案中增加limits的配置，一般如下：

*               soft   nofile       102400

配置的具體含義，大家自行搜尋。/etc/security/limitd.conf 在每一個會話建立時都會載入，所以修改這裡是一個使配置長期生效的方法。
3)修改shell的啟動項，將ulimit -n 102400放進去，每次建立會話時也會載入。一般是/etc/profile檔案，或者/etc/profile.d/limits.sh中。

到此為止，配置好了，你通過 ulimit -n 查看系統的最大檔案開啟數已經生效了。但此時查看進程的最大檔案開啟數沒有變，原因是這個值是在進程啟動的時候設定的，要生效必須重啟。

ok，那就重啟吧，重啟完畢，結果發現依然沒變。這奇了怪了，後來經過好久的排查，最終確認問題是，該程式是通過 supervisord來管理的，也就是這進程都是 supervisord 的子進程，而 supervisord 的最大檔案開啟數還是老的配置，此時必須重啟 supervisord 才可以。後來在saltstack上也遇到了同樣的問題，必須把所有的 salt-minion 重啟。

當大家遇到limits修改不生效的時候，請查一下進程是否只是子進程，如果是，那就要把父進程也一併重啟才可以。