Linux系統的檔案控制代碼數量問題

在Linux下面部署應用的時候，有時候會遇上Socket/File: Can’t open so many files的問題，其實Linux是有檔案控制代碼限制的（就像WinXP？），而且預設不是很高，一般都是1024，作為一台生產伺服器，其實很容易就達到這個數量，因此我們需要把這個值改大一些。

大概知道ulimit這個命令是相關的，上Google搜尋了一下，大多數說的很含糊，也沒有統一說一下，經過兩個小時看了不少文章終於弄清楚ulimit相關的一些配置問題。

我們可以用ulimit -a來查看所有限制值，我只關心檔案控制代碼數量的問題

open files (-n) 1024

這個就是限制數量

這裡，有很多ulimit的文章都說的很含糊，究竟這個1024是系統的限制，還是使用者的限制呢。其實，這個是使用者限制來的，完整的說法，應該是目前使用者準備要啟動並執行程式的限制。

1、這個限制是針對單個程式的限制

2、這個限制不會改變之前已經運行了的程式的限制

3、對這個值的修改，退出了當前的shell就會消失

比如說，我先運行了一個程式A，然後通過ulimit修改了限制為2048，然後運行B，然後退出了shell再登入，然後運行C。那就只有B可以開啟2048個控制代碼。

如果我們需要改變整體的限制值，或者我們啟動並執行程式是系統啟動的，應該怎麼處理呢

其中一個方法，是想ulimit修改命令放入/etc/profile裡面，但是這個做法並不好

正確的做法，應該是修改/etc/security/limits.conf

裡面有很詳細的注釋，比如

* soft nofile 2048

* hard nofile 32768

就可以將檔案控制代碼限制統一改成軟2048，硬32768

這裡涉及另外一個問題，什麼是軟式節流，什麼是硬限制

硬限制是實際的限制，而軟式節流，是warnning限制，只會做出warning

其實ulimit命令本身就有分軟硬設定，加-H就是硬，加-S就是軟

預設顯示的是軟式節流，如果修改的時候沒有加上的話，就是兩個一起改

設定檔最前面的一位是domain，設定為星號代表全域，另外你也可以針對不同的使用者做出不同的限制

修改了，重新登入用ulimit一開就立刻生效了，不過之前啟動過的程式要重新啟動才能使用新的值。我用的是CentOS，似乎有些系統需要重啟才會生效。

ulimit其實就是對單一程式的限制

那系統總限制呢

其實是在這裡，/proc/sys/fs/file-max

可以通過cat查看目前的值，echo來立刻修改

另外還有一個，/proc/sys/fs/file-nr

唯讀，可以看到整個系統目前使用的檔案控制代碼數量

尋找檔案控制代碼問題的時候，還有一個很實用的程式lsof

可以很方便看到某個進程開了那些控制代碼

也可以看到某個檔案/目錄被什麼進程佔用了。

（責任編輯：雲子）