ulimit control

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。因此可以用上面的公式来简单估算。