最准确的系统级最大PID数是cat /proc/sys/kernel/pid_max返回的实时值，x86_64默认为32768或4194304，超4194304会被静默截断；ulimit -u是用户级限制，systemd服务需单独配置LimitNPROC，三者取最小值决定实际上限。

直接看内核参数 /proc/sys/kernel/pid_max

这是最准确、最实时的系统级最大 PID 数（即进程+线程总数上限），Linux 中所有进程和线程共享这个 PID 池。cat /proc/sys/kernel/pid_max 输出的值就是当前生效的硬上限。

常见值：x86_64 系统默认通常是 32768 或 4194304；32 位系统多为 32768。超过 4194304 的写入会被内核静默截断，不报错但不生效。

别用 sysctl kernel.pid_max 查——它可能返回缓存值，而 /proc/sys/ 下的是内核运行时真实状态。

ulimit -u 显示的是用户级限制，不是系统上限

ulimit -u 输出的是当前 shell 及其子进程（包括 Java 所有线程）能使用的最大 PID 数，它受 /etc/security/limits.d/ 配置控制，但只对新登录会话生效。

常见陷阱：

• 普通用户常被设为 1024 或 4096，远低于 pid_max，但高并发应用一开几千线程就爆
• 改了 /etc/security/limits.conf 后没新开 shell，ulimit -u 仍显示旧值
• systemd 服务完全忽略 limits.conf，必须在 .service 文件里加 LimitNPROC=

真正卡住 fork 的，是 pid_max 和 ulimit -u 的交集

进程创建失败时，错误往往是 fork: Cannot allocate memory，但 dmesg | tail 会看到 PID allocation failure——这不是内存不足，是 PID 耗尽。

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

验证方法：

• 已用 PID 数：ls /proc/[0-9]* | wc -l（轻量，推荐）或 ps -e --no-headers | wc -l
• 剩余空间 = cat /proc/sys/kernel/pid_max 减去已用数
• 如果剩余 > 0 但 still fork 失败，说明 ulimit -u 更小，成了瓶颈

容器和 systemd 场景下容易漏掉的配置点

Docker 默认继承宿主机 ulimit -u，但不会自动加载 /etc/security/limits.d/；Kubernetes 和 systemd 则完全绕过该机制。

必须显式配置：

• Docker 启动时加：--ulimit nproc=65535:65535
• Kubernetes Pod：securityContext.limits.nproc: 65535
• systemd 服务：LimitNPROC=65535 写进 .service 文件，或全局设 DefaultLimitNPROC=65535 在 /etc/systemd/system.conf

调优时只改 pid_max 或只调 ulimit 都不够——两者都要对齐，且 ulimit -u 不能超过 pid_max，否则多余部分无意义。