centos 7资源限制需分进程级、用户级、内核级三层配置：ulimit仅临时生效于当前shell；/etc/security/limits.conf须soft/hard成对设置且对systemd服务无效；systemd服务需在unit文件中配置limitnofile/limitnproc；内核级fs.file-max必须同步调高，否则仍报“too many open files”。
直接说结论：CentOS 7 的系统级资源上限不是单靠 ulimit 就能改全的，必须分三层处理——进程级、用户级、内核级，漏掉任何一层都可能在高并发或重启后失效。
为什么 ulimit -n 65535 只在当前 shell 有效
这是最常踩的坑：ulimit 命令只影响当前 shell 及其派生进程，退出或新开终端就恢复默认（通常是 1024）。它不修改任何配置文件，也不影响已运行的服务（比如 nginx、mysql）。
- 软限制（
-S）可被进程自行调高，但不能超过硬限制（-H） - 硬限制只能由 root 修改，且必须配合配置文件才持久
- systemd 管理的服务（CentOS 7 默认）会忽略
/etc/security/limits.conf，除非显式声明
/etc/security/limits.conf 要配对生效，不能只写一行
这个文件只控制登录 shell 启动的进程，而且必须同时指定 soft 和 hard 才可靠。只写 * soft nofile 65535 没用，因为 soft 不能超过 hard，默认 hard 是 4096。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。
- 正确写法示例（追加到文件末尾）：
* soft nofile 65535* hard nofile 65535* soft nproc 65535* hard nproc 65535 - 若只针对某用户（如
nginx），把*换成用户名即可 - 注意：该文件对 root 用户不一定生效，需额外检查
/etc/security/limits.d/下的覆盖配置（如20-nproc.conf）
systemd 服务必须单独设限，limits.conf 对它无效
CentOS 7 使用 systemd 启动绝大多数服务，而 systemd 默认不读取 limits.conf。比如你改了 nofile，但 nginx 进程打开文件数还是卡在 1024，就是因为没配 systemd。
- 编辑服务单元文件，例如：
/etc/systemd/system/nginx.service - 在
[Service]段下添加：LimitNOFILE=65535LimitNPROC=65535 - 保存后执行：
systemctl daemon-reload && systemctl restart nginx - 验证：用
cat /proc/$(pgrep nginx)/limits | grep "Max open files"查看实际值
内核级限制 fs.file-max 容易被忽略
这是整个系统的总文件描述符上限，所有进程加起来不能超这个数。如果只调高单个进程的 nofile 却不调 fs.file-max，系统会在高负载时直接拒绝分配新句柄，报错仍是 Too many open files。
- 临时生效：
sysctl -w fs.file-max=1000000 - 永久生效：向
/etc/sysctl.conf追加一行：fs.file-max = 1000000，再执行sysctl -p - 验证：
cat /proc/sys/fs/file-max - 注意：该值建议设为单进程最大值 × 预估并发进程数，留 20% 余量
真正改到位的关键是——改完必须验证。不要只信配置文件写了，要查 ulimit -n、查 /proc/<pid>/limits</pid>、查 sysctl fs.file-max，三者缺一不可。尤其注意 systemd 服务和非交互式登录（如 cron、ssh 执行脚本）走的是不同加载路径，容易漏测。
