centos 7 文件打开数限制需同时配置系统级（fs.file-max、fs.nr_open）、用户级（/etc/security/limits.conf）和进程级（systemd limitnofile），缺一不可；验证必须检查具体进程的 /proc/pid/limits。
ulimit -n 报错 “Operation not permitted” 或服务启动后仍卡在 1024，说明只改了单点配置，没打通全链路。CentOS 7 的文件打开限制分三层，缺一不可。
查清当前哪一层卡住了
先跑三组命令定位瓶颈点：cat /proc/sys/fs/file-max —— 系统级总上限（默认约 58 万）ulimit -Sn 和 ulimit -Hn —— 当前 shell 的软/硬限制（普通用户常卡在 1024）cat /proc/$(pidof your_service)/limits | grep "Max open files" —— 具体进程实际生效值（可能比 ulimit 还低）
/etc/security/limits.conf 不生效的常见原因
这个文件只对通过 PAM 登录的会话生效，但很多服务（尤其是 systemd 启动的）根本不会读它。
CentOS Linux 7.9.2009
下载
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。
- 不要用
*匹配所有用户——systemd 服务通常以root或专用用户（如nginx、mysql）运行，得写明用户名，例如：nginx soft nofile 65535nginx hard nofile 65535 - 确保
/etc/pam.d/sshd或/etc/pam.d/login中有这一行（默认 CentOS 7 已存在）：session required pam_limits.so - 改完必须退出重登，或用
su -l nginx -c 'ulimit -n'验证目标用户视角
systemd 服务绕过 limits.conf 的解决方法
如果用 systemctl start nginx 启动，limits.conf 完全无效。必须改 systemd unit 文件：
- 新建
/etc/systemd/system/nginx.service.d/override.conf（目录需存在） - 内容写死限制：
[Service] LimitNOFILE=65535
- 执行：
systemctl daemon-reloadsystemctl restart nginx - 验证：
cat /proc/$(pidof nginx)/limits | grep "Max open files"应显示 65535
内核参数 fs.file-max 和 fs.nr_open 的关系
fs.file-max 是系统总文件句柄上限，fs.nr_open 是单进程能申请的最大值（默认 1048576），两者都得调：
- 编辑
/etc/sysctl.conf，加两行：fs.file-max = 8061540fs.nr_open = 8061540 -
fs.nr_open必须 ≥fs.file-max，否则即使设了高LimitNOFILE，进程也会被内核拒绝分配 - 生效命令：
sysctl -p
systemd 启动的服务无视 limits.conf，同时 fs.nr_open 没同步放大，导致进程拿到的上限远低于你写的数字。验证时别只看 shell 的 ulimit -n，一定要查具体进程的 /proc/PID/limits。
