file-max与ulimit的关系与差别

1. file-max的含义

man proc，可得到file-max的描述：

/proc/sys/fs/file-max

This file defines a system-wide limit on the number of open files for all processes. (See

also setrlimit(2), which can be used by a process to set the per-process limit,

RLIMIT_NOFILE, on the number of files it may open.) If you get lots of error messages

about running out of file handles, try increasing this value:

即file-max是设置 系统所有进程一共可以打开的文件数量 。同时一些程序可以通过setrlimit调用，设置每个进程的限制。如果得到大量使用完文件句柄的错误信息，是应该增加这个值。

也就是说，这项参数是系统级别的。

echo 6553560 > /proc/sys/fs/file-max

或修改 /etc/sysctl.conf, 加入

fs.file-max = 6553560 重启生效

[System-wide File Descriptors (FD) Limits

The number of concurrently open file descriptors throughout the system can be changed via /etc/sysctl.conf file under Linux operating systems.]

2. ulimit的

Provides control over the resources available to the shell and to processes started by it, on systems that allow such control.

即设置当前shell以及由它启动的进程的资源限制。

显然，对服务器来说，file-max, ulimit都需要设置，否则就可能出现文件描述符用尽的问题，为了让机器在重启之后仍然有效，强烈建立作以下配置，以确保file-max, ulimit的值正确无误：

1. 修改/etc/sysctl.conf, 加入

fs.file-max = 6553560

2.系统默认的ulimit对文件打开数量的限制是1024，修改/etc/security/limits.conf并加入以下配置，永久生效

* soft nofile 65535

* hard nofile 65535

3.nr_open是单个进程可分配的最大文件数，所以在使用ulimit或limits.conf来设置时，如果要超过默认的1048576值时需要先增大nr_open值（sysctl -w fs.nr_open=100000000或者直接写入sysctl.conf文件）

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.

修改完之后，重启即可生效

[User Level FD Limits

The above procedure sets system-wide file descriptors (FD) limits. However, you can limit httpd (or any other users) user to specific limits by editing /etc/security/limits.conf file]
3,nofile的最大值就是nr_open的值，默认是1024*1024

/etc/security/limits.conf nofile absolute maximum

Apparently unlimited != unlimited in the Linux kernel for maximum number of open files. After some extensive digging, I finally found the actual maximum to the nofile setting in /etc/security/limits.conf. Yes I was searching in the context of Oracle (Imagine
that) for a maximum number of procs / files. The Linux kernel has a hard upper limit of 1024*1024 (1048576 – a magical number I won’t soon forget).

Consider the following:

[root@localhost ~]# grep mrsmith /etc/security/limits.conf

mrsmith soft nofile unlimited

mrsmith hard nofile unlimited

Trying to su to mrsmith suddenly casts you aside:

[root@localhost ~]# su - mrsmith

could not open session

Displaying the open file setting for mrsmith shows something odd:

[root@localhost ~]# ulimit -au mrsmith

...

open files (-n) 1024

Why would our number of open files be 1024? This apparently is the default setting for users without a custom nofile set based on the following bugzilla.

Then what is our actual upper bound for nofile in /etc/security/limits.conf? This isn’t well documented anywhere I’ve seen, but based on some research it appears to be 1024*1024. Setting nofile to 1048577 produces the same “could not open session” error as
mentioned previously. 1048576 however seems to work just fine. Although you can set your nofile ulimit to this, the effects of such are unknown and I would highly recommend testing any such setting.