linux系統層級的能夠開啟的檔案控制代碼的數file-max命令

來源:互聯網
上載者:User

 簡單的說, max-file表示系統層級的能夠開啟的檔案控制代碼的數量, 而ulimit -n控制進程層級能夠開啟的檔案控制代碼的數量.

man 5 proc, 找到file-max的解釋:
file-max中指定了系統範圍內所有進程可開啟的檔案控制代碼的數量限制(系統層級, kernel-level). (The value in file-max denotes the maximum number of file handles that the Linux kernel will allocate).當收到”Too many open files in system”這樣的錯誤訊息時, 就應該曾加這個值了.

# cat /proc/sys/fs/file-max
185230
# echo 100000 > /proc/sys/fs/file-max

或者
# echo ""fs.file-max=65535" >> /etc/sysctl.conf
# sysctl -p

The kernel constant NR_OPEN imposes an upper limit on the value that may be placed in file-max. (這句啥子意思? 沒太明白)

對於2.2的核心, 還需要考慮inode-max, 一般inode-max設定為file-max的4倍. 對於2.4及以後的核心, 沒有inode-max這個檔案了.

file-nr 可以查看系統中當前開啟的檔案控制代碼的數量. 他裡麵包括3個數字: 第一個表示已經分配了的檔案描述符數量, 第二個表示閒置檔案控制代碼數量, 第三個表示能夠開啟檔案控制代碼的最大值(跟file-max一致). 核心會動態分配檔案控制代碼, 但是不會再次釋放他們(這個可能不適應最新的核心了, 在我的file-nr中看到第二列一直為0, 第一列有增有減)

man bash, 找到說明ulimit的那一節:
提供對shell及其啟動的進程的可用資源(包括檔案控制代碼, 進程數量, core檔案大小等)的控制. 這是進程層級的, 也就是說系統中某個session及其啟動的每個進程能開啟多少個檔案描述符, 能fork出多少個子進程等…

當達到上限時, 會報錯”Too many open files”或者遇上Socket/File: Can’t open so many files等

另外需要注意的是, 每種資源都有相關的軟硬限制, 軟式節流是核心強加給相應資源的限制值,硬限制是軟式節流的最大值. 非授權調用進程只可以將其軟式節流指定為0~硬限制範圍中的某個值,同時能無法復原轉地降低其硬限制.授權進程可以任意改變其軟硬限 制.RLIM_INFINITY的值表示不對資源限制.

分別使用-H和-S選項來指定需要對資源是做硬限制/軟式節流的設定. 如果都不指定, 硬限制和軟式節流同時設定.

列印資源的限制值, 如果不明確指定-H, 列印的是-S

要改apache的ulimit, 可以在 /usr/sbin/apachectl 這個指令碼中修改 ULIMIT_MAX_FILES 這個值

可開啟檔案控制代碼數設定的太大, 有那些危害:
If the file descriptors are tcp sockets, etc, then you risk using up a large amount of memory for the socket buffers and other kernel objects; this memory is not going to be swappable.

另外要記得的是socket connection也是檔案.
相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

Tags Index: