要看系统级文件描述符上限，最靠谱的还是直接以/proc/sys/fs/file-max的实时值为准；/proc/sys/fs/file-nr的第一列表示当前已经分配的总数，一旦逼近第三列，基本就说明快要碰到上限了。至于进程的真实限制，得去查/proc/[pid]/limits；如果是systemd托管的服务，则需要在[Service]段里设置LimitNOFILE，并执行daemon-reload使配置生效。
看系统级上限：直接读 /proc/sys/fs/file-max
真正权威、而且反映当前状态的，是这个实时值。它既不是配置文件里“写着什么就算什么”，也不是 sysctl fs.file-max 里可能残留的缓存结果。内核在运行过程中，看的就是它来控制全局 fd 总量。比如输出 2097152，含义很直接：整个系统最多只能分配这么多 fd。至于 /etc/sysctl.conf 里有没有那一行，其实没那么重要——如果没执行 sysctl --system，就算改了配置，也不会真正生效。
查当前真实用量：/proc/sys/fs/file-nr 的第一列才是关键
执行 cat /proc/sys/fs/file-nr 得到类似 12480 0 2097152 的三列数字：
- 第一列
12480：已分配出去的 fd 总数（含已关闭但未回收的），≈ 实际占用量 - 第二列通常为
0，现代内核基本不保留“预分配但未用”的池子 - 第三列等于
file-max，是硬上限
如果第一列接近第三列（比如差不到 5%），说明系统级快满了，调单个进程的限制没用。
验证具体进程的软硬限制：必须看 /proc/[pid]/limits
ulimit -n 只反映当前 shell，对 systemd 服务完全无效。真正生效的限制藏在进程自己的 limits 文件里：
- 先找到 pid：
pgrep nginx或systemctl show nginx --property=MainPID - 再查限制：
cat /proc/$(pgrep nginx | head -n1)/limits | grep "Max open files" - 输出如
Max open files 65536 65536 files，左边是 soft，右边是 hard
如果这里还是 1024，哪怕你改了 /etc/security/limits.conf，也说明 systemd 没加载你的配置。
systemd 服务改 limit 容易漏掉的三个地方
写 LimitNOFILE=65536 不等于生效：
- 必须放在 unit 文件的
[Service]段下，写在[Unit]或[Install]里无效 - 改完要
systemctl daemon-reload，否则 reload service 也不起作用 - 硬限制不能超过内核的
fs.nr_open（默认1048576），否则服务启动失败且无明确报错
最终是否落地，只认 /proc/[pid]/limits 里的数字——其他所有配置都是中间步骤，这行才是终点。
