"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" 打个措手不及。
10个月宝宝每天需要喝多少奶粉？