fs.nr_open是单进程文件描述符硬上限，决定ulimit -n最高可设值；而fs.file-max是全系统总句柄数上限，二者作用域不同，故不能仅调高后者——若fs.nr_open未同步扩大，ulimit将因超出进程级上限而失败。
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<br>fs.file-max = 1500000
然后执行 sysctl -p 加载。验证是否生效：
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
-
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<br>echo 'DefaultLimitNOFILE=1500000' >> /etc/systemd/user.conf<br>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，不提具体原因。
