4.4.1 ulimit与资源限制模型

本节围绕 Linux 进程资源限制模型展开，重点解析 ulimit 的配置方式、内核限制项与典型运维场景的调优思路，建立“限制—观测—优化”的闭环，并提供可执行示例、排错流程与练习。

1. 资源限制模型概览#

Linux 通过 rlimit 为进程提供资源配额控制，分为软限制（soft）与硬限制（hard）：
- 软限制：运行时可临时调整，进程自我约束的上限
- 硬限制：系统级上限，只有特权用户可提高

常见限制项：
- 最大打开文件数（nofile）
- 最大进程数（nproc）
- 最大栈大小（stack）
- 最大核心转储大小（core）
- 最大锁定内存（memlock）
- 最大消息队列（msgqueue）

原理草图（进程继承限制）：

文章图片

2. ulimit 常见用法与影响#

ulimit 为 shell 内置命令，修改当前 shell 及其子进程的限制。

查看当前限制：

ulimit -a

设置最大文件数（当前会话生效）：

ulimit -n 65535
ulimit -n
# 预期输出：65535

设置最大进程数（当前会话生效）：

ulimit -u 4096
ulimit -u
# 预期输出：4096

设置 core 文件大小：

ulimit -c unlimited
ulimit -c
# 预期输出：unlimited

命令解释要点：
- -n：nofile，打开文件数上限
- -u：nproc，用户可创建的进程数
- -c：core 文件大小上限
- -a：查看所有限制

3. 系统级配置与持久化#

推荐通过 limits 与 PAM 组合实现持久化。

1）编辑 limits 配置：

sudo tee /etc/security/limits.d/99-custom.conf >/dev/null <<'EOF'
* soft nofile 65535
* hard nofile 65535
* soft nproc  4096
* hard nproc  4096
mysql soft nproc 8192
mysql hard nproc 8192
EOF

2）确认 PAM 生效（以 RHEL 系列为例）：

grep -n "pam_limits.so" /etc/pam.d/system-auth /etc/pam.d/sshd
# 预期包含：session required pam_limits.so

3）systemd 服务设置（以 nginx 为例）：

sudo systemctl edit nginx

填入：

[Service]
LimitNOFILE=65535
LimitNPROC=4096
LimitCORE=infinity

应用并重启：

sudo systemctl daemon-reload
sudo systemctl restart nginx

验证进程限制：

pid=$(pidof nginx | awk '{print $1}')
cat /proc/$pid/limits

4. 典型场景与建议值#

高并发中间件与数据库通常需要提高限制：

  • Nginx：nofile ≥ 65535
  • MySQL：nofile 与 nproc 提升至数千至上万
  • Redis：nofile 满足连接峰值
  • Kafka：nofile 与 memlock 影响吞吐

配套内核参数检查：

# 文件句柄上限
sysctl fs.file-max
# 进程号上限
sysctl kernel.pid_max

示例：同时提升内核与限制值

sudo sysctl -w fs.file-max=1048576
sudo sysctl -w kernel.pid_max=4194304

sudo tee /etc/sysctl.d/99-limits.conf >/dev/null <<'EOF'
fs.file-max=1048576
kernel.pid_max=4194304
EOF

5. 常见问题排查#

常见报错与定位方式：
- Too many open files → nofile 与 fs.file-max
- 进程无法创建线程 → nproc 与线程栈
- core 文件不生成 → ulimit -c 与 kernel.core_pattern

排错流程（示例）：

# 1. 查看当前进程限制
pid=$(pidof mysqld | awk '{print $1}')
cat /proc/$pid/limits

# 2. 查看系统级文件句柄
sysctl fs.file-max

# 3. 确认服务启动方式
systemctl status mysqld | sed -n '1,10p'

# 4. 查看 unit 限制
systemctl show mysqld | grep -E 'LimitNOFILE|LimitNPROC|LimitCORE'

core 文件排错：

ulimit -c
sysctl kernel.core_pattern
# 若 core_pattern 指向管道或目录，确保有写权限

6. 运维建议与最佳实践#

  • 基线中统一规划限制值，避免不同主机不一致
  • 关键服务使用专属 limits 配置与 systemd Limit*
  • 配合监控采集限制命中率与使用水位
  • 修改限制后必须重启服务并做压测

监控采集示例（基础思路）：

# 采集所有进程限制快照（可定时）
for p in /proc/[0-9]*; do
  pid=${p##*/}
  comm=$(tr -d '\0' < $p/comm 2>/dev/null)
  printf "%s %s\n" "$pid" "$comm" >> /var/log/proc_comm.log
done

7. 练习与实操#

1）将当前会话 nofile 提升到 65535，并启动一个测试进程，验证限制继承：

ulimit -n 65535
sleep 300 &
cat /proc/$!/limits | grep "Max open files"

2）为 nginx 设置 systemd 限制，重启后确认生效：

sudo systemctl edit nginx
# 设置 LimitNOFILE=65535
sudo systemctl daemon-reload
sudo systemctl restart nginx
pid=$(pidof nginx | awk '{print $1}')
cat /proc/$pid/limits | grep "Max open files"

3）模拟 “Too many open files”：

ulimit -n 64
python3 - <<'PY'
import os
files=[]
try:
    for i in range(1000):
        files.append(open('/dev/null','r'))
except Exception as e:
    print("error:", e)
PY
# 预期输出：Too many open files

完成以上练习后，总结限制调整对业务进程的影响，并记录系统与服务级配置的差异。