CentOS 7修改文件系统inode上限方法

在调高系统文件句柄上限时，很多工程师会遇到一个让人困惑的问题：明明已经修改了 fs.file-max，但 ulimit -n 就是报错，提示“Operation not permitted”。这背后的关键，其实在于一个容易被忽略的内核参数——fs.nr_open。

fs.nr_open 是什么，为什么不能直接改 fs.file-max

简单来说，fs.nr_open 是内核给每个进程设置的一道“天花板”，它决定了单个进程最多能打开多少个文件描述符（file descriptor），进而限定了 ulimit -n 这个命令能设置的上限值。而 fs.file-max 则是系统全局的“总水池”，所有进程打开的文件数加起来不能超过它。

如果只调高了 fs.file-max，却没同步扩大 fs.nr_open，用户执行 ulimit -n 1000000 时就会碰壁，系统会直接报错：bash: ulimit: open files: cannot modify limit: Operation not permitted。所以，这两个参数必须“协同作战”，缺一不可。

修改 fs.nr_open 必须先确认当前值和硬限制

动手之前，先通过以下命令摸清现状：

cat /proc/sys/fs/nr_open

默认值通常是 1048576（也就是 1024×1024）。但这里有个陷阱：fs.nr_open 本身存在一个编译时的硬上限，不能无限制地设高。假如你尝试设为 2000000 却失败了，说明已经超出了内核编译时定义的 NR_OPEN_MAX——这种情况下，调整配置文件已经没用了，要么换内核，要么接受这个内置上限。

几个必须留意的细节：

• 必须确保 fs.file-max ≤ fs.nr_open，否则 sysctl -p 加载时会拒绝生效。
• 改之前建议先查一下 cat /proc/sys/fs/file-max，提前避免后续冲突。
• 如果需要临时生效，可以执行 sysctl -w fs.nr_open=2000000，但重启后配置会清除。

永久修改需写入 /etc/sysctl.conf 并验证

想让改动一劳永逸，需要编辑 /etc/sysctl.conf，添加两行配置（顺序不能颠倒）：

fs.nr_open = 2000000
fs.file-max = 1500000

保存后执行 sysctl -p 加载。验证是否生效可以从三个方面入手：

• 运行 sysctl fs.nr_open——输出值应该和你设的一致。
• 执行 ulimit -Hn——这个值必须 ≤ fs.nr_open，且大于之前的软限制。
• 新开一个终端，执行 ulimit -n 1500000——不报错才算真正打通了通道。

如果 ulimit -n 仍然卡在旧值上，排查方向有两个：一是检查 /etc/security/limits.conf 中是否给对应用户设置了 nofile 限制；二是看看是否被 systemd 服务覆盖了（下面会提到）。

systemd 服务绕过 limits.conf？得改 DefaultLimitNOFILE

CentOS 7 中一个很容易踩的坑是：由 systemd 启动的服务（比如 nginx、Java 进程）默认不会读取 /etc/security/limits.conf 的配置。即使你在全局设了 * hard nofile 1500000，这些服务在启动时，限制可能仍然只有 4096 或 65536。

解决方案是统一修改 systemd 的全局限制：

echo 'DefaultLimitNOFILE=1500000' >> /etc/systemd/system.conf
echo 'DefaultLimitNOFILE=1500000' >> /etc/systemd/user.conf
systemctl daemon-reload

之后重启目标服务（比如 systemctl restart nginx），再用 cat /proc/$(pgrep nginx)/limits | grep "Max open files" 来确认新限制是否生效。

还有一个容易被忽略的点：systemd 的 DefaultLimitNOFILE 值不能超过 fs.nr_open，否则服务启动会失败，而日志中只会抽象地报一句 Failed at step LIMITS spawning，完全不会提示具体原因。这才是排查时最容易卡住的地方。