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是唯讀檔案，第一個數代表了目前分配的檔案控制代碼數；第二個數代表了系統分配的最大檔案控制代碼數；比如線上系統查看結果：

Shell代碼 

# 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” 查看當前值。查看和設定例如：

Shell代碼 

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