pid_max 设置不生效需检查是否持久化：临时写入/proc/sys仅当前有效，应配置/etc/sysctl.d/并运行sysctl --system；32位内核默认32768非硬件限制，但建议不超过65536；容器中须在宿主机修改；超限后内核会重试回收僵尸进程而非立即失败。
pid_max 设置后不生效？检查内核是否真的加载了新值
改完 /proc/sys/kernel/pid_max 看似成功，但新进程 PID 还是卡在 32768，大概率是只写了临时值，没持久化或被 systemd/sysctl 覆盖。Linux 内核启动时会从 /etc/sysctl.conf 或 /etc/sysctl.d/*.conf 加载初始值，之后你用 echo 1000000 > /proc/sys/kernel/pid_max 只影响当前运行时——一旦重启就回退。
- 确认当前生效值：
cat /proc/sys/kernel/pid_max - 写入永久配置：在
/etc/sysctl.d/99-pidmax.conf里加一行kernel.pid_max = 1048576，再执行sysctl --system - 注意 systemd 环境下，
systemd-sysctl服务可能在 boot 时覆盖手动 echo 的值，所以必须走 sysctl 配置文件路径
32bit 系统上 pid_max 最大只能设到 32768？不是内核限制，是默认编译选项
很多老服务器跑的是 32bit x86 内核（比如 i686），pid_max 默认确实是 32768，但这不是硬件级天花板，而是内核编译时 CONFIG_BASE_SMALL=0 下的保守设定。64bit 内核默认上限是 2^22（4194304），而 32bit 内核只要重新编译、打开 CONFIG_PID_MAX_DEFAULT 并设足够大（比如 1048576），也能支持——但实际极少这么做，因为 32bit 用户空间进程本身受限于地址空间，大量 fork() 容易 OOM。
- 查当前内核架构：
uname -m（输出i386或i686是 32bit；x86_64是 64bit） - 32bit 内核最大安全值建议不超过 65536，再高会导致
struct pid哈希表膨胀、调度延迟上升 - 64bit 系统别盲目拉到 4194304——如果容器密度高（如 k8s node），PID 哈希冲突概率上升，
fork()平均耗时可能增加 5%~10%
容器环境（Docker / containerd）里改 pid_max 没用？得进 init namespace 改
在容器里执行 echo 1000000 > /proc/sys/kernel/pid_max 会报 Permission denied，因为容器默认运行在非 init PID namespace，而 /proc/sys/kernel/pid_max 是全局参数，只能由 host 的 init namespace（即 PID 1 所在 namespace）修改。即使你用 --privileged 启动容器，也改不了这个值——它不属于容器自己的 cgroup 控制域。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 真正有效的做法：在宿主机改（见第一个副标题），然后重启容器
- 如果用 systemd + cgroup v2，可通过
TasksMax单独限制某 service 的 PID 数量，和pid_max无关，别混淆 - Pod 中看到
fork: Resource temporarily unavailable，先看cat /proc/sys/kernel/pid_max和ps -eL | wc -l，再确认是不是宿主机整体 PID 耗尽，而非容器内部限制
超过 pid_max 后的行为：不是立即失败，而是有重试窗口
当系统 PID 分配器用完所有可用编号（从 1 到 pid_max），内核不会马上返回 EAGAIN。它会先尝试回收已退出但尚未被 wait() 的僵尸进程 PID，再 scan 一遍空闲槽位——这个过程最多重试 10 次，每次 sleep 微秒级。所以你会看到 fork() 延迟突增，而不是立刻报错。这也是为什么压测时偶尔出现 “fork 失败” 但 ps 显示进程数远低于 pid_max。
- 监控真实压力：用
cat /proc/sys/kernel/pid_max和cat /proc/sys/kernel/pid_allocated对比（后者 5.11+ 内核才支持） - 旧内核无
pid_allocated？用ps -eo pid= | wc -l估算，但注意包含线程（LWP），更准的是ls /proc/[0-9]* 2>/dev/null | wc -l - pid_max 不是“并发进程数”，而是“同时存活的 PID 总数”，包括僵尸进程 —— 忘记 wait() 的父进程会让 PID 泄漏，比调大 pid_max 更值得优先排查
事情说清了就结束
