在调整 Linux 系统文件句柄（file descriptor）上限时，许多工程师常常遇到一个令人困惑的报错：明明已经修改了 `fs.file-max`，执行 `ulimit -n` 却仍然提示“Operation not permitted”。这背后隐藏的关键在于一个容易被忽略的内核参数——`fs.nr_open`。 ### fs.nr_open 是什么，为什么不能直接改 `fs.file-max` 简单来说，`fs.nr_open` 是内核为每个进程设定的“天花板”，它决定了单个进程最多能打开多少个文件描述符，进而限定了 `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` 必须先确认当前值和硬限制 动手之前，先通过以下命令摸清现状： ```bash 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`，添加两行配置（顺序不能颠倒）： ```bash 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 的全局限制： ```bash 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`，完全不会提示具体原因。这才是排查时最容易卡住的地方。