5154

在 Linux 系统管理中，资源控制是确保系统稳定、公平分配资源以及防止个别进程耗尽系统资源的关键环节，在 CentOS 7 这类广泛用于服务器的发行版中，ulimit 命令是管理员进行资源限制管理的核心工具之一，通过 ulimit -a，我们可以全面地查看当前 shell 会话下，用户进程所能使用的各类资源的上限，本文将深入解析 ulimit -a 的输出内容，探讨软限制与硬限制的区别，并详细介绍如何在不同场景下修改这些限制,以优化系统性能和稳定性。

ulimit -a 输出详解

当在终端中执行 ulimit -a 命令时，系统会列出一系列资源限制，这些限制是针对当前用户和当前 shell 会话的，理解每一项的含义是进行有效配置的第一步,下表详细列出了常见的输出项及其解释：

在这些限制中，open files（打开文件数量）和 max user processes（最大用户进程数）是日常运维中最常遇到瓶颈的两项，高并发的 Web 服务器或数据库服务，很容易因连接数过多而触及 open files 的上限,导致服务拒绝新的连接请求。

软限制与硬限制

ulimit 的资源限制分为两种类型：软限制和硬限制。

• 软限制：这是对资源限制的“软性”约束，普通用户可以自行调整软限制，但只能调高到硬限制所设定的值,软限制是内核真正强制执行的当前限制。
• 硬限制：这是资源限制的“天花板”，由系统管理员设定，普通用户无法提高硬限制，只有 root 用户或具备相应权限的用户才能修改,硬限制的作用是防止普通用户无限制地占用系统资源。

硬限制的值会大于或等于软限制，可以使用 -S 和 -H 标志分别查看软限制和硬限制。ulimit -Sn 查看打开文件数的软限制，ulimit -Hn 查看其硬限制。

如何修改 ulimit 限制

修改 ulimit 限制有临时和永久两种方式,适用于不同的需求场景。

临时修改（当前会话）

这种方式最简单，直接在 shell 中使用 ulimit 命令即可，修改仅对当前 shell 会话及其启动的子进程有效，一旦退出登录或关闭终端,设置就会失效。

# 将当前会话的打开文件数软限制临时提高到 65536
ulimit -n 65536
# 同时设置软限制和硬限制
ulimit -Sn 65536
ulimit -Hn 65536

永久修改（针对特定用户）

要让设置在用户每次登录时都生效，需要修改配置文件，最常用的方法是编辑 /etc/security/limits.conf 文件,该文件的格式为：

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

• domain：可以是用户名、组名（格式为 @groupname）或通配符 （表示所有用户）。
• type：soft 表示软限制，hard 表示硬限制。
• item：要限制的资源项，如 nofile（打开文件数）、nproc（进程数）等。
• value：具体的限制值。

要为 nginx 用户永久设置打开文件数的软限制和硬限制为 65535，可以在 /etc/security/limits.conf 文件末尾添加以下两行：

nginx       soft     nofile    65535
nginx       hard     nofile    65535

注意：修改 limits.conf 文件后，用户需要重新登录才能使设置生效，对于已经运行的服务,需要重启该服务。

系统级全局调整

某些资源，如系统允许打开的总文件数，是由内核参数控制的，而非 ulimit。fs.file-max 定义了整个系统所有进程一共可以打开的文件句柄数，可以通过 sysctl 命令进行动态调整：

# 临时调整
sysctl -w fs.file-max=2097152
# 永久调整，写入 /etc/sysctl.conf
echo "fs.file-max = 2097152" >> /etc/sysctl.conf
sysctl -p

系统级的 fs.file-max 应该大于所有用户 ulimit -n 硬限制的总和,以确保系统有足够的资源池。

实战案例：解决 Nginx "Too many open files" 错误

假设一台运行 Nginx 的 CentOS 7 服务器在高并发下出现 "socket() failed (24: Too many open files)" 错误。

1. 诊断问题：以 nginx 用户身份检查其当前的文件打开数限制。

   su - nginx -c 'ulimit -n'

   假设输出为 1024，这个值对于高并发 Web 服务来说显然太小了。

2. 修改配置：编辑 /etc/security/limits.conf，为 nginx 用户提高限制。

   # 在文件末尾添加
   nginx       soft     nofile    65535
   nginx       hard     nofile    65535

3. 重启服务：为了让 Nginx 进程（由 systemd 管理）加载新的限制，最稳妥的方式是重启 Nginx 服务。

   systemctl restart nginx

4. 验证：再次检查 Nginx 主进程的 nofile 限制。

   # 找到 Nginx 主进程 PID
   cat /var/run/nginx.pid
   # 查看 /proc/<PID>/limits 文件
   cat /proc/$(cat /var/run/nginx.pid)/limits | grep "Max open files"

   输出应该显示 65535,表明修改已成功生效。

   

通过以上步骤，我们不仅解决了眼前的问题，也为服务器的稳定运行提供了更可靠的保障，熟练掌握 ulimit 的配置，是每一位 Linux 系统管理员必备的技能。

相关问答 (FAQs)

Q1: 我已经在 /etc/security/limits.conf 中修改了配置，并且重新登录了，但 ulimit -a 显示的值依然是旧的，这是为什么？

A1: 这个问题在 CentOS 7 及使用 systemd 的现代 Linux 发行版中比较常见,原因可能有两点：

1. PAM 模块未加载：请确保 /etc/pam.d/login 和 /etc/pam.d/sshd 文件中包含了 session required pam_limits.so 这一行，这是 limits.conf 生效的前提，在 CentOS 7 中,这通常是默认配置好的。
2. Systemd 服务：如果你是通过 systemctl start 启动的服务，那么它可能不会完全遵循 /etc/security/limits.conf 的设置，Systemd 有自己的一套资源管理机制，对于由 systemd 管理的服务，更推荐直接在其服务单元文件（.service 文件）中设置限制，对于 Nginx，可以编辑 /usr/lib/systemd/system/nginx.service 文件，在 [Service] 部分添加 LimitNOFILE=65535，然后执行 systemctl daemon-reload 和 systemctl restart nginx，这种方式对 systemd 服务来说更为直接和可靠。

Q2: ulimit -n（打开文件数）和 fs.file-max 有什么区别和联系？

A2: 它们是两个不同层面的限制：

• ulimit -n：这是一个用户/进程级别的限制，它控制的是单个进程能够打开的文件描述符的最大数量，每个用户登录后，其 shell 和启动的进程都会受到这个值的约束。
• fs.file-max：这是一个系统级别的内核参数，它定义了整个 Linux 系统所有进程加起来可以同时打开的文件描述符的总数上限。

联系：ulimit -n 的值不能超过 fs.file-max 的值，可以把 fs.file-max 想象成一个水库的总蓄水量，而每个用户的 ulimit -n 则是分配给他的水桶大小，如果水库总水量不足，那么即使水桶再大，也无法装满水，在调整 ulimit -n 时，通常也需要确保 fs.file-max 有一个足够大的值,以容纳所有用户进程的需求。