CentOS 7如何永久修改ulimit -n文件打开数限制？

在 CentOS 7 系统管理中，ulimit -n 是一个至关重要的命令，它直接关系到系统能够处理的最大文件描述符数量，文件描述符是内核为了高效管理已被打开的文件、网络连接（Socket）、管道等资源而创建的一个索引，对于需要处理大量并发连接的应用程序，如高并发的 Web 服务器（Nginx、Apache）、数据库（MySQL、PostgreSQL）或消息队列（Kafka、RabbitMQ），默认的 ulimit -n 值往往成为性能瓶颈，深入理解并正确配置 ulimit -n 是保障高负载服务稳定运行的基础。

理解 ulimit -n 的核心概念

ulimit 是一个内建于 Shell 的命令，用于控制 shell 启动的进程所能使用的系统资源。-n 选项专门用于设置或查看进程可以打开的最大文件描述符数量,这个限制分为两种类型：

• 软限制：当前生效的限制值，普通用户可以自行调整软限制,但只能调高到硬限制所设定的上限。
• 硬限制：软限制可达到的最高值，只有 root 用户或有 CAP_SYS_RESOURCE 权限的进程才能增加硬限制。

我们所说的“修改 ulimit -n”指的是提高软限制和硬限制，以满足应用程序的需求，需要注意的是，这里的“文件”是一个广义概念，它不仅包括磁盘上的普通文件，还包括目录、块设备、字符设备、管道、套接字等一切 Linux 系统中以文件形式存在的资源，一个高并发的 Web 服务器，其每个客户端连接都会消耗一个文件描述符，连接数越多,需要的文件描述符就越多。

查看与临时修改限制

在开始永久性修改之前,首先需要学会如何查看当前的限制以及如何进行临时性调整。

查看当前限制

打开一个终端，可以使用以下命令查看当前 shell 的文件描述符限制：

# 查看软限制
ulimit -Sn
# 查看硬限制
ulimit -Hn
# 同时查看软限制和硬限制
ulimit -n

还可以通过查看 /proc 文件系统获取更详细的信息：

cat /proc/self/limits | grep "Max open files"

这会输出类似 Max open files 1024 4096 files 的信息，其中第一个数字是软限制,第二个是硬限制。

临时修改限制

临时修改非常简单，它仅对当前的 shell 会话及其后续启动的子进程有效，一旦用户退出登录,设置便会失效。

# 将软限制和硬限制都设置为 65536
ulimit -n 65536

执行后，再次使用 ulimit -n 查看，会发现限制值已经更新，这种方法非常适合用于临时的测试或调试,但不适用于生产环境的持久化配置。

永久修改限制的正确方法

在 CentOS 7 中，由于其广泛使用 systemd 作为初始化和服务管理器，永久修改 ulimit -n 的方法与传统方式有所不同,需要特别注意。

通过 /etc/security/limits.conf（传统方法）

这是最经典的方法，通过修改 PAM（Pluggable Authentication Modules）的配置文件来对登录用户进行限制,文件格式如下：

<domain> <type> <item> <value>

字段	说明
<domain>	可以是用户名、用户组（格式为 @groupname）或通配符 （表示所有用户）。
<type>	soft 表示软限制，hard 表示硬限制， 表示同时设置软限制和硬限制。
<item>	nofile 代表文件描述符数量。
<value>	具体的数值。

要为所有用户设置默认的文件描述符限制，可以在 /etc/security/limits.conf 文件末尾添加以下两行：

* soft nofile 65536
* hard nofile 65536

重要提示：在 CentOS 7 中，直接修改此文件可能不会对由 systemd 管理的服务生效，这是因为 systemd 在启动服务时，有自己的一套资源管理机制，其优先级高于 PAM 的 limits.conf，此方法更适用于非 systemd 管理的、通过用户登录启动的进程。

通过 systemd 服务单元文件（推荐方法）

对于由 systemd 管理的服务（如 Nginx、MySQL 等），最可靠、最推荐的方法是直接修改其服务配置文件。systemd 提供了 LimitNOFILE= 指令来专门设置文件描述符限制。

最佳实践是使用 systemctl edit 命令创建一个覆盖配置文件，而不是直接修改原始的单元文件,这样可以避免系统更新时配置被覆盖。

以修改 nginx.service 为例：

1. 创建覆盖配置文件：
   执行以下命令，systemd 会自动在 /etc/systemd/system/nginx.service.d/ 目录下创建一个 override.conf 文件,并打开编辑器。

   systemctl edit nginx.service

2. 添加配置内容：
   在打开的编辑器中，输入以下内容。[Service] 部分用于指定服务级别的配置。

   [Service]
   LimitNOFILE=65536

   保存并退出编辑器。

3. 重新加载配置并重启服务：
   让 systemd 重新加载所有单元文件，然后重启 Nginx 服务使配置生效。

   

   systemctl daemon-reload
   systemctl restart nginx.service

4. 验证配置：
   可以使用 systemctl show 命令来验证配置是否已成功应用。

   systemctl show nginx.service | grep LimitNOFILE

   输出应包含 LimitNOFILE=65536,表明设置已生效。

全局 systemd 配置

如果希望对所有 systemd 管理的服务都提高默认的文件描述符限制，可以修改 /etc/systemd/system.conf 文件。

找到并取消以下两行的注释（或直接添加）,然后设置期望的值：

DefaultLimitNOFILE=65536
DefaultLimitNOFILESoft=65536

修改后，需要执行 systemctl daemon-reexec 或重启系统才能使全局配置生效。

---

相关问答 (FAQs)

我已经在 /etc/security/limits.conf 文件中为用户 nginx 设置了 nofile 限制，但重启 Nginx 服务后，使用 cat /proc/$(pidof nginx)/limits 查看到的限制值依然是默认的 1024，这是为什么？

解答：这个问题的根本原因在于 CentOS 7 使用 systemd 管理服务。systemd 在启动服务时，其自身的资源控制逻辑（如服务单元文件中的 LimitNOFILE= 指令）会覆盖 /etc/security/limits.conf 中的设置，对于 systemd 管理的服务，修改 limits.conf 是无效的，正确的做法是使用 systemctl edit nginx.service 命令来创建一个覆盖配置文件，在其中设置 LimitNOFILE=，然后通过 systemctl daemon-reload 和 systemctl restart nginx.service 来应用更改。

我应该把 ulimit -n 的值设置多大？有没有一个最佳实践值？

解答：ulimit -n 的值没有一个固定的“最佳值”，它完全取决于你的应用程序类型、服务器硬件（尤其是内存）以及预期的并发负载，设置得过低会成为瓶颈，设置得过高则会浪费内存资源，因为每个文件描述符都会消耗少量内核内存，一个合理的做法是：监控你的应用在高负载下的文件描述符使用情况，例如使用 lsof -p <pid> | wc -l 来统计某个进程当前打开的文件数，根据这个峰值并留出一定的余量（50% 到 100%）来设定一个合理的值，对于大多数现代高负载服务器，将此值设置为 65536 (64K) 或 1048576 (1M) 是一个常见的起点,最科学的决策应基于性能测试和持续监控。