在Linux下面部署應用的時候,有時候會遇上Socket/File: Can’t open so many files的問題;這個值也會影響伺服器的最大並發數,其實Linux是有檔案控制代碼限制的,而且Linux預設不是很高,一般都是1024,生產伺服器用其實很容易就達到這個數量。下面說的是,如何通過正解配置來改正這個系統預設值。因為這個問題是我配置Nginx+php5時遇到了,所以我將這篇歸納進nginx+apache篇。
查看方法
我們可以用ulimit -a來查看所有限制值
[root@centos5 ~]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
max nice (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 4096
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
max rt priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 4096
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited||<
其中 "open files (-n) 1024 "是Linux作業系統對一個進程開啟的檔案控制代碼數量的限制(也包含開啟的SOCKET數量,可影響MySQL的並發串連數目)。這個值可用ulimit命令來修改,但ulimit命令修改的數值只對當前登入使用者的目前使用環境有效,系統重啟或者使用者退出後就會失效(在布署Nginx+FastCGI我就遇到這個問題,將ulimit -SHn 65535放到/etc/rc.d/rc.local也沒起什麼作用)
系統總限制是在這裡,/proc/sys/fs/file-max。可以通過cat查看目前的值,修改/etc/sysctl.conf 中也可以控制。
另外還有一個,/proc/sys/fs/file-nr,可以看到整個系統目前使用的檔案控制代碼數量。
尋找檔案控制代碼問題的時候,還有一個很實用的程式lsof。可以很方便看到某個進程開了那些控制代碼,也可以看到某個檔案/目錄被什麼進程佔用了。
修改方法
若要令修改ulimits的數值永久生效,則必須修改配置文檔,可以給ulimit修改命令放入/etc/profile裡面,這個方法實在是不方便,還有一個方法是修改/etc/sysctl.conf。我修改了,測試過,但對使用者的ulimits -a 是不會改變的,只是/proc/sys/fs/file-max的值變了。
我認為正確的做法,應該是修改/etc/security/limits.conf
裡面有很詳細的注釋,比如
* soft nofile 32768
* hard nofile 65536
就可以將檔案控制代碼限制統一改成軟32768,硬65536。設定檔最前面的是指domain,設定為星號代表全域,另外你也可以針對不同的使用者做出不同的限制。
注意:這個當中的硬限制是實際的限制,而軟式節流,是warnning限制,只會做出warning;其實ulimit命令本身就有分軟硬設定,加-H就是硬,加-S就是軟
預設顯示的是軟式節流,如果運行ulimit命令修改的時候沒有加上的話,就是兩個參數一起改變。
生效
因為我平時工作最多的是部署web環境(Nginx+FastCGI外網生產環境和內網開發環境),重新登陸即可(reboot其實也行)我分別用root和www使用者登陸,用ulimit -a分別查看確認,做這之前最好是重啟下ssh服務,service sshd restart。