第3期：Too many open files以及ulimit的探讨

Java、AI、互联网、金融

10 人赞同了该文章

Too many open files是Java常见的异常，通常是由于系统配置不当或程序打开过多文件导致。这个问题常常又与ulimit的使用相关。关于ulimit的用法有不少坑，本文将遇到的坑予以梳理。

Too many open files异常

下面是Java程序，系统超过最大打开文件数时的异常堆栈：

Exception in thread "main" java.io.IOException: Too many open files

    at java.io.UnixFileSystem.createFileExclusively(Native Method)

    at java.io.File.createTempFile(File.java:2024)

    at java.io.File.createTempFile(File.java:2070)

    at com.imshuai.wiki.ulimit.App.main(App.java:16)

如果不是程序问题（程序问题，需要看为什么打开很多文件，比如通过lsof），一般要通过ulimit调整打开文件数限制解决，但ulimit本身也有不少坑，下面做一下总结。

什么是ulimit

直接参考ulimit的帮助文档（注意：不是man ulimit，而是help ulimit，ulimit是内置命令，前者提供的是C语言的ulimit帮助）：

Modify shell resource limits.
Provides control over the resources available to the shell and processes it creates, on systems that allow such control.

可以看出，ulimit提供了对shell（或shell创建的进程）可用资源的管理。除了打开文件数之外，可管理的资源有：最大写入文件大小、最大堆栈大小、core dump文件大小、cpu时间限制、最大虚拟内存大小等等，help ulimit会列出每个option限制的资源。或者查看ulimit -a也可以看出：

maoshuai@ms:~/ulimit_test$ ulimit -a

core file size          (blocks, -c) 0

data seg size           (kbytes, -d) unlimited

scheduling priority             (-e) 0

file size               (blocks, -f) 100

pending signals                 (-i) 15520

max locked memory       (kbytes, -l) 16384

max memory size         (kbytes, -m) unlimited

open files                      (-n) 1024

pipe size            (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

real-time priority              (-r) 0

stack size              (kbytes, -s) 8192

cpu time               (seconds, -t) unlimited

max user processes              (-u) 15520

virtual memory          (kbytes, -v) unlimited

file locks                      (-x) unlimited

理解ulimit

在使用ulimit之前，有几个容易迷糊的点：

ulimit的管理的维度

理解ulimit，第一个疑问是限制的维度是什么。比如nofile设置为1024，是指当前用户总共只能打开1024个文件，还是单个shell会话进程只能打开1024个文件？** 实际上help ulimit里已经说清楚了：process，但我们可通过下面的方法程序验证：

下面通过一段java程序，打开800个文件：

class Ulimit{

    public static void main( String[] args ) throws IOException, InterruptedException

    {

        List<FileInputStream> fileList = new ArrayList<FileInputStream>();

        for(int i=0;i<800;i++) {

            File temp = File.createTempFile("ulimit-test", ".txt");

            fileList.add(new FileInputStream(temp));

            System.out.println("file_seq=" + i + " " + temp.getAbsolutePath());

        }

        // keep it running, so we can inspect it.

        Thread.sleep(Integer.MAX_VALUE);

    }

}

我们将nofile设置为1024

ulimit -n 1024

然后我们运行两个进程实例：

nohup java Ulimit >a.log &

nohup java Ulimit >b.log &

查看日志a.log和b.log，都创建了800个文件，没有报异常。

如果将ulimit 设置为700，重新测试，发现java程序在创建688个文件时就报了Too many open files异常(之所以不是700整，是因为java本身也会打开一些文件)，

file_seq=688 /tmp/ulimit-test7270662509459661456.txt

Exception in thread "main" java.io.IOException: Too many open files

        at java.io.UnixFileSystem.createFileExclusively(Native Method)

        at java.io.File.createTempFile(File.java:2024)

        at java.io.File.createTempFile(File.java:2070)

        at Ulimit.main(Ulimit.java:12)

虽然ulimit的u是user的意思，但事实证明，ulimit控制的维度是shell会话或shell创建的进程（至少对于nofile来说）。即：当前用户打开的文件数，是可以远远超过nofile的值。

所以，通过lsof | wc -l 查看系统打开文件数，来判断是否打开文件数是否超了，是不正确的。另外，lsof | wc -l是也并不反映系统打开的文件数！（后续周刊补充）

soft和hard的区分

理解ulimit第二个重要方面是soft和hard的区分，ulimit对资源的限制区分为soft和hard两类，即同一个资源（如nofile）存在soft和hard两个值。

在命令上，ulimit通过-S和-H来区分soft和hard。如果没有指定-S或-H，在显示值时指的是soft，而在设置的时候指的是同时设置soft和hard值。

但soft和hard的区别是什么是什么呢？下面这段解释较为准确（来自man 2 getrlimit ）

The soft limit is the value that the kernel enforces for the corresponding resource. The hard limit acts as aceiling for the soft limit: an unprivileged process may set only its soft limit to a value in the range from 0 up to the hard limit, and (irre‐versibly) lower its hard limit. A privileged process (under Linux: one with the CAP_SYS_RESOURCE capability) may make arbitrary changes to either limit value.

归纳soft和hard的区别： 1. 无论何时，soft总是小于等于hard 2. 无论是超过了soft还是hard，操作都会被拒绝。结合第一点，这句话等价于：超过了soft限制，操作会被拒绝。 2. 一个process可以修改当前process的soft或hard。但修改需满足规则： * 修改后soft不能超过hard。也就是说soft增大时，不能超过hard；hard降低到比当前soft还小，那么soft也会随之降低。 * 非root或root进程都可以将soft可以在[0-hard]的范围内任意增加或降低。 * 非root进程可以降低hard，但不能增加hard。即nofile原来是1000，修改为了900，在修改为1000是不可能的。（这是一个单向的，有去无回的操作） * root进程可以任意修改hard值。

soft和hard在控制上其实并没有区别，都会限制资源的使用，但soft可以被进程在使用前自己修改。

ulimit的修改与生效

知道ulimit很好，但更重要的是怎么修改，这是工作中常见的任务。

关于ulimit的生效，抓住几点即可： 1. ulimit的值总是继承父进程的设置。 2. ulimit命令可修改当前shell进程的设置。这也说明，为了保证下次生效，修改的地方要具有持久性（至少相当于目标进程而言），比如.bashrc，或进程的启动脚本） 3. 从第2点也可以推出，运行中的进程，不受ulimit的修改影响。 3. 增加hard值，只能通过root完成

下面给出两个案例：

案例1：某非root进程要求2048的nofile，经查看当前soft为1024，hard为4096

可以直接在该进程启动脚本中，增加ulimit -nS 2048即可

案例2：某非root进程要求10240的nofile，经查看当前soft为1024，hard为4096

显然，非root用户没法突破。只能通过root修改，一般修改/etc/security/limits.conf文件，修改方法在该配置文件中的注释中也有说明，格式是：

一条记录包含4️列，分别是范围domain（即生效的范围，可以是用户名、group名或*代表所有非root用户）；t类型type：即soft、hard，或者-代表同时设置soft和hard；项目item，即ulimit中的资源控制项目，名字枚举可以参考文件中的注释；最后就是value。比如将所有非root用户的nofile设置为100000

*  hard nofile 10000

*  soft nofile 10000

运行中进程的limits的查看

ulimit修改之后，可以直接通过ulimit命令查看。对于已运行的进程，还有一种更准确的查看方法（比如修改ulimit前就启动的进程，如何知道其ulimit值就需要这种方法）：查看进程目录下的limits文件。比如，/proc/4660/limits文件就记录了4660号进程的所有limits值：

maoshuai@ms:~/ulimit_test$ cat /proc/4660/limits

Limit                     Soft Limit           Hard Limit           Units

Max cpu time              unlimited            unlimited            seconds

Max file size             unlimited            unlimited            bytes

Max data size             unlimited            unlimited            bytes

Max stack size            8388608              unlimited            bytes

Max core file size        0                    unlimited            bytes

Max resident set          unlimited            unlimited            bytes

Max processes             15520                15520                processes

Max open files            2000                 2000                 files

Max locked memory         16777216             16777216             bytes

Max address space         unlimited            unlimited            bytes

Max file locks            unlimited            unlimited            locks

Max pending signals       15520                15520                signals

Max msgqueue size         819200               819200               bytes

Max nice priority         0                    0

Max realtime priority     0                    0

Max realtime timeout      unlimited            unlimited            us

ulimit不加参数

曾经有小白直接用ulimit查看，看到打印出unlimited，就认为打开文件不受限制。显然这是不对的，help ulimit中明确指出：

If no option is given, then -f is assumed.

所以，ulimit不加参数，相当于ulimit -f -S（没有指定-S或-H就相当于-S），实际上是指可写入的文件最大size。

其他

如何查看进程打开文件数

losf命令虽然作用是"list open files"，但用lsof | wc -l统计打开文件数上非常不准确。主要原因是：

某些情况下，一行可能显示的是线程，而不是进程，对于多线程的情况，就会误以为一个文件被重复打开了很多次
子进程会共享file handler

如果用lsof统计，必须使用精巧的过滤条件。更简单和准确的方法是，通过/proc目录查看。获取系统打开文件说，直接查看/proc/sys/file-nr，其中第一个数字就是打开的file数（file-nr说明参考：https://www.kernel.org/doc/Documentation/sysctl/fs.txt）。要查看一个进程的打开文件数，直接查看目录/proc/$pid/fd里的文件数即可：

Java 自动将nofile的soft提升为hard上限

在研究的过程中，我发现java程序似乎不受nofile的soft值影响。查看进程的limits文件（/proc/$pid/limits），才发现nofile的soft被提升为和hard一样。经过全网搜索查询，发现JDK的实现中，会直接将nofile的soft先改成了和hard一样的值，可参考：How and when and where jvm change the max open files value of Linux?

Ubuntu中eclipse中启动的java和命令行启动的java，nofile不一样

通过pstree，发现eclipse的java是通过gnome-shell启动的，而命令行是通过gnome-terminal启动的。其中gnome-terminal又是通过systemd --user启动的，而systemd --user似乎不读取/etc/security/limits.conf的值。这个坑的说明有机会再填吧。

file-max控制内核总共可以打开的文件数

除了ulimit控制外，/proc/sys/fs/file-max这个文件控制了系统内核可以打开的全部文件总数。所以，即便是ulimit里nofile设置为ulimited，也还是受限的。

ulimit常用选项罗列

ulimit -a # 查看所有soft值

ulimit -Ha # 查看所有hard值

ulimit -Hn # 查看nofile的hard值

ulimit -Sn 1000 # 将nofile的soft值设置为1000

ulimit -n 1000 # 同时将nofiles的hard和soft值设置为1000

参考

本周刊示例代码与文档markdown文本统一整理于github：

maoshuai/java-linux-weeklygithub.com

本周比较忙，无奈先拿了我之前一篇笔记整理整理充了个数，见谅了；原载于：

Too many open files以及ulimit的用法wiki.imshuai.com

发布于 2019-08-01

Linux

Java