Linux 进程卡住别急着 kill -9 — ps 状态会暴露真因

AI 模型部署大多跑在 Python 进程上，遇到卡死用 kill -9 收尾的代价很贵。本周掘金一篇工程笔记提醒：先看状态再决定怎么结束。

这是什么

作者写了一个约 30 行的 Python 程序，同时启动三个子进程：读管道阻塞的 reader（呈现 S 状态）、死循环计算的 worker（R 状态持续吃 CPU）、fork 后不被父进程回收的子进程（短暂出现 Z 僵尸）。配合 ps、/proc/<pid>/status 和 wchan，演示如何从 STAT 列判断根因：R 看调度与计算热点、S 看 I/O 与锁、D 看底层设备、Z 看父进程是否调用了 wait 系列回收。

行业怎么看

这套方法不算新东西，ps 手册与《Linux Performance Tuning》都覆盖过。文章真正值得收藏的是「可复现」：用一段本地代码就能造出三种典型状态，避免排查时只能依赖生产样本。但局限也明确——wchan 在不同内核与发行版上可能显示为「-」或裸地址，不能直接当结论用；生产环境切忌用宽泛的 pkill -f 收尾，极易误伤同名服务。更深一层，AI 框架的卡死常常发生在 GPU 等待、Python GIL 与数据加载交叉处，单纯看用户态进程状态未必够用。

对普通人的影响

对企业 IT：跑模型推理、消息队列或定时任务的技术栈，多数问题最终落到 R/S/D/Z/I 这几种状态之一，团队值得把 ps -L 与 pidstat 列入值班手册。 对个人职场：AI 工程师常被训练「调模型」，但生产环境卡死往往不是模型问题，而是进程卡在系统调用或 I/O 上，调试能力被严重低估。 对消费市场：影响间接；用户感知不到，但每次「服务短暂不可用」背后，可能都是一次粗暴 kill -9 的代价。