📏 字节分布：大对象的典型体重（内存盘 3 图）

💡 一句话理解

快递站每收一件包裹都要过秤，秤不记每一件的重量，只往一叠"累积水桶"里记账：不超过 1MB 的几件、不超过 10MB 的几件……P95 就是把所有包裹从轻到重排队，站在 95% 位置那件的体重——它代表"典型的大件有多重"。m109 / m110 / m123 就是 backend 的三张体重秤：文件/媒体一类、图像/整包一类、XAI 生图响应一类。

它解决一个具体问题：RSS 冲高时，说明内存里突然多了几百 MB，但不知道是谁搬进来的。拿冲高时刻来对时间戳——哪类东西的体量足够解释这次冲高，搬运工就是谁。顺带记住一个天然事实：b64_json 格式把图片塞进 JSON 文本，天生比 URL 形态大 33%+。

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

先懂秤的原理。延迟、体积这类"每次都不一样"的数，系统不存单值，存的是一叠累积水桶（bucket，每个桶带个上限标签 le）：不超过 1MB 的有几件、不超过 10MB 的有几件……查询时用 histogram_quantile 从桶里插值算出分位数。所以面板名字里都有 _bytes_bucket 和 "p95"——P95 回答的不是"最重的那件多重"，而是"典型的大件有多重"，比最大值稳得多（最大值会被一个极端件带跑）。

再看三张秤各称什么。m109 称文件/媒体三类活：ZIP 打包的产物、视频转存的文件、TTS 合成的音频。它就是"RSS 为什么冲高"的答案：要处理一个 200MB 的视频，程序必须先把它读进内存——内存必然先涨 200MB+，这不是泄漏，是搬运的物理代价。m110 称五类图像资产：快照源图、分割图层、skill 整包、provider 生图返回、Seedance 参考图。m123 单独称 xAI 的生图响应，并且 P50/P95 两条线对照——P50 是典型件，P95 是大件，两条线的距离就是"件与件的差距"。

最后是把秤变成破案工具。上一课的在途线回答"谁在搬"，本课的分布回答"搬的典型多大"——两个时间戳一对：RSS 冲高时刻 × 在途跳起的工 × 该工的典型体重，三者量级对得上，案子就结了。还有一个高阶用法：分布本身"突然变大"（比如 provider 生图 p95 翻倍），那不是流量问题，是上游变更——先怀疑它换了默认分辨率或返回格式（b64_json 就天然比 URL 大 33%+）。

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

直方图 = 水桶

体积/延迟不存单值，存一叠累积桶（bucket），桶的上限标签叫 le；分位数从桶里插值算出。

# 指标名长这样：_bytes_bucket，带 le 标签
siliang_xai_image_response_bytes_bucket{le="1000000"}

P95 读法

把所有件从轻到重排队，P95 = 95% 的件比它轻——"典型大件"的代表，比最大值稳定。

# m123 口径：p95 / p50 双线对照
histogram_quantile(0.95, sum(rate(siliang_xai_image_response_bytes_bucket[5m])) by (le))

by (le) 第一大坑

histogram_quantile 忘了 by (le)，所有桶混成一锅，算出来的分位数是废的——这是直方图查询第一大坑。

# 错：没有 by (le)；对：必须 by (le)（+业务维度）
… sum(rate(…_bytes_bucket[5m])) by (le)

b64 天然大 33%+

b64_json 把图片塞进 JSON 文本（base64 编码），天然比 URL 形态大 33%+——这是格式代价，不是 bug；但膨胀会直接放大内存峰值。

# m123 用法：判断响应是否异常膨胀
# p95 阶跃 ≈ 格式切换（URL → b64_json）或分辨率变大

搬运的物理代价

处理 200MB 的视频，内存必然先涨 200MB+——RSS 冲高不一定是泄漏，先看体重秤再定罪。

# 冲高量级 × 典型体重 对得上 = 正常搬运
# 对不上且在途滞留 → 才升级成泄漏排查

分布突变 = 上游变更

provider 生图 p95 突然变大，先怀疑上游换了默认分辨率/返回格式——体重是上游给的，不是我们养出来的。

# 与昨天对比（offset 是通用 PromQL）
… bytes_bucket[5m] offset 1d  # 昨天的同期体重

p50 与 p95 的距离

p50 是典型件、p95 是大件；两线距离突然拉大 = 出现了一批异常大的件。

# m123 双读数（照抄主图谱口径）
histogram_quantile(0.95/0.50, sum(rate(
  siliang_xai_image_response_bytes_bucket[5m])))

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

# 面板 PromQL（主图谱口径：三类 bucket 各算一条 p95）
histogram_quantile(0.95, sum(rate(
  siliang_file_batch_archive_bytes_bucket[5m])) by (le))
# 同款：…_video_transfer_bytes_bucket / …_tts_audio_bytes_bucket

# 面板 PromQL（主图谱口径：五类 bucket 并列，此处举两类）
histogram_quantile(0.95, sum(rate(
  siliang_snapshot_compose_source_bytes_bucket[5m])) by (le))
# 同款：_image_segmentation_layer / _openapi_skill_package /
#       _provider_image_response / _seedance_reference_bytes_bucket

# 面板 PromQL（照抄主图谱口径：p95 / p50 双读数）
histogram_quantile(0.95/0.50,
  sum(rate(siliang_xai_image_response_bytes_bucket[5m])))

🏭 生产实战 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 步：查搬运工的典型体重（m109 口径）
histogram_quantile(0.95, sum(rate(siliang_video_transfer_bytes_bucket[5m])) by (le))
# 定案：冲高量级 ≈ 在途工的 P95 体重 = 正常搬运；对不上 = 泄漏排查

# 今天的 provider 生图 p95（m110 口径）
histogram_quantile(0.95, sum(rate(
  siliang_provider_image_response_bytes_bucket[5m])) by (le))
# 昨天同期（offset 是通用 PromQL）
histogram_quantile(0.95, sum(rate(
  siliang_provider_image_response_bytes_bucket[5m])) by (le) offset 1d)
# 判读：阶跃式上涨（如翻倍）= 上游换默认分辨率/格式 → 找供应商确认
# 连带检查：安检门拦截速率是否同步抬头（m114 口径）

# p95 与 p50 双读数（m123 口径）
histogram_quantile(0.95, sum(rate(siliang_xai_image_response_bytes_bucket[5m])) by (le))
histogram_quantile(0.50, sum(rate(siliang_xai_image_response_bytes_bucket[5m])) by (le))
# 读法：
#   p50 与 p95 同步阶跃 ≈ +33% → 格式切到 b64_json（格式代价，计入基线）
#   p50 平稳、只有 p95 阶跃 → 出现一批大件（分辨率变化），单独查

# 通用模板：histogram_quantile + rate + sum by (le)
histogram_quantile(<分位数>,
  sum(rate(<…_bytes_bucket>[5m])) by (le, <业务维度>))
# 实例：Seedance 参考图 p95（m110 五类之一）
histogram_quantile(0.95,
  sum(rate(siliang_seedance_reference_bytes_bucket[5m])) by (le))
# 自查：结果数量 = le 桶数才对；只有一条线 = 忘了 by (le)

# 三张秤的周巡检（拉 7d 窗口看趋势）
histogram_quantile(0.95, sum(rate(siliang_file_batch_archive_bytes_bucket[5m])) by (le))
histogram_quantile(0.95, sum(rate(siliang_tts_audio_bytes_bucket[5m])) by (le))
histogram_quantile(0.95, sum(rate(siliang_xai_image_response_bytes_bucket[5m])) by (le))
# 关注：台阶式抬升（上游变更）/ 缓慢爬升（数据量自然增长）
# 台阶 = 记变更单；爬升 = 评估内存峰值预算

⚠️ 常见坑 pitfalls

# 错: histogram_quantile(0.95, sum(rate(…_bucket[5m])))
# 对: histogram_quantile(0.95, sum(rate(…_bucket[5m])) by (le))

# 错: 用 p95 估算内存峰值上限
# 对: 峰值预算用 p99/最大值；p95 看典型与趋势

# 错: b64 比 URL 大 → 报 bug
# 对: 大 33%+ = b64 格式天然代价；阶跃才立案

# 错: 只看当前 p95 绝对值
# 对: …bucket[5m] offset 1d  # → 和昨天同期比

# 错: histogram_quantile(0.95, sum(…_bucket) by (le))
# 对: histogram_quantile(0.95, sum(rate(…_bucket[5m])) by (le))

# 错: p95 够大 → 冲高合理，结案
# 对: 在途同时跳起且事后归零 → 才算正常搬运

# 错: siliang_tts_audio_bytes[5m]
# 对: siliang_tts_audio_bytes_bucket[5m]

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

🔗 相关课程