如何优化Ubuntu ulimit的性能 - 问答

Ubuntu ulimit 性能优化实操指南

一核心原则与风险边界

ulimit 只影响当前 shell 及其子进程，对系统其他用户或已运行的 systemd 服务不生效；要全局生效需分别配置登录会话与 systemd。
提升限制并非越高越好，应与应用需求、内存与文件句柄总量匹配，避免资源争用与稳定性风险。
高并发服务（如 Nginx、Docker、Kafka、Elasticsearch）常因 打开文件描述符不足出现 “Too many open files”，需优先优化相关限制。

二系统级与登录会话的持久化配置

统一用户限制（推荐在 /etc/security/limits.d/ 新建文件，避免直接改 limits.conf）：
1. 新建配置：sudo nano /etc/security/limits.d/99-nofile.conf
2. 写入示例：
```
*    soft    nofile  65536
*    hard    nofile  65536
```
启用 PAM 限制加载：确保 /etc/pam.d/common-session 与 /etc/pam.d/common-session-noninteractive 包含：
```
session required pam_limits.so
```
使配置生效：重启或重新登录；验证：在新开终端执行 ulimit -n（应返回 65536）。

三针对 systemd 服务的专属设置

修改 systemd 默认上限：编辑 /etc/systemd/system.conf 与 /etc/systemd/user.conf，设置：
```
DefaultLimitNOFILE=65536
```

重新加载并重启目标服务：

sudo systemctl daemon-reload
sudo systemctl restart nginx   # 示例

验证服务级限制：

sudo systemctl show nginx | grep LimitNOFILE

说明：登录会话与 systemd 是两套机制，仅改其一会导致服务或登录会话限制不一致。

四关键参数建议与典型场景

打开文件描述符（nofile）：多数生产业务建议 ≥ 65536；极高并发可提升到 1048576，但需确保内核与内存能支撑。
最大进程数（nproc）：结合业务并发与容器/虚拟化环境设置，避免过大导致调度与内存压力。
内存相关（谨慎）：
- ulimit -v（虚拟内存，KB）：如 2097152 表示 2GB；
- ulimit -m（物理内存，KB）：如 1048576 表示 1GB；
- ulimit -d（数据段，KB）：如 524288 表示 512MB；
- ulimit -s（堆栈，KB）：如 1048576 表示 1GB。
典型场景示例：
- 通用高并发服务：nofile 65536；
- 极高并发/大连接：nofile 1048576（需内核与内存配合）；
- 内存控制与 OOM 规避：按需设置 -v/-m/-d/-s，避免无限制导致资源被单一进程耗尽。

五验证与排错清单

登录会话验证：

ulimit -n        # 打开文件描述符
ulimit -u        # 最大进程数
ulimit -v        # 虚拟内存(KB)
ulimit -m        # 物理内存(KB)
ulimit -d        # 数据段(KB)
ulimit -s        # 堆栈(KB)

systemd 服务验证：

sudo systemctl show <service> | grep LimitNOFILE

常见问题与修复：
- 改了 limits.conf 但 ulimit -n 不变：检查 /etc/pam.d/common-session 是否包含 pam_limits.so；
- 服务限制未提升：确认 /etc/systemd/system.conf 与 /etc/systemd/user.conf 的 DefaultLimitNOFILE 已设置并 daemon-reload 后重启服务；
- 仅临时生效：将 ulimit -n 65536 写入 ~/.bashrc 或 /etc/profile 仅对登录会话有效，不能影响 systemd 服务。

0 赞

0 踩