Linux systemd 服务怎么限制打开文件数和进程数

服务一到高并发就报“Too many open files”，或者不断拉起子进程后被系统拒绝，通常不是把 ulimit 写进登录用户配置就能解决。由 systemd 启动的服务，应在对应的 unit 中声明限制，再重载并重启服务。

实用的分工是：用 LimitNOFILE 限制每个服务进程能打开的文件描述符；用 TasksMax 限制一个 systemd unit 内的进程和线程总量；只有需要 Linux RLIMIT_NPROC 语义时，才额外使用 LimitNPROC。

先分清三个限制到底管什么

这三个参数经常被放在同一段配置里，但它们不是同一层。LimitNOFILE 对应进程的文件描述符资源限制，服务进程打开 socket、日志、配置文件时都会消耗它。写成一个值时通常同时设置软、硬上限；写成两个值则按“软值:硬值”分别设置。

LimitNPROC 对应 RLIMIT_NPROC，判断边界时要考虑用户身份和内核的 rlimit 语义。它不等于“这个 unit 里最多允许多少个任务”。如果目标是控制某个 service 及其子进程、线程的总量，TasksMax 的 cgroup 边界更接近问题本身。

用 drop-in 写入服务级限制

下面以 myapp.service 为例。drop-in 会放在 systemd 管理的覆盖目录中，升级软件包时不容易被原始 unit 覆盖。

sudo systemctl edit myapp.service

在编辑器中写入：

[Service]
# 每个服务进程的文件描述符软、硬上限
LimitNOFILE=65535:65535
# 限制该 unit 内所有进程和线程的总任务数
TasksMax=4096
# 只有需要 RLIMIT_NPROC 语义时才启用这一项
LimitNPROC=4096:4096

如果你只想解决连接数过多导致的文件描述符耗尽，可以先保留 LimitNOFILE，不要为了“看起来完整”盲目增加 LimitNPROC。如果服务会创建大量线程，TasksMax 应按进程与线程总量一起估算。

LimitNPROC 和 TasksMax 不在同一层

最容易误判的场景是：把 LimitNPROC=4096 当成 unit 的总任务上限，结果服务仍可能因为线程数量达到 cgroup 边界而启动失败；也可能多个服务共用同一 UID，导致按 UID 计算的 rlimit 互相影响。需要 unit 隔离时，优先观察 TasksCurrent 和 TasksMax。

因此，配置“进程数”之前先写清楚口径：是限制某个 UID 的 rlimit，还是限制一个服务树的全部任务。前者看 LimitNPROC，后者看 TasksMax。对于线程密集型程序，后者通常更符合运维预期。

重载后用三层结果确认是否生效

只看到 drop-in 文件存在还不够。先让 manager 重新读取配置，再重启服务，让新的限制进入新进程：

# 重新读取 unit 文件，然后创建带新限制的服务进程
sudo systemctl daemon-reload
sudo systemctl restart myapp.service

# 查看 manager 当前保存的限制和 cgroup 任务计数
systemctl show myapp.service -p LimitNOFILE -p LimitNPROC -p TasksCurrent -p TasksMax

接着取服务主进程的 PID，检查进程实际收到的 rlimit。这里的结果可以解释“unit 配了，但程序仍然报错”的情况：

# 读取主进程 PID；PID 为 0 通常表示服务没有正常运行
MAINPID=$(systemctl show myapp.service -p MainPID --value)

# 只查看打开文件和进程资源限制，避免被其他 /proc 字段干扰
sudo awk '/Max open files|Max processes/ {print}' "/proc/$MAINPID/limits"

预期能看到类似 Max open files 和 Max processes 的软值、硬值。如果 systemctl show 的配置值正确而 /proc 仍是旧值，优先检查是否真的重启了服务，以及查询的 PID 是否已经变化。

常见问题

为什么改了 /etc/security/limits.conf，systemd 服务还是不变？

登录会话的 PAM limits 与 systemd 启动的 system service 不是同一条继承链。服务级限制应直接写在 unit 或 drop-in 中，并在重启后检查主进程的 /proc 限制。

LimitNOFILE 写 65535 还是 65535:65535？

只需要同一个软、硬上限时，两种写法的意图接近；写成带冒号的形式更明确，也便于以后把软值和硬值调整成不同数值。

TasksMax 设置后为什么线程也会被算进去？

systemd 的任务限制面向 cgroup 中的任务，进程至少包含一个线程，线程数增长也会消耗任务额度。线程池上限应与 TasksMax 一起设计。

排查这类限制时，先判断要限制的是文件描述符、按 UID 的 rlimit，还是 unit 的 cgroup 任务总量；再按对应层级配置和验证，通常比单纯把数字调大更容易得到稳定结果。