当前系统最大pid数由kernel.pid_max决定，即理论进程数上限；x86_64默认为4194304，可通过cat /proc/sys/kernel/pid_max或sysctl kernel.pid_max查看。

Linux 系统最大进程数不是单一配置决定的，而是由 kernel.pid_max（全局 PID 池）和 ulimit -u（用户级 nproc 限额）共同约束；只改一个，另一层仍会拦截新进程创建。

怎么看当前系统最大 PID 数（即理论最大进程数）

这个值是内核硬上限，决定了整个系统能分配多少个 PID（含进程和线程），不等于实际能跑多少个进程，但它是天花板。

• cat /proc/sys/kernel/pid_max —— 最直接，读取运行时值
• sysctl kernel.pid_max —— 效果同上，更符合 sysadmin 习惯
• 注意：x86_64 默认是 4194304（2²²），32 位系统通常为 32768；超过该值写入会失败

为什么 ulimit -u 显示 65535 却还是 fork 失败？

因为 ulimit -u 控制的是单个用户能拥有的进程+线程总数（Linux 中线程也占 PID），但它不能突破 kernel.pid_max 剩余空闲 PID 数。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 假设 pid_max=65536，当前已用 65500 个 PID，那即使你 ulimit -u 100000，该用户最多也只能再创建 36 个进程/线程
• 常见错误现象：fork: Cannot allocate memory —— 这不是内存不足，而是 PID 耗尽；dmesg | tail 可看到 "PID allocation failure"
• 验证当前 PID 使用量：ps -eLf | wc -l（含线程）或 ls /proc/[0-9]* | wc -l（更轻量）

怎么安全调大 kernel.pid_max

增大 PID 池本身开销很小（每个 PID 对应一个 struct pid，约几十字节），但过大会略微增加 PID 查找延迟；一般无需超过 4194304。

• 临时生效（重启失效）：sysctl -w kernel.pid_max=4194304
• 永久生效：在 /etc/sysctl.conf 末尾加一行 kernel.pid_max = 4194304，再执行 sysctl -p
• 别设太高：x86_64 架构上限约 4194304；设成 8388608 可能被内核静默截断，且 kernel.threads-max 应 ≤ pid_max，否则无效

容器和 systemd 服务里 nproc 容易漏配

容器默认继承宿主机 ulimit -u，但 Docker/Kubernetes 不自动加载 /etc/security/limits.conf；systemd 服务则完全忽略该文件，除非显式配置。

• Docker 启动时加：--ulimit nproc=65535:65535
• Kubernetes Pod 中需在 securityContext 设置：limits.nproc: 65535
• systemd 服务需在 .service 文件中写：LimitNPROC=65535，或全局设 DefaultLimitNPROC=65535 在 /etc/systemd/system.conf
• 修改 /etc/security/limits.d/20-nproc.conf 后，必须新开 shell 才生效；已有进程不受影响

真正卡住进程创建的，往往是 pid_max 和 ulimit -u 的交集，而不是其中某一个。查问题时先看 ps -eLf | wc -l 和 cat /proc/sys/kernel/pid_max 的差值，比盲目调高 ulimit 更有效。