Linux下设置最大文件打开数nofile及nr_open、file-max

时间：2022-11-21 16:54:44

在开发运维的时候我们常常会遇到类似“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其实就是对单一程序的限制,进程级别的

file-max是所有时程最大的文件数

nr_open是单个进程可分配的最大文件数

[root@server-mysql fs]# ulimit -n unlimited

-bash: ulimit: open files: cannot modify limit: Operation not permitted

[root@server-mysql fs]# 
[root@server-mysql fs]# ulimit -n 1048576

[root@server-mysql fs]# ulimit -n 1048577

-bash: ulimit: open files: cannot modify limit: Operation not permitted

[root@server-mysql fs]# cat /proc/sys/fs/nr_open

1048576
[root@server-mysql fs]# echo 1000000 > /proc/sys/fs/nr_open

[root@server-mysql fs]# cat /proc/sys/fs/nr_open

1000000

[root@server-mysql fs]# ulimit -n 999999

[root@server-mysql fs]# ulimit -n 1000000

[root@server-mysql fs]# ulimit -n 1000001

-bash: ulimit: open files: cannot modify limit: Operation not permitted
?
[root@server-mysql fs]# cat file-nr

2496    0       132022

[root@server-mysql fs]# cat file-max

132022
[root@server-mysql fs]# echo 2000000 >file-max

[root@server-mysql fs]# cat file-nr

2496    0       2000000
man 5 proc:
 /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:

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

              The kernel constant NR_OPEN imposes an upper limit on the value that may be placed in  file-

              max.

              If  you  increase  /proc/sys/fs/file-max,  be sure to increase /proc/sys/fs/inode-max to 3-4

              times the new value of /proc/sys/fs/file-max, or you will run out of inodes.

 /proc/sys/fs/file-nr

              This (read-only) file gives the number of files presently opened.  It  contains  three  num-

              bers: the number of allocated file handles; the number of free file handles; and the maximum

              number of file handles.  The kernel allocates file handles dynamically, but it doesn’t  free

              them  again.   If the number of allocated files is close to the maximum, you should consider

              increasing the maximum.  When the number of free file handles is large, you’ve encountered a

              peak in your usage of file handles and you probably don’t need to increase the maximum.
ulimit中硬限制是实际的限制，而软限制，是warnning限制，只会做出warning，其实ulimit命令本身就有分软硬设置，加-H就是硬，加-S就是软。

默认显示的是软限制，如果修改的时候没有加上的话，就是两个一起改

配置文件最前面的一位是domain，设置为星号代表全局，另外你也可以针对不同的用户做出不同的限制

ulimit其实就是对单一程序的限制,进程级别的

系统总限制:/proc/sys/fs/file-max

通过 man 5 proc 找到file-max的解释：
file-max指定了系统范围内所有进程可以打开的文件句柄的数量限制---kernel-level

可以通过cat查看目前的值，echo来立刻修改

echo 10000 >    /proc/sys/fs/file-max
另外还有一个，/proc/sys/fs/file-nr

只读，可以看到整个系统目前使用的文件句柄数量

写一个简单的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-max是内核可分配的最大文件数，nr_open是单个进程可分配的最大文件数，所以在我们使用ulimit或limits.conf来设置时，

如果要超过默认的1048576值时需要先增大nr_open值（sysctl -w fs.nr_open=100000000或者直接写入sysctl.conf文件）。

当然百万级别的单进程最大file-handle打开数应该也够

相关文章