👷 RAG / Review Worker 体检单（内存盘 3 图）

💡 一句话理解

backend 之外还有两个「独立小弟」：rag（RAG 检索，要解析用户上传的大文件）和 review（审阅服务）。它们各自是单进程、各顶 2G 内存限额、各有自己的 DB / Redis 借书证。体检单看三样：体温计（RSS：rag 处理 LibreOffice 大文件时冲高属预期——关键看之后回不回落；冲高不回落+逼近 2G 限额 = 下一个 OOM 受害者，rag 有前科）、借书证使用率和借出数绝对值（review 是独立小池 5+5，特别容易被慢任务借空）。

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

先认清这两个小弟是谁。backend 是四 worker 的大店，rag 和 review 是两间独立小作坊：各只有一个进程、各分到 2G 的「房间面积」（容器限额）。因为单进程，它们的体检单没有 per-worker 多线——一个服务一条线，跟 backend 那种「四条线一起看」的画面完全不同。指标前缀也不同：siliang_worker_*，job 是 siliang-rag / siliang-review，别拿 backend 的面板来找它们。

rag 的体检重点是「冲高看回落」。它的工作就是用 LibreOffice 解析用户上传的大文档——解析期间内存必然冲高，这不是病，是干活的样子。干完活回落 = 健康（锯齿）。要警惕的是另一种形态：冲上去之后横住不回落，并且一步一步逼近 2G 限额线——这不是「正在干活」，这是「干完的活没收拾」。rag 是有前科的：它历史上就因为 LibreOffice 大文件被 OOM 杀过。OOM 不打招呼：working_set 顶到限额，内核直接 SIGKILL，日志空白，现场只剩「重启 + 5xx + 用户掉线」三联。所以「冲高不回落 + 贴限额」必须在被枪毙之前发现——这正是这张体检单存在的意义。

review 的体检重点是「小池借空」。它不像 backend 有 sync 30 / async 80 的大书架，只有一个独立小池 5+5（常备 5 + overflow 5）。小池的脾气是：平时够用，但慢任务一多——几条查询抱着连接不还——很快借空，后面所有请求排队，审阅接口集体变慢。看它就用和 backend 一样的两张卡（使用率 + 绝对值），只是脑子里要换算：这里的天花板是 5，不是 80。

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

两个独立小弟

rag（RAG 检索）与 review（审阅服务）是独立于 backend 的单进程服务，各自 2G 容器限额。单进程=每服务一条线，没有 per-worker 多线。

# 身份证（主图谱口径）
job=~"siliang-rag|siliang-review"   # 两个小弟的 job
# 限额：rag 2G · review 2G（容器层口径，OOM 判定看 working_set）

rag 的冲高属预期

LibreOffice 解析大文件必然吃内存——冲高是干活的样子，不是病。判定只看一件事：干完之后回不回落。

# 判定口径（面板原话）
# 冲高 → 回落 = 预期，锯齿健康
# 冲高 → 不回落 + 逼近 2G = 下一个 OOM 受害者（rag 有前科）

2G 限额与 OOM 前科

容器限额 rag 2G / review 2G；顶到限额内核直接 SIGKILL（memcg OOM），不打招呼不留遗言。rag 历史上被 LibreOffice 大文件打爆过。

# 现场三联（OOM 后只剩这些）
# 容器重启 + 一波 5xx + 用户掉线；日志空白，别指望遗言

deriv 量化爬升

「在爬」要变成数字才好告警：deriv(rss[1h]) 算斜率=每小时涨多少字节。这是内存盘核心告警口径之一。

# 核心告警（口径卡）
deriv(siliang_worker_process_resident_memory_bytes{job="siliang-rag"}[1h]) > 5MB/h
# → 持续爬升；[1h] 窗口抹掉抓取抖动

review 独立小池 5+5

review 不用 backend 的大书架，自己一本小借书证：常备 5 + overflow 5。慢任务一占就是五分之一，几条就借空。

# 池天花板对照（别背混）
# backend: sync 30 / async 80 / checkpointer 30
# biz:      10 + overflow 20 = 30
# review:   5 + 5                # ← 特别容易被慢任务借空

指标前缀 siliang_worker_*

两个小弟的池/RSS 指标都带 worker 前缀，与 backend 的 siliang_db_pool_*、siliang_process_* 是两套。找错前缀=图上永远没数据。

# 前缀对照
siliang_worker_process_resident_memory_bytes   # 小弟 RSS
siliang_worker_db_pool_connections             # 小弟 DB 池
siliang_worker_redis_pool_connections          # 小弟 Redis 池

池和内存互为因果

池被借空→请求排队→排队请求占着的内存迟迟不释放→RSS 冲高逗留更久。体检单三张要连着看。

# 互证顺序
# 接口慢 → 池借空（m129/m130）→ RSS 冲高逗留（m128）→ 回源：慢任务是谁

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

# 主图谱口径：两个小弟的 RSS（1 分钟抹抖，job 正则圈住两家）
max_over_time(siliang_worker_process_resident_memory_bytes{job=~"siliang-rag|siliang-review"}[1m])

# 主图谱口径：DB 池 + Redis 池使用率（前缀 siliang_worker_*）
siliang_worker_db_pool_connections{state="checked_out"} / siliang_worker_db_pool_capacity
  + siliang_worker_redis_pool_connections / siliang_worker_redis_pool_capacity

# 主图谱口径：借出数 + 上限参考线（含 review 独立池 5+5）
siliang_worker_db_pool_connections / siliang_worker_db_pool_capacity
  + siliang_worker_redis_pool_connections / siliang_worker_redis_pool_capacity

🏭 生产实战 real world

# 第 1 步：看形态——冲高之后回不回落？
max_over_time(siliang_worker_process_resident_memory_bytes{job="siliang-rag"}[1m])
# → 回落成锯齿 = 干活；横住不回落 = 嫌疑

# 第 2 步：量化斜率——是真在爬还是在抖？
deriv(siliang_worker_process_resident_memory_bytes{job="siliang-rag"}[1h])
# → > 5MB/h 持续 = 真爬升（核心告警口径）；正负跳变 = 抖动

# 第 3 步：对照限额——还有几个台阶到 2G？
# 贴 2G = OOM 倒计时（rag 有前科），立刻处理卡住的大文件任务

# 一级：爬升速度（核心告警口径 deriv > 5MB/h）
- alert: RagMemoryClimbing
  expr: deriv(siliang_worker_process_resident_memory_bytes{job="siliang-rag"}[1h]) > 5 * 1024 * 1024
  labels: {severity: warning}    # 在爬：定位卡住的大文件任务

# 二级：绝对水位逼近 2G 限额（示例阈值 85%，按限额换算）
- alert: RagMemoryNearLimit
  expr: max(siliang_worker_process_resident_memory_bytes{job="siliang-rag"})
        > 0.85 * 2 * 1024 * 1024 * 1024
  labels: {severity: critical}   # 贴限额 = OOM 倒计时（rag 有前科）

# 借出绝对值：天花板 5，几条慢任务就能顶平
siliang_worker_db_pool_connections{state="checked_out",job="siliang-review"}

# 使用率互证：贴 100% = 借空排队
siliang_worker_db_pool_connections{state="checked_out",job="siliang-review"}
  / siliang_worker_db_pool_capacity{job="siliang-review"}

# 找病根：慢任务常见来源是锁窗口（1205=等太久，1213=死锁）
sum(rate(siliang_db_lock_errors_total[5m])) by (operation, code)

# 冲高时刻的伴读图：文件/媒体处理的典型体重（P95）
histogram_quantile(0.95,
  sum by (le) (rate(siliang_file_batch_archive_bytes_bucket[5m])))
# → 大文件在冲高窗口内被解析：冲高有了出处

# 结局对照：这批活干成了还是反复失败重试（重试=反复占内存）
sum by (outcome) (rate(siliang_file_batch_archive_outcome_total[5m]))
# → exception 高 = 反复重试反复占内存，RSS 不回落的重要原因

# 每个小弟的抓取目标都应是 1（up 是 Prometheus 通用指标）
up{job=~"siliang-rag|siliang-review"}
# → 0 = 该服务的 /metrics 没被抓到：进程挂了或抓取配置断了

# 复活后 RSS 应从低位重新开始（重启后内存归零再增长）
max_over_time(siliang_worker_process_resident_memory_bytes{job=~"siliang-rag|siliang-review"}[1m])

⚠️ 常见坑 pitfalls

# 错: rss > 1G 即报            # 大文件一来就误报
# 对: deriv(rss[1h]) > 5MB/h 持续 + 不回落   # 抓真爬升

# 错: siliang_db_pool_connections{job="siliang-rag"}      # 前缀就错了
# 对: siliang_worker_db_pool_connections{job=~"siliang-rag|siliang-review"}

# 错: "rag 图只有一条线，是不是少抓了 worker"
# 对: 单进程=一条线；数错了去查抓取配置

# 错: review 借出 > 60 才报          # 天花板才 5，永远不报
# 对: review 使用率 = 借出/5，贴 100% 即借空

# 错: RSS 高 → 直接查大对象
# 对: 先看池是否借空排队 → 再查大对象/慢任务

# 错: "到 95% 再处理"           # 内核不陪你等
# 对: 逼近 2G 限额 = 立即处置 + 复盘大文件来源

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

🔗 相关课程