现场是这样的。业务报句柄不足，运维把系统总上限调大后依旧报错，查下来进程自己的限制还停留在原来的值。
把日志和配置对完，能解释这个现象的基本就这几处。系统总上限和单进程上限是两套独立参数；调整后没有对所有服务生效；限制配置被服务的启动方式绕过。
第一件事是看系统级上限和已用数量
cat /proc/sys/fs/file-max /proc/sys/fs/file-nr调大系统级上限
sysctl -w fs.file-max=2000000给服务单独设进程级上限
systemctl set-property app.service LimitNOFILE=65535末了核对进程实际限制
grep files /proc/$(pidof app)/limits这台环境是别人交接的，不少默认值被动过，只能一项项核。
同事提醒我看一下最近一次发布，时间点确实对得上。
怎么算真的好了，看的是同一批现象。系统与进程两级上限都已放开，业务高峰不再出现句柄耗尽。
补一句。系统级上限是所有进程共享的，单进程设太大会挤占别人；按业务实际需要分级设置更稳妥。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。