Linux系統資源限制

Linux系統資源限制

1. 最大檔案數

檢視程序允許打開的最大檔案句柄數：ulimit -n

檢視程序所占的檔案描述符： lsof -p xxx | wc -l

設定程序能打開的最大檔案句柄數：ulimit -n xxx

2. ulimit -n vs. file-max ?

簡單的說， ulimit -n控制程序級别能夠打開的檔案句柄的數量， 而max-file表示系統級别的能夠打開的檔案句柄的數量。

ulimit -n的設定在重新開機機器後會丢失，是以需要修改limits.conf的限制，limits.conf中有兩個值soft和hard，soft代表隻警告，hard代表真正的限制

Cat /etc/security/limits.conf代碼 

*               soft    nofile          150000 

*               hard    nofile          150000 

這裡我們把soft和hard設定成一樣的。

“cat /proc/sys/fs/file-max”，或“sysctl -a | grep fs.file-max”檢視系統能打開的最大檔案數。檢視和設定例如：

Shell代碼 

[root@vm014601 ~]# sysctl -a |grep fs.file-max 

fs.file-max = 200592 

[root@vm014601 ~]# echo "fs.file-max = 2005920" >> /etc/sysctl.conf  

[root@vm014601 ~]# sysctl -p 

[root@vm014601 ~]# cat /proc/sys/fs/file-max                         

2005920 

file-nr是隻讀檔案，第一個數代表了目前配置設定的檔案句柄數；第二個數代表了系統配置設定的最大檔案句柄數；比如線上系統檢視結果：

# cat /proc/sys/fs/file-max 

1106537 

# cat /proc/sys/fs/file-nr      

1088  0       1106537 

# lsof | wc -l 

1506 

可以看到file-nr和lsof的值不是很一緻，但是數量級一緻。為什麼會不一緻？原因如下：

寫道

lsof是列出系統所占用的資源，但是這些資源不一定會占用打開檔案号的.

比如共享記憶體，信号量，消息隊列，記憶體映射等，雖然占用了這些資源，但不占用打開檔案号。

我曾經在前端機上很長時間都無法得到lsof | wc -l 的結果，這個時候可以通過file-nr粗略的估算一下打開的檔案句柄數。

3. sysckernel.threads-max

指定了核心所能使用的線程（所有程序打開線程之和）的最大數目，通過指令 “cat /proc/sys/kernel/threads-max” 檢視目前值。檢視和設定例如：

sysctl -a | grep threads 

vm.nr_pdflush_threads = 2 

kernel.threads-max = 229376 

本廠系統配置允許打開的線程數 > 229k

如果此值設小了會導緻：-bash: fork: Resource temporarily unavailable

4. 為什麼有限制？

為什麼Linux核心對檔案句柄數、線程和程序的最大打開數進行了限制？以及如果我們把它調的太大，會産生什麼樣的後果？

原因1 - 資源問題：the operating system needs memory to manage each open file， and memory is a limited resource - especially on embedded systems.

原因2 - 安全問題：if there were no limits， a userland software would be able to create files endlessly until the server goes down.

最主要的是資源問題，為防止某一單一程序打開過多檔案描述符而耗盡系統資源，對程序打開檔案數做了限制。

5. 設定成多少比較合适？

網上有朋友給了估算公式：file-max number = RAM size/10k；

I am not a kernel expert， but as far as I can see， the default for file-max seems to be RAM size divided by 10k. As the real memory used per file handler should be much smaller (size of struct file plus some driver dependent memory)， this seems a quite conservative limit. – jofel Apr 19 at 16:43

那麼一個12G RAM 的前端機可以打開接近1M的檔案。真的可以打開1百萬個檔案嗎？

為了試驗，基于MINA寫了一個NIO服務，在一個服務上建立了50萬活躍率約為1%的TCP連接配接。觀察記憶體使用 < 4.5G，可以粗略認為單個socket連接配接使用記憶體小于10K。是以可以用上面的公式來簡單估算。

原文

http://maoyidao.iteye.com/blog/1744309