挂起与变慢不是一回事
进程还在、端口还在监听，但请求不再返回，这种状态叫挂起。常见成因是死锁、多机通信卡死、显存被占满后无法推进，或者上下文损坏。先用一分钟的吞吐与队列曲线判断是完全不动还是缓慢推进，两种情况处置路径完全不同。诊断入口是不重启进程直接抓取调用栈。
基本信息
| 适用平台 | Linux 服务器，抓栈依赖内核的调试接口 |
|---|---|
| 常用工具 | py-spy、dmesg、nvidia-smi |
| 权限要求 | 抓栈与读内核日志需要 root 或等效权限 |
| 判定顺序 | 先看曲线确认挂起，再抓栈，最后才动重启 |
典型使用场景
- 请求超时集中爆发：先确认真挂还是慢，避免误重启丢掉现场
- 卡在多机通信：核对网络与通信超时配置，这类卡死通常不会自愈
- 卡在显存分配：结合显存水位判断是否被并发挤爆
- 内核日志出现 GPU 错误：上下文可能已损坏，按维护流程重启进程
- 完全抓不到栈：先保全日志与设备状态，再升级处置
抓 Python 栈（不重启进程）
抓 Python 栈（不重启进程）
pip install py-spy # 建议装在独立环境，避免污染服务依赖
py-spy dump --pid <引擎PID> # 查看各线程当前调用栈
py-spy top --pid <引擎PID> # 观察热点线程
nvidia-smi -q > /tmp/gpu-state.txt # 同时留一份设备状态
dmesg -T | tail -50 # 查内核层是否有报错卡点对照
| 卡在哪 | 观察点 | 处置方向 |
|---|---|---|
| 多机通信 | 栈停在通信原语，各进程进度不一致 | 核对网络与超时配置，必要时按预案整体重启 |
| 显存分配 | 栈停在分配调用，显存水位已满 | 降低并发或缩短窗口，再评估扩容 |
| GPU 调用 | 内核日志里有设备错误记录 | 保全证据后按维护流程重启进程 |
| 抓不到栈 | 进程状态特殊或工具被拦截 | 先留日志与设备状态再做决定 |
先分清慢与挂：观察一分钟的水位与吞吐曲线，缓慢推进和完全不动，处置方式差得很远。
挂起类故障复现成本高，抓栈前不要急着重启：调用栈与内核日志往往是仅有的线索。