每天学一个Linux命令系列(进阶篇4):ulimit - 进程打不开文件?too many open files就是它管的

"too many open files" 是怎么来的

在 Linux 系统上，任何东西都是文件。你在终端里打开的每个会话、每个网络连接、每个硬盘上的普通文件、甚至每个管道，背后都是一个文件描述符（file descriptor，简称 fd）。内核给每个进程设了一个上限，防止它无限制地打开文件导致系统资源耗尽。这个上限就是 ulimit 管理的。

我第一次遇到这个错误是在一次线上事故中。当时一个 Java 后端服务突然全部报错，日志里清一色的 "java.io.IOException: Too many open files"。我查了一下这个 Java 进程，光它自己就开了 5 万多个文件描述符，超过了默认的 1024 限制。后来一查才知道程序中某个 HTTP 连接池没关闭连接，导致文件描述符疯狂泄漏。那次事故的教训是：程序写得好不好是一回事，系统层面有没有给足资源是另一回事。如果你不知道 ulimit 怎么调，就算程序写得再对，高并发下一样会崩。

ulimit 查看当前限制

先看看你的系统默认值长什么样：

# 查看所有用户级别的资源限制
ulimit -a

# 只看打开文件数限制
ulimit -n

# 查看最大用户进程数限制
ulimit -u

# 查看最大堆栈大小
ulimit -s

# 查看最大锁定内存大小
ulimit -l

ulimit -a 输出会看到类似这样的内容（不同发行版默认值不同）：

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 31538
max locked memory       (kbytes, -l) 65536
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) 31538
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

最需要关注的三行是 open files（-n）、max user processes（-u）、max locked memory（-l）。这三个在高并发服务（数据库、Web 服务器、消息队列）中经常需要调大。

软限制 vs 硬限制

ulimit 有两个级别的概念：软限制（soft limit）和硬限制（hard limit）。需要理解它们的区别：

# 查看软限制，普通用户看到的就是软限制
ulimit -Sn

# 查看硬限制，这个是内核允许的上限
ulimit -Hn

软限制是实际生效的限制。进程可以请求提高软限制，但最高只能提到硬限制的值。硬限制是真正的天花板，只有 root 用户可以调高它。

举个例子：如果软限制是 1024，硬限制是 65536，那么普通用户进程可以把软限制提高到 65536，但不能超过。如果硬限制就是 1024，那再怎么搞也提不上去。最直接的区别是，你运行 ulimit -n 65536 如果不加 -S 或 -H，默认改的是软限制。只有 root 用户用 ulimit -Hn 65536 才能提高硬限制。

这个设计是有安全考虑的。假设一个用户写了个程序，里面 fork 了大量子进程，每个进程都打开很多文件。如果没有硬限制保护，这个进程可以无限制地消耗系统资源，影响到其他用户的进程。硬限制的存在保证了"一个用户再折腾也有个度"。

临时修改：ulimit 命令

直接在终端里修改当前 shell 的限制：

# 把当前 shell 的打开文件上限改成 65535（仅当前会话有效）
ulimit -n 65535

# 修改最大进程数
ulimit -u 65535

# 用 -S 和 -H 分别指定软硬限制
ulimit -Sn 65535
ulimit -Hn 65535

这里有一个非常重要的细节：ulimit 改的是当前 shell 的限制，而且只影响这个 shell 以及从这个 shell 启动的子进程。你关掉终端窗口，重新打开一个，限制就回到默认值了。这就是"临时修改"的含义。

我在测试环境调试应用的时候经常用这个特性：先 ulimit -n 65535 然后启动服务试一下，如果确认是文件描述符的问题，再去配永久配置。

永久配置：/etc/security/limits.conf

要让 ulimit 的修改永久生效，需要修改 PAM（Pluggable Authentication Modules，可插拔认证模块）的配置文件：

# 编辑 limits.conf
sudo vi /etc/security/limits.conf

文件格式是每行一个规则：domain type item value。举个例子：

# 给所有用户设置软限制
*                soft    nofile          65536
*                hard    nofile          65536

# 给所有用户设置最大进程数
*                soft    nproc           65536
*                hard    nproc           65536

# 给 mysql 用户单独设置更高的限制
mysql            soft    nofile          100000
mysql            hard    nofile          100000
mysql            soft    nproc           65536
mysql            hard    nproc           65536

域（domain）可以是用户名、组名（用 @group 表示）或者 *（代表所有用户）。类型（type）是 soft 或 hard。项目（item）是限制类型，最常用的有：
- nofile：打开文件数
- nproc：最大进程数
- memlock：锁定内存大小
- stack：堆栈大小
- as：地址空间限制

改完之后需要重新登录才会生效。如果你已经在终端里了，可以 exit 再重新 SSH 进来。

有个坑：CentOS 6/7 上的 nproc 限制用 * 通配符有时不生效（这是 PAM 的 bug），需要显式指定 root 用户：

root             soft    nproc           unlimited
*                soft    nproc           65536
*                hard    nproc           65536

我当初在这个问题上卡了整整一个下午，以为 limits.conf 没生效，后来查了 Red Hat 的官方文档才发现是 PAM 的已知问题。

systemd service 的 LimitNOFILE

如果你用 systemd 管理服务（现在基本都走 systemd 了），limits.conf 对 systemd 启动的服务是不生效的。这是很多人配置了 limits.conf 却感觉"没起作用"的常见原因。你需要改对应 service 的 unit 文件：

# 查看某个 service 的配置，确认是否有限制设置
sudo systemctl cat myservice.service

# 编辑 service 对应的 override 配置（如果不存在会自动创建）
sudo systemctl edit myservice.service

在编辑器中添加：

[Service]
LimitNOFILE=65535
LimitNPROC=65535
LimitMEMLOCK=infinity

改完后重新加载配置并重启服务：

# 重新加载 systemd 配置
sudo systemctl daemon-reload

# 重启服务
sudo systemctl restart myservice.service

这个坑我亲身踩过。之前在一台 CentOS 7 的机器上配了 limits.conf 给某个应用账号提了 nofile，然后重启了应用但没重启 systemd。检查发现限制还是老样子。后来才知道，对 systemd 管理的服务来说，limits.conf 根本不会被用到。

所以排查限制问题时，先搞清楚服务是怎么启动的：用 systemctl 的走 LimitNOFILE，用 SSH 登录后手动启动的走 limits.conf，用 docker 跑的还要考虑容器级别的限制。

⚠️ 安全提醒：把 nofile 改成 unlimited 或者设置得非常大（比如 1048576），有可能耗尽系统的文件描述符资源。系统的全局上限由 /proc/sys/fs/file-max 控制（用 sysctl 可以改），ulimit 给每个进程分配的上限总合不能超过这个全局限制。建议不要夸大到几百万，要根据实际业务评估。对于大多数 Java/Go/Node 后端服务，65535 到 100000 已经足够。

进程级查看：/proc/PID/limits

如果你想确认某个正在运行的进程当前到底生效了什么限制，直接查 proc 文件系统：

# 查看 PID 为 1234 的进程的有效限制
cat /proc/1234/limits

# 结合 ps 和 pidof 动态查看特定服务的限制
PID=$(pidof nginx | awk '{print $NF}')
cat /proc/$PID/limits

输出样例如下：

Limit                     Soft Limit           Hard Limit           Units
Max open files            65535                65535                files
Max processes             65535                65535                processes
Max pending signals       31538                31538                signals

这是最靠谱的检查方式，因为它反映的是进程当前实际生效的情况，而不是配置文件里写了什么。我每次改完限制配置后，都会重启服务然后 cat /proc/PID/limits 确认修改已经生效。

如何确认当前进程的文件描述符使用情况

调大限制之后，也要看看实际用了多少：

# 查看 PID 为 1234 的进程当前打开的文件描述符数量
ls -la /proc/1234/fd | wc -l

# 更准确的方式（排除 . 和 ..）
ls /proc/1234/fd/ | wc -l

# 查看所有已打开文件描述符的详细信息
ls -la /proc/1234/fd/

如果发现某个进程的文件描述符数量接近你设置的上限（比如设了 65535，已经用了 60000），那一定是程序有资源泄漏，光调 ulimit 是治标不治本的。

一个完整的配置流程

假设你要部署一个 Java 后端服务到新服务器上：

# 第一步：检查当前系统的全局文件句柄上限
sysctl fs.file-max

# 第二步：如果需要，调大全局上限
sudo sysctl -w fs.file-max=2000000
echo "fs.file-max=2000000" | sudo tee -a /etc/sysctl.d/99-server-tuning.conf

# 第三步：配置 limits.conf
echo '* soft nofile 65535
* hard nofile 65535' | sudo tee -a /etc/security/limits.conf

# 第四步：如果走 systemd，配 services unit
sudo mkdir -p /etc/systemd/system/myservice.service.d
echo '[Service]
LimitNOFILE=65535' | sudo tee /etc/systemd/system/myservice.service.d/override.conf
sudo systemctl daemon-reload

# 第五步：重启服务并用 /proc/PID/limits 确认
sudo systemctl restart myservice
cat /proc/$(pidof myservice)/limits | head -5

这个流程走一遍后，基本不会再遇到 "too many open files" 的问题。

总结

ulimit 的核心是管理"每个进程能吃多少资源"。软限制和硬限制的配合、limits.conf 和 systemd LimitNOFILE 的区别、/proc/PID/limits 的确认方法，这三个知识点掌握了，你就不会再被 "too many open files" 打个措手不及。