单进程能打开的文件句柄数量，由内核参数和用户态资源限制共同决定，生产环境里最常见、最直接的设置方式是编辑/etc/security/limits.conf文件里的nofile项，再用sysctl调整内核全局上限。
too many open files怎么解决？先分清限制层级
很多运维朋友一看到“too many open files”报错，第一反应就是敲ulimit -n改大数字，这个思路方向没错，但不完整，因为文件句柄限制是从内核到用户态一层层卡下来的，只改某一层，进程照样可能顶不住。
Linux查看文件句柄限制：三个数值各管什么
在Linux系统中,文件句柄（文件描述符，File Descriptor）的控制权分散在三个层面，业内专家指出它们的关系可以理解为“国家政策”和“地方细则”的差别。
| 参数 | 作用范围 | 默认情况 | 修改途径 |
|---|---|---|---|
fs.file-max |
整个操作系统所有进程的句柄总数 | 随内存大小自动调整 | sysctl -w fs.file-max=xxx |
fs.nr_open |
单个进程能打开句柄数的内核硬上限 | 默认1048576 | sysctl -w fs.nr_open=xxx |
nofile（RLIMIT_NOFILE） |
单个进程实际可用的句柄数 | 多数发行版默认1024 | ulimit -n或limits.conf |
ulimit -n显示出来的数字，只是第三层的软限制，换句话说，就算你把ulimit -n调到100万，只要进程是普通用户启动的，它还受fs.nr_open这个内核上限的约束，反过来，如果fs.file-max没调大，整个系统的句柄额度用光了，单个进程的nofile再高也没用。
排查“too many open files”问题时，先按下面顺序查一遍：
cat /proc/sys/fs/file-max查看系统全局上限cat /proc/sys/fs/nr_open查看单进程内核硬上限ulimit -n查看当前shell的软限制ulimit -Hn查看当前shell的硬限制cat /proc/你的进程PID/limits查看进程实际生效的限制值
服务器进程句柄数设置方法：从临时到永久
搞清楚层级之后,动手改就顺理成章了，大多数情况下，我们需要同时调整用户态限制和内核参数，让设置真正落到进程头上。
临时调大：适合快速验证
如果只想临时验证一下调整效果,直接在终端里执行：
ulimit -n 65535
这条命令只对当前shell及它启动的子进程生效，关掉终端就没了，但做测试验证足够了改完数字后，立刻启动出问题的程序，看看“too many open files”是否消失。
永久生效：修改limits.conf
线上服务器显然不能靠手动敲命令撑一天,永久修改的经典路径是编辑/etc/security/limits.conf，在文件末尾追加：
soft nofile 65535 hard nofile 65535
这里第一行设置软限制，是进程启动时默认拿到的额度；第二行设置硬限制，是允许上调的最大值，普通用户只能把软限制往上调到硬限制的数值，不能超过硬限制，所以两个值最好写成一样的，省得后面踩坑。
改完保存后,需要重新登录会话或重启相关服务才能生效，不少朋友改完这个文件发现不起作用，多半是忘记重新登录。
同步调整内核参数
limits.conf的nofile设置的是用户态的上限，但内核的fs.nr_open如果比它小，设置依然会被压制，建议顺手把内核参数也调大：
sysctl -w fs.nr_open=1048576 sysctl -w fs.file-max=1048576
如果希望重启后仍生效,将这两行写入/etc/sysctl.conf，再执行sysctl -p加载。
systemd服务要单独处理
这里有个很容易被忽略的坑：如果目标进程是由systemd管理的服务（比如Nginx、Tomcat），
limits.conf对它们不生效，systemd服务默认有一套自己的资源控制规则，需要编辑service文件：
systemctl edit 你的服务名
在打开的覆盖文件里写入：
[Service] LimitNOFILE=65535
保存后执行systemctl daemon-reload并重启服务，再用cat /proc/PID/limits验证服务进程的nofile确实是新值。
单进程句柄数不是越大越好
很多人的误区是：既然是限制，那把上限调到最大不就行了吗？行业共识认为，文件句柄是内核里比较金贵的资源，单进程句柄数过大意味着内核要预留更多的内存数据结构，吃着内存不说，还可能掩盖程序里的资源泄漏问题。
怎么判断合适的值
这个数值不能拍脑袋定,需要结合进程的实际行为来推算：
- 统计进程当前已打开的句柄数量（
ls /proc/PID/fd | wc -l） - 评估业务高峰期的并发连接数,通常取峰值数量的2到3倍
- 如果进程是反向代理或网关类程序,句柄消耗会随连接数快速上升
- 对于日志采集、消息队列这类长连接应用，句柄数相对稳定
举个例子：一台负载均衡服务器日常维持2万个并发连接，把nofile设成65535会是比较宽裕的配置，但如果你看到某个进程的句柄数随时间无限增涨，先别急着调大上限，查查是不是存在连接池泄漏这比调参数重要得多，对绝大多数应用来说，单进程句柄数超过100万的场景非常罕见，盲目设成超大值等于拿内存换安全感。
验证配置是否真正生效
修改不是结束,验证才是，实际操作中，配置写错位置或者被其他配置覆盖的情况经常发生，教你三步确认修改到位。
第一步：查看进程实际限制
cat /proc/进程PID/limits | grep -i "open files"
看到Max open files
那行显示你设置的值，说明配置生效，注意要查看目标进程的PID，而不是当前shell的PID服务重启后PID可能会变。
第二步：确认当前占用情况
ls /proc/进程PID/fd | wc -l
这个数字是进程当前打开的实际句柄数,如果它在毫无节制地增长，说明程序存在句柄泄露，光调参数解决不了根本问题。
第三步：压测模拟峰值
用ab、wrk这类压测工具模拟高并发，观察进程会不会触发too many open files，务必在预发环境做这一步，别拿线上流量当测试。
Q&A：关于内核参数限制单进程文件句柄数的常见问题
ulimit -n改大了不生效，怎么回事？
优先排查三件事：一是确认修改是否写进了/etc/security/limits.conf的正确位置且没有语法错误；二是确认当前用户是否重新登录过，limits.conf只在登录时加载一次；三是如果进程由systemd启动，必须单独在service配置里设置LimitNOFILE，这个优先级高于limits.conf。
修改nofile后进程还是报“too many open files”？
这说明不只是用户态限制的问题,用cat /proc/sys/fs/file-max检查系统全局句柄总数是否充足，再用cat /proc/sys/fs/nr_open检查内核单进程硬上限，多数情况下，fs.file-max的默认值够用，但少数内存配置偏低的老服务器上，这个全局值会成为瓶颈。
单进程文件句柄数设置多少才算合理？
没有万能答案,但可以参考这个思路：先观察业务高峰期的实际句柄消耗量，计算两次采样之间的增长速率，再把上限设为高峰期消耗量的2到3倍，对于大多数Web应用，65535是一个兼顾性能和资源消耗的起步值；如果业务量极大，可以逐步上调到1048576，但前提是确认程序没有句柄泄漏问题，内核参数限制单进程文件句柄数的调整，本质上是对资源分配和稳定性之间做权衡，一边调一边观察服务器压力才是靠谱的做法。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/658316.html
