服务器评测
在开发运维的时候我们常常会遇到类似“Socket/File: Can’t open so many files”，“无法打开更多进程”，或是coredump过大等问题，这些都可以设置资源限制来解决。今天在教某位客户设置最大文件数方法时，搜索网上的方法时发现各家说法并不一致，便写了这篇文档。
通常对Linux某个用户设置系统资源，我们都已经知道可以用ulimit命令来查看和设置。
表 1. ulimit 参数说明
| 选项 [options] | 含义 | 例子 |
| -H | 设置硬资源限制，一旦设置不能增加。 | ulimit – Hs 64；限制硬资源，线程栈大小为 64K。 |
| -S | 设置软资源限制，设置后可以增加，但是不能超过硬资源设置。 | ulimit – Sn 32；限制软资源，32 个文件描述符。 |
| -a | 显示当前所有的 limit 信息。 | ulimit – a；显示当前所有的 limit 信息。 |
| -c | 最大的 core 文件的大小， 以 blocks 为单位。 | ulimit – c unlimited； 对生成的 core 文件的大小不进行限制。 |
| -d | 进程最大的数据段的大小，以 Kbytes 为单位。 | ulimit -d unlimited；对进程的数据段大小不进行限制。 |
| -f | 进程可以创建文件的最大值，以 blocks 为单位。 | ulimit – f 2048；限制进程可以创建的最大文件大小为 2048 blocks。 |
| -l | 最大可加锁内存大小，以 Kbytes 为单位。 | ulimit – l 32；限制最大可加锁内存大小为 32 Kbytes。 |
| -m | 最大内存大小，以 Kbytes 为单位。 | ulimit – m unlimited；对最大内存不进行限制。 |
| -n | 可以打开最大文件描述符的数量。 | ulimit – n 128；限制最大可以使用 128 个文件描述符。 |
| -p | 管道缓冲区的大小，以 Kbytes 为单位。 | ulimit – p 512；限制管道缓冲区的大小为 512 Kbytes。 |
| -s | 线程栈大小，以 Kbytes 为单位。 | ulimit – s 512；限制线程栈的大小为 512 Kbytes。 |
| -t | 最大的 CPU 占用时间，以秒为单位。 | ulimit – t unlimited；对最大的 CPU 占用时间不进行限制。 |
| -u | 用户最大可用的进程数。 | ulimit – u 64；限制用户最多可以使用 64 个进程。 |
| -v | 进程最大可用的虚拟内存，以 Kbytes 为单位。 | ulimit – v 200000；限制最大可用的虚拟内存为 200000 Kbytes。 |
当然我们都知道Linux大部分的命令设置都是临时生效，而且ulimit命令只对当前终端生效，如果需要永久生效的话，我们有两种方法，一种是将命令写至profile和bashrc中，在有些网页中说写到rc.local，其实是不对的；还有一种就是在limits.conf中添加记录（需重启生效，并且在/etc/pam.d/中的seesion有使用到limit模块）。接下来讨论的就是在limits.conf用户最大文件打开数限制的相关内容。
针对用户打开最大文件数的限制， 在limits.conf对应的nofile，不管是man手册还是文件中说明都只是一句话“maximum number of open files”，它其实对应是单个进程能打开的最大文件数，通常为了省事，我们想取消它的限制，根据man手册中，“values -1, unlimited or infinity indicating no limit”，-1、unlimited、infinity都是表明不做限制，可是当你实际给nofile设置成这个值，等你重启就会发现无法登录系统了。
由此可见，nofile是有一个上限的，同时用ulimit测试：
#ulimit -n unlimited
bash: ulimit: open files: cannot modify limit: 不允许的操作
写一个简单的for循环得出：
#for V in `seq 100000 10000000`;do ulimit -n $V；[[ $? != 0 ]]&&break;done
再执行ulimit -n ，可以看到1048576就是nofile的最大值了，但为什么是这个值？1048576是1024*1024，当然这并没有什么卵用。。。再跟踪一下我们就会发现这个值其实是由内核参数nr_open定义的：
# cat /proc/sys/fs/nr_open
1048576
到此我们就要说起nr_open，与file-max了，网上在说到设置最大文件数时偶尔有些帖子也说到要修改file-max，字面上看file-max确实像是对应最大文件数，而在Linux内核文档中它们两的解释是：
file-max：
The value in file-max denotes the maximum number of file-
handles that the Linux kernel will allocate. When you get lots
of error messages about running out of file handles, you might
want to increase this limit
执行：grep -r MemTotal /proc/meminfo | awk ‘{printf(“%d”,$2/10)}’，可以看到与file-max是相近的；
nr_open:
This denotes the maximum number of file-handles a process can
allocate. Default value is 1024*1024 (1048576) which should be
enough for most machines. Actual limit depends on RLIMIT_NOFILE
resource limit.
额，到此笔者有点晕了，file-handles（即文件句柄），然后相比而言在UNIX/LINUX中我们接触更多是file discriptor（FD，即文件描述符)，通过百度搜索，似乎file-handle在windows中是一个类似file discrptor的东东，但是我们讨论的是linux，再google一下，我们可以精确到c语言中这两个概念的区别，据他们的讨论file-handle应该是一个高层的对象，使用fopen，fread等函数来调用，而FD是底层的一个对象，可以通过open，read等函数来调用。
到此，我们应该可以下一个大致的结论了，file-max是内核可分配的最大文件数，nr_open是单个进程可分配的最大文件数，所以在我们使用ulimit或limits.conf来设置时，如果要超过默认的1048576值时需要先增大nr_open值（sysctl -w fs.nr_open=100000000或者直接写入sysctl.conf文件）。当然百万级别的单进程最大file-handle打开数应该也够用了吧。。
由于笔者水平有限，内容难免有错漏之处，还有file-max的默认值为何会比nr_open值要小也没有再深入追究，欢迎大家来讨论交流。
本文永久更新链接地址：http://www.linuxidc.com/Linux/2015-10/124223.htm
