📦 大对象在途：谁攥着大文件（内存盘 2 图）

💡 一句话理解

把 backend 想成一家搬运公司：ZIP 打包、快照合成、skill 整包、图片分割、画布裁剪是五个搬运工，每人干活时都要抱着一口大箱子（大块内存）。健康的标准简单粗暴——「稳态应归零」：活干完，箱子放回仓库，台账上"正在搬运"的计数回落到 0。

这两个面板就是搬运台账：m106 盯文件/打包三个工，m107 盯图像处理两个工。哪条线忙完不归零，哪个工就攥着箱子不撒手——这就是 RSS 抬升的直接嫌疑人。而且箱子比看上去重得多：一张几 MB 的 PNG，解码后在内存里要占几十 MB。

🧩 费曼拆解 讲给完全没接触过的小白

先认识五个搬运工。有人下单"帮我把整个画布打包成 ZIP"——打包工接过活，把几百张图装进一个巨型袋子（内存里的字节数组），压好、传走、放袋下班。快照工、整包工、分割工、裁剪工同理：接活 → 抱箱子 → 干完 → 放下。所以它们的"在途计数"（active）天然就该是锯齿：忙时往上跳几格，闲时稳稳归零。「稳态应归零」不是要求，是这类活的物理本性——箱子没有理由一直抱着。

再看箱子有多重。磁盘上的 PNG 是压缩过的，几 MB；程序要处理它，必须先"解码"摊开成原始像素——一张几 MB 的 PNG 摊开后能占几十 MB 内存，放大 10 倍不止。所以图像工（m107）抱的箱子格外沉：只要有一个裁剪活挂着不结束，几十 MB 就一直扣在 worker 头上；几个同时挂着，RSS 立刻冲高一截。

最后是排查姿势。内存冲高了怎么办？别翻代码猜——拿 m101 的 RSS 冲高时刻，来 m106/m107 对时间戳：某个工的在途线在同一时刻跳起来、然后一直没归零？嫌疑人就是他。在途回答"谁在搬"，下一课的字节分布回答"搬的多大"，两图一夹，凶手现形。

🧠 必知必会 看懂本课全部面板的地基

active 是温度计

在途计数可上可下，是 Gauge：读数=手里有几个活。直接读，别配 rate。

# m106 口径：三条线各画一条（主图谱以 / 简写并列）
max_over_time(siliang_file_batch_archive_active[1m])
max_over_time(siliang_snapshot_compose_active[1m])
max_over_time(siliang_openapi_skill_package_active[1m])

稳态应归零

这组面板的健康定义就四个字：闲时读数应回 0。不归零不是"忙"，是"没释放"。

# 滞留判据（通用 PromQL）：30 分钟内始终 > 0
min_over_time(siliang_file_batch_archive_active[30m]) > 0

解码放大

磁盘体积 ≠ 内存体积：PNG/JPEG 是压缩格式，解码摊开成原始像素后暴涨，几 MB 文件占几十 MB 内存。

# 估算口诀：内存 ≈ 宽 × 高 × 4 字节（RGBA）
# 4000×3000 的图 ≈ 48MB —— 与磁盘上几 MB 完全两码事

时间戳方法论

RSS 冲高时刻 × 在途跳起时刻，两个时间戳一对，嫌疑人现形——监控版"调监控录像"。

# 同一 Grafana 时间轴上叠三张图：
# m101（RSS 冲高）× m106/m107（谁跳起）× m109/m110（箱子多重）

分线看，别求和

五个工各归各的零：求和会把"一个工滞留"稀释成"平均略微偏高"，线索全无。

# 错：sum 五条线；对：分线各自归零各自看
max_over_time(siliang_image_segmentation_active[1m])

在途 vs 字节分布

在途（本课）回答"谁在搬"；字节分布 p95（下一课 m109/m110/m123）回答"搬的典型多大"。

# 一问在途，二问体重，三对 RSS——三连击
histogram_quantile(0.95, …)  # 下一课的主角

在途归零 ≠ RSS 立降

活干完、箱子放下后 RSS 可能停在高位走平台——那是 allocator 不归还（常态），别误判成滞留。

# 分流判据：
# 在途=0 且 deriv(RSS[1h])≈0  → 平台期，常态
# 在途>0 且 RSS 抬升          → 滞留实锤

📋 逐面板精讲 2 张图一张不落

# 面板 PromQL（照抄主图谱口径：三线并列）
max_over_time(siliang_file_batch_archive_active[1m])
max_over_time(siliang_snapshot_compose_active[1m])
max_over_time(siliang_openapi_skill_package_active[1m])

# 面板 PromQL（照抄主图谱口径：两线并列）
max_over_time(siliang_image_segmentation_active[1m])
max_over_time(siliang_workspace_crop_active[1m])

🏭 生产实战 real world

# 第 1 步：锁定冲高时刻（m101 口径）
max_over_time(siliang_process_resident_memory_bytes{job="siliang_backend_worker"}[1m])
# 第 2 步：同一时间轴叠上在途（m106/m107 口径）——谁在那一刻跳起？
max_over_time(siliang_file_batch_archive_active[1m])
max_over_time(siliang_image_segmentation_active[1m])
# 第 3 步：翻字节分布确认箱子多重（m110 口径，下一课详解）
histogram_quantile(0.95, sum(rate(siliang_snapshot_compose_source_bytes_bucket[5m])) by (le))
# 判读：冲高时刻 × 在途跳起 × 箱子体量 = 闭环证据链

# 告警规则：大对象滞留（稳态应归零面板通用写法）
groups:
- name: siliang-bigobject-retention
  rules:
  - alert: BigObjectStuckInFlight
    expr: min_over_time(siliang_file_batch_archive_active{job="siliang_backend_worker"}[30m]) > 0
    for: 0m          # min_over_time 已含"持续 30 分钟"语义，不用再 for
    labels:
      severity: warning
  # 同款复制给 snapshot_compose / skill_package / segmentation / crop
  # 注意：深夜低峰触发可信度最高；白天要结合业务量排除"真在忙"

# 拉 24h 看完整业务周期（m107 口径）
max_over_time(siliang_workspace_crop_active[1m])
# 对照请求量确认"忙时"（有活干 >0 是正常的）
sum(rate(siliang_http_requests_total[5m]))
# 基线结论应长这样：忙时 1~几个在途，闲时归 0，全天锯齿
# 偏离基线的两种坏形态：闲时不归零（滞留）/ 忙时冲到异常高的并发

# 在途几个活（m107 口径）
max_over_time(siliang_image_segmentation_active[1m])
# 源图典型体量（m110 口径：快照源图 p95）
histogram_quantile(0.95, sum(rate(siliang_snapshot_compose_source_bytes_bucket[5m])) by (le))
# 心算：p95 若 5MB（压缩态），解码后 ≈ 数十 MB/张；在途 3 个 = 上百 MB 被攥着
# 与 RSS 冲高量级一对照：对得上 = 定案

⚠️ 常见坑 pitfalls

# 错: alert: archive_active > 0
# 对: alert: min_over_time(archive_active[30m]) > 0

# 错: sum(archive_active, compose_active, …)
# 对: 五条线并列，谁不归零谁是嫌疑人

# 错: 3MB 文件 → 内存占用 ≈ 3MB
# 对: 4000×3000 × 4B ≈ 48MB，几 MB PNG 解码后占几十 MB

# 错: active=0 且 RSS 高 → 泄漏
# 对: active=0 + deriv(RSS[1h])≈0 → 平台期，常态

# 错: rate(siliang_workspace_crop_active[5m])
# 对: sum by (outcome) (rate(siliang_workspace_crop_outcome_total[5m]))

# 错: 只查 file_batch / snapshot / skill_package
# 对: 加上 image_segmentation / workspace_crop 再结案

🎓 费曼自测 合上书，能讲出来才算懂

🔗 相关课程