必须同时修改limits.conf、systemd.system.conf、sysctl.conf及重启服务，否则ulimit -n仍显示1024；因CentOS 7用systemd管理服务，其忽略limits.conf对系统服务的限制，需分别配置PAM用户限制、systemd默认限制及内核级file-max/nr_open参数。

必须同时改三个地方，只动 /etc/security/limits.conf 是无效的 —— 这是 CentOS 7 最常见的失效原因。

为什么 ulimit -n 显示还是 1024？

CentOS 7 使用 systemd 启动服务，而 systemd 会忽略 /etc/security/limits.conf 中对 root 或系统服务的限制。即使你改了 limits.conf，systemd 启动的进程（比如 mysqld、java、nginx）仍按默认值（通常是 1024）运行。

• 查看当前生效的软限制：ulimit -Sn
• 查看硬限制：ulimit -Hn
• 检查系统级总上限：cat /proc/sys/fs/file-max
• 检查单进程理论最大值：cat /proc/sys/fs/nr_open

改 /etc/security/limits.conf 只对 PAM 登录用户有效

这个文件只影响通过 login、su、ssh 等 PAM 认证方式登录的交互式 shell，不作用于 systemd 服务或后台守护进程。

CentOS Linux 7.9.2009

CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离

下载

• 在文件末尾添加（注意：不是用 *，而是明确指定用户或组）：
  root soft nofile 65536
root hard nofile 65536
myappuser soft nofile 65536
myappuser hard nofile 65536
• 避免用 * 全局匹配：某些 PAM 版本（尤其是较新 CentOS 7.9+）会跳过 * 条目
• 改完后需重新登录（不是 source 或 logout 就行），否则不会加载新限制

必须改 /etc/systemd/system.conf 才能让服务生效

systemd 服务的资源限制由 DefaultLimitNOFILE 控制，它覆盖所有通过 systemctl start 启动的服务。

• 编辑：sudo vi /etc/systemd/system.conf
• 取消注释并修改这两行：
  DefaultLimitNOFILE=65536
DefaultLimitNPROC=65536
• 执行重载：sudo systemctl daemon-reload
  ⚠️ 注意：不是 daemon-reexec，后者仅在极少数场景需要
• 重启目标服务才能生效，例如：sudo systemctl restart mysqld

别漏掉 fs.file-max 和 fs.nr_open

这两个是内核级硬限制，如果设得太低，上面所有用户级设置都会被截断。

• 查看当前值：sysctl fs.file-max、sysctl fs.nr_open
• 编辑 /etc/sysctl.conf，追加两行：
  fs.file-max = 2097152
fs.nr_open = 2097152
• 立即生效：sudo sysctl -p
• ⚠️ fs.nr_open 必须 ≥ 你设的 DefaultLimitNOFILE，否则 systemd 会静默降级到 nr_open 值

改完全部四点后，务必用 cat /proc/$(pgrep -f 'your_service_name')/limits | grep files 直接查目标进程的 Max open files 行 —— 这才是真实生效值，比 ulimit -n 更可靠。