最可靠做法是将关键进程oom_score_adj设为-1000实现内核级免杀，再结合cgroup v2限制非关键进程内存、调优vm.panic_on_oom等内核参数，并部署earlyoom前置干预，形成分层防护体系。
Webman 本身不直接控制内核参数，但它的高并发表现极度依赖 Linux 网络与内存子系统的配合；盲目调大 net.core.somaxconn 或设 vm.swappiness=0 可能导致连接失败或 OOM killer 杀进程。
Webman 进程模型对内核资源的真实消耗
Webman 默认使用 Swoole 的多进程 Reactor-Worker 模型：1 个 Master 进程 + N 个 Manager 进程 + M 个 Worker 进程 + 若干 Task 进程。每个 Worker 默认独占一个 CPU 核心，且会为每个 TCP 连接分配独立的 socket 缓冲区和文件描述符。
这意味着：
- 并发连接数直接受
fs.file-max和用户级nofile限制，不是 Webman 配置里改个worker_num就能突破的 - 大量短连接（如 WebSocket 心跳）会快速堆积
TIME_WAIT状态，若net.ipv4.tcp_tw_reuse=0，新连接可能被拒绝 - Worker 进程数超过物理核心数时，上下文切换开销陡增，
vmstat 1 5中的cs（context switch）值会明显跳升 - Task 进程执行阻塞 I/O（如同步写日志、调用未协程化的 SDK）会导致整个 Worker 被挂起，此时内核网络队列积压，
ss -s显示inuse高而orphans上升
必须配对调整的三个关键内核参数
这三个参数在 Webman 场景下必须一起看、一起调，单点优化无效：
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
net.core.somaxconn：内核层面 accept 队列最大长度。Webman 的swoole_server->set(['backlog' => 65535])不能超过它，否则多余连接被内核静默丢弃。建议设为65535（需确认内核 ≥ 5.4） -
net.ipv4.tcp_max_syn_backlog：SYN 半连接队列大小。Webman 在突发流量下（如秒杀）易触发 SYN Flood，此值低于net.core.somaxconn会导致连接在三次握手阶段就被丢。建议设为262144（注意：老内核如 4.18 最大只支持 65535） -
net.core.netdev_max_backlog：网卡软中断收包队列长度。当 Webman Worker 处理不过来时，未及时 pull 的数据包会堆积在此。若该值过小（默认常为 1000），会触发丢包，netstat -s | grep "packet receive errors"可见计数上升。建议设为30000
Webman 场景下 vm.swappiness 的真实取值逻辑
很多指南无脑写 vm.swappiness=0，但在 Webman 实际部署中，这个值是否合理取决于你的内存压力类型：
- 如果你的 Webman 应用常驻内存（如加载了大缓存、Swoole Table），且物理内存充足（比如 64G 机器只跑 20G RSS），
vm.swappiness=1是更稳的选择——它允许内核在极端内存碎片时换出少量匿名页，避免 OOM killer 启动 - 如果你用
swoole_table存储海量会话，并启用了swappiness=0，当系统出现短暂内存峰值（如日志刷盘+GC 同时发生），内核可能因无法回收 page cache 而直接触发 OOM - 不要设
vm.swappiness=0后就不管/proc/sys/vm/overcommit_memory：Webman 的共享内存段（如swoole_shm）受其约束，默认0（启发式）可能导致shmget失败，建议显式设为1（永远允许）或2（按vm.overcommit_ratio计算）
容易被忽略的 NUMA 与 CPU 绑核协同问题
Webman Worker 进程默认不绑定 CPU，而在 NUMA 架构服务器（如双路 EPYC 或 Xeon Scalable）上，跨 NUMA 节点访问内存延迟可高达 3 倍。这不是内核参数能解决的，但必须和内核调优联动：
- 先用
numactl --hardware查清节点布局，再用taskset -c 0-7 php start.php start把 Webman 主进程绑到特定 CPU 核心范围 - 同时确保
/proc/sys/vm/zone_reclaim_mode为0（默认），否则 Worker 在本地节点内存不足时不会主动跨节点分配，而是触发直接回收，造成毛刺 - 若使用 Swoole 5.0+，可在
swoole_server->set()中启用'open_cpu_affinity' => true，它会自动将每个 Worker 绑定到不同核心——但前提是启动前已用taskset限定了可用 CPU 范围，否则仍可能跨 NUMA
真正卡住性能的，往往不是单个参数的数值，而是参数之间、参数与进程行为、硬件拓扑之间的隐含耦合。比如把 tcp_max_syn_backlog 调到 262144 却忘了同步调大 net.core.somaxconn，或者开了 tcp_tw_reuse 却没配 net.ipv4.ip_local_port_range 导致端口耗尽——这些细节比“调多少”更重要。
