GPU 机硬挂首次崩溃取证报告

取证时间：2026-09-28 10:49（机器 10:47 重启后由监督脚本自动抓取）原始现场：崩溃取证/recovery_20260928_104833.txt（41 KB）意义：这是这台机器 6 次硬挂以来第一次拿到崩溃现场——此前所有记录都写着「没有崩溃捕获能力」

一、结论先说

找到了高度可疑且可操作的元凶：宿主机内存压力（kernel-level memory pressure）+ 缺失 --disable-pinned-memory。

这不是"随机玄学"，是有日志证据的：

上一次启动的内核日志里出现 4 次内核级内存压力告警：

Sep 28 03:51:14 zywpc systemd-journald[1182]: Under memory pressure, flushing caches.
Sep 28 03:52:50 zywpc systemd-journald[1182]: Under memory pressure, flushing caches.
Sep 28 04:19:31 zywpc systemd-journald[480]:  Under memory pressure, flushing caches.
Sep 28 04:56:30 zywpc systemd-journald[1182]: Under memory pressure, flushing caches.

日志在 05:04:39 戛然而止 —— 没有 panic、没有 Xid、没有 GSP 报错、没有 OOM-killer、没有正常关机记录。 「日志直接断掉」= 内核冻结（hard freeze），与「整机硬挂」的现象完全吻合。
最后一次内存压力告警（04:56:30）之后 8 分钟机器就冻死了。
关键是：当时那个 ComfyUI 实例的启动参数里没有 --disable-pinned-memory —— 而这正是 2026-09-15 取证报告查出的病因：ComfyUI 默认会 pin 住按公式算出来的 ≈27.1 GiB「不可换页」宿主内存，而本机只有 30 GiB 物理内存。

二、现场数据

2.1 机器基本盘

项	值
物理内存	30 GiB
Swap	71 GiB（`/swap.img` 8G + `/swap2.img` 64G），但使用 0 B
GPU	RTX 5060 Ti 16 GB，驱动 610.43.02
内核	6.8.0-142-generic
`kernel.panic`	10
`kernel.panic_on_oops`	0
`kernel.hung_task_panic`	1
`kernel.hung_task_timeout_secs`	300

⚠️ 注意：hung_task_panic=1 + 300s 本应让内核在任务挂起 5 分钟后 panic 并 10 秒后自动重启，但它没有触发（日志里没有 panic 记录，也没有自动重启）—— 说明冻结得太彻底，连 hung_task 检测器都没能跑起来。这解释了为什么"必须人工断电"。

2.2 启动记录（journald 是持久化的）

-4  ...  Fri 2026-09-25 18:57:47 → Sun 2026-09-27 03:32:30
-3  ...  Sun 2026-09-27 03:35:35 → Sun 2026-09-27 20:35:32
-2  ...  Sun 2026-09-27 20:38:51 → Mon 2026-09-28 02:26:57   ← 第一次硬挂（02:26）
-1  ...  Mon 2026-09-28 02:52:05 → Mon 2026-09-28 05:04:39   ← 第二次硬挂（05:04）
 0  ...  Mon 2026-09-28 10:47:42 → （当前）

这推翻了运维记录里"没有崩溃捕获能力"的旧结论 —— journald 有持久化存储（/var/log/journal 存在，journalctl --list-boots 可列出 5 个历史启动），以前只是没人在恢复后第一时间去读。现在监督脚本会自动读。

注意 -2 段的结束时间 02:26:57 —— 但机器重启是 02:52:05。也就是 02:26:57 冻死 → 直到 02:52:05 才重启（中间 25 分钟无人处理）。这与我观察到的时间线吻合：我 02:50 发现不可达，报告后你断电重启，02:52 起来。

2.3 内存压力时间点与生成任务的对应关系

内存压力告警	当时在做什么
03:51:14	镜01（Pass2 采样中，03:49 提交）
03:52:50	镜01
04:19:31	镜01 刚出片（04:17）、镜02 刚提交（04:18）
04:56:30	镜03（04:50 提交）
05:04:39	镜03 生成中 → 整机冻死

每一次内存压力告警都落在生成任务的时间窗内，不是巧合。

2.4 其它发现：Docker 的 snapshotter 告警（已核实，影响有限）

⚠️ 更正：本节初版写成「Docker 在反复解包/拉取镜像」，这个描述不准确。复核后确认：comfyui_persist 容器7 周前就已 Exited(127)，镜像 nvcr.io/nvidia/pytorch:25.12-py3 是早已存在的本地镜像；那些告警是 Docker 29.3.0 的 containerd-snapshotter 集成计算镜像体积失败时报的 warning（Canceled: context canceled）， 不是网络拉取、也不持续占用内存。当前启动(0)里共 18 条，绝大多数集中在 dockerd 启动那几秒。保留在此仅为如实记录，它不太可能是硬挂主因。

原始告警样貌：

03:34:54 dockerd: failed to calculate snapshot usage ... "Canceled: context canceled"
03:52:45 dockerd: 同上
03:56:21 dockerd: 同上
04:26:37 dockerd: 同上
04:43:49 dockerd: 同上
04:56:29 dockerd: 同上

当前在跑的容器：

homepage                ghcr.m.daocloud.io/gethomepage/homepage:latest   Up
mumuainovel             mumujie/mumuainovel:latest                       Up
mumuainovel-postgres    postgres:16-alpine                               Up
open-web-search         ghcr.io/aas-ee/open-web-search:latest           Created
comfyui_persist         nvcr.io/nvidia/pytorch:25.12-py3                 Exited (127)

结论：这是 Docker daemon 的健康噪音，不是内存压力源。在 30 GiB 机器上跑 H3 时它不会带来实质负担，无需处理。

（真正需要盯的是 3.1 的 --disable-pinned-memory —— 已修复，且重启后内存压力告警计数为 0。）

三、修复与缓解

3.1 已生效（监督脚本里）

ComfyUI 现已以此参数启动，已实测进程命令行确认：

main.py --listen 0.0.0.0 --port 8189 --lowvram --force-fp16 --reserve-vram 1.0
        --fast-disk --cache-lru 2
        --disable-pinned-memory        ← 关键！去掉那 ≈27 GiB 的不可换页池
        --preview-method none

对比：本次两次硬挂时用的命令没有 --disable-pinned-memory（我照抄了 09-25 监督脚本以外的旧命令）。这是本次排查最重要的操作性发现。

3.2 建议的进一步缓解（需要你决定，我没有擅自做）

#	措施	效果	风险
1	生成期间停掉非必要 Docker 容器（`homepage`、`mumuainovel`、`mumuainovel-postgres`）	直接释放内存，且消除镜像解包抖动	会让这三个服务短暂不可用
2	~~查清谁在反复拉 PyTorch 镜像~~	已核实无需处理（见 2.4 更正）	—
3	给 ComfyUI 加 RAM 哨兵（`ram_guard.sh`，09-25 已有）	内存越线时主动干预	需确认脚本存在于 GPU 机
4	降载（Pass2 步数 8→6、分辨率 768P→640P）	缩短单镜满载窗口	画质略降

我倾向先只做 3.1（已做）+ 观察一轮：既然 --disable-pinned-memory 正是 09-15 查出的病因，而本次两次硬挂都缺这个参数，很可能补上之后就能稳定跑完。如果补上后仍挂，再上 3.2 的 1/2/4。

四、与历史结论的关系

运维记录 2026-09-25 曾下结论「该机在 H3 长时满载下会随机整机硬挂，与配置/软件路径无关」。本次取证部分修正了这个结论：

该结论成立的前提是「已按 09-15 修复配好参数」。但在本次两次硬挂中，--disable-pinned-memory 是缺的，所以这两次不能用来支持"与配置无关"。
现在有直接证据（4 次内核内存压力告警 + 日志冻结式终止）指向内存压力，这与 09-15 的 pinned-memory 结论一致，而非"随机硬件故障"。
若补上参数后仍复现，才应回到"硬件层面"（此时应重点看 3.2 的第 2 项：Docker 抖动，以及考虑换更大内存/关掉 swap 之外的干扰）。

五、监督脚本本次的实际表现（全自动，无需人工）

10:47  机器重启恢复
10:48  监督脚本第 324 轮探活成功
10:48  自动触发 capture_after_recovery.sh（本报告的数据来源）
10:49  取证落盘（41 KB）
10:49  发现 ComfyUI 未就绪 → 自动拉起（带 --disable-pinned-memory）
10:53  ComfyUI 就绪（200）
10:53  自动开始断点续跑，扫到 S01/S02 已存在 → 跳过
10:53  提交 S03（上次被打断的那一镜）→ 采样中（GPU 14.3GB / 98%）

从机器恢复到继续出片，全程 6 分钟，零人工干预。

六、产物位置

内容	路径
本报告	`dl-hub/06-ComfyUI-H3运维记录/崩溃取证/2026-09-28-首次崩溃取证报告.md`
原始现场	`dl-hub/06-ComfyUI-H3运维记录/崩溃取证/recovery_20260928_104833.txt`
取证脚本	`~/.tools/capture_after_recovery.sh`
监督脚本	`~/.tools/mv_aicg3d_supervisor.sh`

⚠️ 重要修正（2026-09-28 11:50 补录）

一、`--disable-pinned-memory` 没能阻止第三次硬挂

本报告第三节把「内存压力 + 缺失 --disable-pinned-memory」当作元凶并断言 "很可能补上之后就能稳定跑完"。这个结论下得太早，已被证伪。

第三次硬挂事实：

项	值
时间	2026-09-28 约 11:33（第 3 次硬挂）
当时在跑	镜03（用新的单人正面参考图重跑）
ComfyUI 参数	已含 `--disable-pinned-memory`（进程命令行已核实）
本启动内存压力告警计数	0（`journalctl -b 0 \| grep -c "memory pressure"` = 0）
距该批次开始	仅约 3 分钟

→ 在内存压力为 0、修复参数已生效的情况下依然硬挂，说明内存压力不是（唯一）病因。

二、第三次硬挂的形态与"长时满载"假设不符

此前 09-25 记录与本次前两次都表现为"跑了一段时间后挂"。但第三次：

批次 11:29:56 开始 → 11:33 左右失联，只有约 3 分钟
这 3 分钟正好是 模型加载阶段（日志里模型加载约需 2~3 分钟，Model Initializing ...）
09-25 记录的死亡位置也是 "S03 的 Model Initializing ..."，同样是加载阶段

新假设：崩溃与「大模型反复加载/卸载」的内存与 IO 尖峰有关，而不是"跑久了才挂"。

这条假设有一个可疑的诱因：第三次硬挂前，我中断了 S04 并清空了 ComfyUI 队列 （因为要用新参考图重跑）。该操作会让已驻留的 20GB UNET + 15GB 文本编码器被释放，紧接着新批次又要重新加载它们 → 一次剧烈的内存/IO 尖峰。 这可能是我自己制造的触发条件。

三、修正后的处置原则

#	原则	原因
1	不要再随意中断/清空 ComfyUI 队列	会强制大模型重新加载，制造内存/IO 尖峰
2	保持 `--disable-pinned-memory`（继续保留）	即便不是唯一病因，它消除了 27GB 不可换页池，没有坏处
3	参考图等改动必须在批次间隙做，不要在采样中途打断	同 1
4	下次恢复后先取证（监督脚本已自动做），重点看死前最后动作是否在模型加载	验证新假设
5	若确认是加载尖峰：考虑把 H3 模型常驻（不卸载）、或改用更小的模型档	降低尖峰

四、对用户的影响

第 3 次硬挂同样需要人工断电重启。监督脚本已在守护，恢复后会自动取证+拉起+续跑。

当前进度仍为 2/45（S01、S02 有效；S03 用新参考图重跑时被这次硬挂打断，仍需重跑）。

五、诚实说明

我在上一轮把"内存压力"当成了确定结论并向用户断言"很可能补上就能稳定跑完"， 这是过早的结论。本机 6 次硬挂的原因目前仍未确认；内存压力是本启动里唯一抓到的内核级异常，但它显然不足以解释全部。后续每轮恢复都会自动取证，累积样本后再下结论。

2026-09-28-首次崩溃取证报告.md