274 lines
7.0 KiB
Markdown
274 lines
7.0 KiB
Markdown
# 当前线上最终 Runbook
|
||
|
||
最后更新：2026-04-26 18:12 左右
|
||
适用节点：`mainland-controller-01`
|
||
|
||
这份文档的目标很简单：
|
||
后面不再靠聊天记录回忆，也不在多份文档里来回翻。
|
||
只看这一份，就知道：
|
||
|
||
1. 当前线上到底跑在什么基线上
|
||
2. 现在先看什么数
|
||
3. 什么情况继续观察
|
||
4. 什么情况才值得继续动刀
|
||
|
||
## 1. 当前结论
|
||
|
||
当前这套线上方案，已经从：
|
||
|
||
- 线程忙但不出结果
|
||
|
||
推进到了：
|
||
|
||
- 线程忙，同时持续产出 `completed`
|
||
|
||
所以现在的正确策略不是继续乱改参数，而是：
|
||
|
||
**先稳住，先观察，确认这套已经验证有效的配置能不能持续出结果。**
|
||
|
||
## 2. 当前线上基线
|
||
|
||
### 当前基底版本
|
||
|
||
- `current` 指向：
|
||
`/opt/domaincheck/releases/domaincheck_release_20260424_220158`
|
||
|
||
说明：
|
||
|
||
- 当前不是纯旧 release 原样运行
|
||
- 真实线上状态是：
|
||
`220158 基底 + 多轮已热补代码 + 已生效 env`
|
||
|
||
### 当前服务状态
|
||
|
||
- `domaincheck-worker.service = active`
|
||
- `domaincheck-sync-agent.service = active`
|
||
- `domaincheck-api.service = active`
|
||
|
||
## 3. 当前已确认生效的关键参数
|
||
|
||
这些参数是**已经在运行进程环境里确认过**的，不是只改了文件。
|
||
|
||
### 单机性能与爱站相关
|
||
|
||
- `DOMAINCHECK_REGISTER_SINGLE_MACHINE_MODE=1`
|
||
- `DOMAINCHECK_SINGLE_MACHINE_AIZHAN_DIRECT_FIRST=1`
|
||
- `DOMAINCHECK_AIZHAN_REMOTE_DISCONNECT_DEGRADE=1`
|
||
- `DOMAINCHECK_AIZHAN_EXTERNAL_FAST_DEGRADE=1`
|
||
- `DOMAINCHECK_PROXY_STEP_MAX_ATTEMPTS_AIZHAN=2`
|
||
- `DOMAINCHECK_PROXY_STEP_MAX_SECONDS_AIZHAN=10`
|
||
- `DOMAINCHECK_AIZHAN_TIMEOUT_PROXY=1.8`
|
||
- `DOMAINCHECK_AIZHAN_TIMEOUT_DIRECT=2.4`
|
||
|
||
### Wayback 相关
|
||
|
||
- `DOMAINCHECK_PROXY_STEP_MAX_ATTEMPTS_WAYBACK=2`
|
||
- `DOMAINCHECK_PROXY_STEP_MAX_SECONDS_WAYBACK=8`
|
||
- `WAYBACK_CDX_TIMEOUT=3`
|
||
- `WAYBACK_SNAPSHOT_TIMEOUT=2`
|
||
- `WAYBACK_RETRY_COUNT=1`
|
||
- `WAYBACK_DOMAIN_CONCURRENCY=1`
|
||
- `WAYBACK_MAX_RECORDS=2`
|
||
- `WAYBACK_TRANSIENT_BACKOFF_SECONDS=0.5`
|
||
|
||
## 4. 当前已确认上线的代码方向
|
||
|
||
### 调度 / 分发侧
|
||
|
||
- 预补货提前触发
|
||
- 预补货时不再让补货 worker 先独吞下一批
|
||
- `pipeline` 推进和主动 `pull_tasks` 做了共享锁
|
||
- `session_replaced -> queued_before_start` 这条重复唤起链已压住
|
||
- `claim / finalize / release` 这些本地 DB 重链已经做过减重
|
||
|
||
### 外部步骤侧
|
||
|
||
- 注册检测保留单机性能模式
|
||
- 百度、360、爱站都不再是早期那套过于激进的超时口径
|
||
- `爱站` 当前已经具备：
|
||
- 首轮可直连优先
|
||
- `RemoteDisconnected` 可直接降级
|
||
- 外部依赖异常可快速降级继续
|
||
- `wayback` 当前已经具备：
|
||
- `latest_cdx` transient 时不再硬打额外 `records_cdx`
|
||
- backoff 已收短
|
||
- 主要剩下 `web.archive.org` 本身慢/拒绝连接
|
||
|
||
## 5. 当前已经验证出来的效果
|
||
|
||
### 5.1 机器已经真正吃起来
|
||
|
||
已观察到：
|
||
|
||
- `60` 个节点全在线
|
||
- 多次快照里 `51 ~ 56` 个 worker 有真实线程
|
||
- 真实线程和长期在 `3.8 万 ~ 4.2 万`
|
||
|
||
所以当前不是“进程活着但没干活”，而是确实在跑。
|
||
|
||
### 5.2 内存高位问题先被压下来
|
||
|
||
滚动重启释放旧 RSS 后，现场出现过一轮明显回落：
|
||
|
||
- `Mem used ≈ 31Gi`
|
||
- `available ≈ 93Gi`
|
||
- `60` 个 worker 总 RSS ≈ `23.9Gi`
|
||
|
||
说明“旧 RSS 不退”这层已经先被压住。
|
||
|
||
### 5.3 当前真正最重要的验证结果
|
||
|
||
观察窗：`2026-04-25 17:17:18` 到 `17:29:23`
|
||
|
||
- `completed_total: 50786 -> 51298`，净增 `512`
|
||
- `aizhan_completed: 7718 -> 7936`，净增 `218`
|
||
- `wayback_completed: 3068 -> 3362`，净增 `294`
|
||
- 这段窗口里：
|
||
- `aizhan_failed = 0`
|
||
- `wayback_failed = 0`
|
||
|
||
这说明：
|
||
|
||
- 现在已经不是“压住 failed，但 completed 不动”
|
||
- 而是“failed 被压住，同时 completed 持续增长”
|
||
|
||
## 6. 当前最该看的数
|
||
|
||
后面观察时，优先级固定按这个顺序：
|
||
|
||
1. `completed_total`
|
||
2. `aizhan_completed`
|
||
3. `wayback_completed`
|
||
4. `aizhan_failed`
|
||
5. `wayback_failed`
|
||
6. `running / claimed / pending`
|
||
|
||
顺序不要反过来。
|
||
|
||
原因：
|
||
|
||
- `claimed / pending` 在 `domain_pipeline` 下天然会波动
|
||
- `completed` 才是最真实的产出
|
||
|
||
## 7. 当前正确的判断方法
|
||
|
||
### 7.1 什么叫“继续观察就行”
|
||
|
||
只要看到下面这种趋势，就先不要再改：
|
||
|
||
- `completed_total` 持续增长
|
||
- `aizhan_completed` 持续增长
|
||
- `wayback_completed` 持续增长
|
||
- `aizhan_failed / wayback_failed` 维持低位或归零
|
||
|
||
这说明：
|
||
|
||
- 当前主链是通的
|
||
- 当前配置方向是对的
|
||
- 现在最应该做的是稳住，不是继续乱调
|
||
|
||
### 7.2 什么叫“又卡住了”
|
||
|
||
只有出现下面这些情况，才值得继续下刀：
|
||
|
||
#### 情况一
|
||
|
||
`completed_total` 在 `30 ~ 60` 分钟窗口里基本不动
|
||
|
||
说明：
|
||
|
||
- 虽然线程在跑
|
||
- 但结果没有真正落地
|
||
|
||
#### 情况二
|
||
|
||
`aizhan_failed` 或 `wayback_failed` 又明显抬头
|
||
|
||
说明：
|
||
|
||
- 当前“快速降级继续”的策略还不够稳
|
||
|
||
#### 情况三
|
||
|
||
`running` 长时间很高，但 `aizhan_completed / wayback_completed` 不再增长
|
||
|
||
说明：
|
||
|
||
- 新的主瓶颈又出现了
|
||
|
||
## 8. 当前建议观察窗口
|
||
|
||
建议至少继续看 `30 ~ 60` 分钟。
|
||
|
||
正确做法：
|
||
|
||
1. 记录一组起始值
|
||
2. 每隔 `10 ~ 15` 分钟看一次
|
||
3. 至少看 `3 ~ 4` 个点
|
||
|
||
不要只看一两个瞬间。
|
||
|
||
## 9. 当前先不要再碰的东西
|
||
|
||
在这轮观察结束前，先不要继续改：
|
||
|
||
- worker 进程数
|
||
- 每进程线程数
|
||
- claim 批量
|
||
- backlog 批量
|
||
- 爱站超时
|
||
- wayback 超时
|
||
- 其他步骤的重试窗口
|
||
|
||
原因很简单：
|
||
|
||
- 现在已经进入“开始稳定产出”的阶段
|
||
- 再频繁改参数，只会把已经验证有效的窗口打碎
|
||
|
||
## 10. 当前一句话执行原则
|
||
|
||
**先稳住，先看 `completed` 能不能持续增长；只要结果还在持续出来，就先不要再乱改。**
|
||
|
||
## 11. `job 876` 尾项释放的当前判断
|
||
|
||
观察时间：`2026-04-26 18:12` 左右
|
||
|
||
当前不是“又卡死了”，而是：
|
||
|
||
- `idx_detect_job_items_release_node_job` 还没转成 `valid=1`
|
||
- 但它已经稳定进入 `index validation: scanning table`
|
||
- 最新验证进度已经到 `229991 / 6197384`
|
||
|
||
`codex-job876-tail-watch.service` 这条后台链当前是活的，而且在连续记进度：
|
||
|
||
- `18:09:51 -> 126725`
|
||
- `18:10:52 -> 169564`
|
||
- `18:11:52 -> 210067`
|
||
- `18:12:22 -> 227856`
|
||
|
||
同时现场另外两组状态也正常：
|
||
|
||
- `job 876 = running`
|
||
- worker 已恢复到：
|
||
- `base=active`
|
||
- `templated=199`
|
||
- `node_agent=active`
|
||
|
||
这次现场更准确的判断应该是：
|
||
|
||
- 已经从“卡住”切成“后台验证扫描中”
|
||
- 当前最合理的动作不是再人工乱动
|
||
- 应该继续让索引自己扫完
|
||
|
||
一旦 `idx_detect_job_items_release_node_job` 转成 `valid=1`，`codex-job876-tail-watch.service` 就会自动继续释放 `876` 的尾项。
|
||
|
||
## 12. 如果后面还要继续优化，下一刀顺序
|
||
|
||
只有在更长观察窗口里确认又卡住时，才按这个顺序继续：
|
||
|
||
1. 先看 `completed_total` 为什么不涨
|
||
2. 再看 `aizhan_completed / wayback_completed` 哪个先停
|
||
3. 再决定是继续打外部链，还是回头查回写 / 聚合语义
|
||
|
||
不要一上来就回去改线程、claim、并发。
|