Linux怎么查看具体的文件描述符最大值

要看系统级文件描述符上限，最靠谱的还是直接以/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 里的数字——其他所有配置都是中间步骤，这行才是终点。