2026-05-08 学习日志

知识点

• [K8s/GPU] qGPU Checkpoint 僵尸分配导致调度失败 → 详见 topics/k8s/gpu/
• [前端/Next.js] socket.io 默认会 destroy 非自己 path 的 upgrade 请求，搞死 Next HMR → 详见 topics/frontend/next/
• [项目/DRMS] dev 环境 HMR 连接失败的根因排查 → 详见 topics/projects/drms/

问题与解决

qGPU 整卡 Pod 一直 Pending

• 问题: GPU 整卡工作负载 Pod 一直 Pending，nvidia-smi 显示 GPU 物理空闲
• 原因: kubelet device-plugin 的 checkpoint 文件残留已删除 Pod 的分配记录
• 解决: 重启 kubelet 清理僵尸 checkpoint（systemctl restart kubelet）

Next.js dev HMR WebSocket 持续失败、页面自动刷新

• 问题: 浏览器 Console 不停刷 ws://localhost:3009/_next/hmr failed，页面隔几秒自动刷新
• 误判: 先怀疑是 ZeroOmega 代理拦截 localhost WebSocket，配 bypass、切直连都没用
• 真因: 项目自定义 server.js 里 new Server(server) 初始化 socket.io，默认 destroyUpgrade: true 把非 /socket.io/ 的 upgrade 请求全部 socket.end() 掉，Next 的 /_next/hmr 跟着遭殃
• 解决: new Server(server, { destroyUpgrade: false })

今日总结

两个看似不相关的故障，本质都是「底层默认行为静默吃掉了上层依赖」：

• qGPU 故障是 kubelet checkpoint 默认会持久化分配状态，Pod 删了不会自动清理
• HMR 故障是 socket.io 默认会强制断开它不认识的 upgrade 请求

排查思路一致：先排除外部干扰（代理/网络），再用底层工具（lsof/源码阅读）定位到协议层，最后看默认配置项。 另外，当 HMR 不工作时，全页刷新会销毁 Worker 状态，这种环境下做性能测试得到的数据全是错的，必须先保证 dev 环境干净再去测业务逻辑。