Linux调整进程数解决资源限制

Linux系统中，高并发场景下进程或线程创建失败（如“Resource temporarily unavailable”或Java的“unable to create new native thread”）往往并非内存不足，而是受双重PID限制——用户级`ulimit -u`（限制单用户进程+线程总数）与系统级`/proc/sys/kernel/pid_max`（内核可分配PID上限）共同制约；二者必须同步调大且正确生效：`ulimit -u`需通过PAM配置`limits.conf`并显式适配systemd服务或容器环境（Docker/K8s需单独设置），而`pid_max`须通过`sysctl`永久调整；仅修改其一、忽略systemd不继承limits.conf、或未在容器内覆盖默认限制，都会导致调优失效——真正有效的验证方式是直接用`prlimit -n $PID`检查目标进程的实际限制值。

直接结论：改 ulimit -u（用户级）和 /proc/sys/kernel/pid_max（系统级）两个地方，缺一不可；只改一个，高并发场景下仍会报 Resource temporarily unavailable。

为什么 ulimit -u 改了还是创建不了线程？

Linux 中线程也占 PID，ulimit -u 限制的是“该用户所有进程 + 线程总数”，不是纯进程数。很多服务（如 Java 应用、Node.js cluster）默认启多线程，很容易打满这个值。

• 现象：Java 启动报 java.lang.OutOfMemoryError: unable to create new native thread，但内存充足；ps -eLf | wc -l 显示线程数接近 ulimit -u 值
• 关键点：ulimit -u 是 per-user 限制，对 systemd 服务默认不生效——因为 systemd 不读 /etc/security/limits.conf，除非显式配置
• 验证方式：在目标用户下开新 shell，运行 ulimit -u；再进对应服务的进程里用 prlimit -n $PID 查实际生效值
• 临时绕过：启动前加 ulimit -u 65535 && ./your-app，仅限调试

怎么永久生效 ulimit -u？注意 PAM 和 systemd 两层加载

/etc/security/limits.conf 配置不会自动被所有登录方式加载，必须确保 PAM 模块启用，且 systemd 服务额外声明。

• 编辑 /etc/security/limits.conf，添加（不要用空格分隔数字）：
  * soft nproc 65535
* hard nproc 65535
• 确认 /etc/pam.d/common-session 和 /etc/pam.d/common-session-noninteractive 中存在：
  session required pam_limits.so
• systemd 服务必须显式设置：
  在 /etc/systemd/system/your-service.service 的 [Service] 段加：
  LimitNPROC=65535
  或全局生效：在 /etc/systemd/system.conf 中设 DefaultLimitNPROC=65535，再运行 systemctl daemon-reload
• 生效前提：用户需重新登录（SSH 或 console），或重启对应 service

/proc/sys/kernel/pid_max 设太小会导致 fork 失败

pid_max 是内核能分配的 PID 上限，也是系统理论最大进程/线程总数。当 ulimit -u 调得很高，但 pid_max 还卡在默认 32768，就会出现“用户允许开 65535 个线程，但内核连 PID 都分不出”的情况。

• 查看当前值：cat /proc/sys/kernel/pid_max（x86_64 默认 32768，部分发行版可能为 4194304）
• 临时修改：sysctl -w kernel.pid_max=4194304
• 永久修改：在 /etc/sysctl.conf 加 kernel.pid_max = 4194304，再执行 sysctl -p
• 注意上限：pid_max 最大值受架构限制（x86_64 是 4194304），设更大无效；threads-max 也不应显著超过它，否则多余线程无法调度

容器环境（Docker/K8s）要单独覆盖

容器默认继承宿主机的 ulimit -u，但多数生产环境没配，导致容器内应用一开多线程就失败。

• Docker 启动时加：--ulimit nproc=65535:65535（软硬限制都设）
• Kubernetes Pod spec 中写：
  securityContext:
  limits:
    nproc: "65535"
• 验证容器内是否生效：docker exec -it your-container sh -c 'ulimit -u'
• 别依赖宿主机 limits.conf —— 容器 init 进程不走 PAM 流程

最容易被忽略的是 systemd 服务不自动读 limits.conf，以及容器环境完全隔离了宿主机 ulimit 设置。调参后务必用 prlimit -n $PID 直接查目标进程的实际限制，而不是只信 ulimit -u 当前 shell 的输出。

以上就是《Linux调整进程数解决资源限制》的详细内容，更多关于的资料请关注golang学习网公众号！