直接调高硬限制是解决“too many open files”错误的关键，需用ulimit -hn临时设置或通过/etc/security/limits.conf、systemd的limitnofile及system.conf永久配置，并验证进程/proc/pid/limits中两列数值一致。
直接调高硬限制（hard limit）是解决高并发下“Too many open files”错误的关键一步，但不能只改 ulimit -n——它默认只调软限，而进程实际能打开的上限由硬限决定。硬限没调够，软限再高也无效。
确认当前硬限制是否不足
运行以下命令查看真实限制：
-
ulimit -Hn：显示当前 shell 的硬限制值（如输出4096，就明显不够） -
ulimit -Sn：对比软限制，若软限高于硬限，说明软限已被截断 -
cat /proc/$(pgrep -f "your-service")/limits | grep "Max open files"：查服务进程实际生效的 soft/hard 值
临时提升硬限制（仅当前会话）
需 root 权限才能上调硬限，普通用户只能降低：
-
sudo ulimit -Hn 65536（先提硬限） -
ulimit -Sn 65536（再提软限，此时不会被截断） - 注意：该方式只影响当前终端及其后续启动的进程，退出即失效
永久设置硬限制（关键生效路径）
硬限制必须通过系统级配置持久化，且不同启动方式需对应不同位置：
- 对普通登录用户（SSH、GUI）：编辑
/etc/security/limits.conf，添加两行（必须同时写 soft 和 hard）：* soft nofile 65536* hard nofile 65536 - 对 systemd 服务（如 nginx、redis）：在服务单元文件（如
/etc/systemd/system/nginx.service）的[Service]段加：LimitNOFILE=65536（等效于 soft=hard） - 全局默认（影响所有未显式覆盖的 systemd 服务）：修改
/etc/systemd/system.conf中的DefaultLimitNOFILE=65536
验证硬限制是否真正落地
改完不验证 = 白改。重点检查进程本身，而非当前终端：
- 重启服务后执行：
cat /proc/$(pidof nginx)/limits | grep "Max open files" - 输出应类似：
Max open files 65536 65536 files（两列数值一致才表示 hard 有效） - 若仍显示
1024 4096等旧值，说明配置未加载或服务未重载（需systemctl daemon-reload && systemctl restart xxx）
