# 当前已验证有效的线上参数与改动清单

> 说明：这份文档保留作阶段留档。后续执行和观察，统一以 [当前线上最终Runbook.md](/www/wwwroot/getDomain/docs/当前线上最终Runbook.md) 为准。

最后更新：2026-04-25 17:30 左右  
适用节点：`mainland-controller-01`  
目标：给后续观察和继续优化留一个“当前已经验证有效”的固定基线，不再靠聊天记录回忆。

## 1. 当前线上基底

- 当前 `current` 指向：
  `/opt/domaincheck/releases/domaincheck_release_20260424_220158`
- 当前核心服务状态：
  - `domaincheck-worker.service = active`
  - `domaincheck-sync-agent.service = active`
  - `domaincheck-api.service = active`

说明：
- 这台机器现在不是只跑旧 release 原样代码，而是“`220158` 基底 + 多轮热补”。
- 后续如果要正式固化，应该把当前热补内容重新打一版正式 release。

## 2. 当前已确认生效的远端环境参数

以下参数已经在运行中的 `detect_worker.py` 进程环境里确认过，不是只改了文件没重启：

### 单机性能/爱站相关

- `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`

## 3. 当前已确认上线的代码改动方向

这些不是“计划中”，而是已经热补到 `mainland-controller-01` 并跑起来的：

### 调度/分发侧

- 预补货提前触发，不再等批次快空了才补。
- 预补货时不让拿到锁的那个 worker 先独吞下一批任务。
- `pipeline` 推进和主动 `pull_tasks` 做了共享锁，减少 60 个 worker 同时拆批次。
- `session_replaced -> queued_before_start` 这条重复唤起链已经加护栏压住。
- `claim / finalize / release` 这些本地 DB 重链做过多轮减重，分钟级长尾已经明显掉下来。

### 注册/站点检测侧

- 注册检测保留单机性能模式。
- 百度、360、爱站都已经不再停留在过于激进的超时口径。
- `爱站` 已经补到：
  - 单机模式下首轮可直连优先
  - `RemoteDisconnected` 可直接降级
  - 现在又进一步支持“外部依赖异常快速降级”，不再把整轮预算白白耗完

### Wayback 侧

- `wayback` 已经从“自己 backoff 把自己打死”收住。
- 当前远端新版逻辑里：
  - `latest_cdx` transient 时，不再硬打额外的 `records_cdx`
  - backoff 已收短到 `0.5s`
  - 当前剩下主要是 `web.archive.org` 本身慢/拒绝连接

## 4. 这轮真正验证出来的效果

下面这些是已经实测到的，不是预估：

### 4.1 机器确实吃起来了

较早一轮稳定快照里，`mainland-controller-01` 已经出现：

- `60` 个节点全在线
- `53` 个子 worker 的 `active_threads > 0`
- `active_thread_count = 13531`

后续观察里，最近 2 分钟也长期能看到：

- `59` 个 fresh worker
- 大约 `51 ~ 56` 个 worker 有真实线程数大于 `0`
- 真实线程总和大约在 `3.8 万 ~ 4.2 万`

这说明当前不是“进程活着但没吃活”，而是确实在跑。

### 4.2 内存高位问题先被压下来了

滚动重启并替换旧 RSS 后，现场有过一轮明显回落：

- `Mem used ≈ 31Gi`
- `available ≈ 93Gi`
- `60` 个 worker 总 RSS 约 `23.9Gi`

说明“旧 RSS 不退”这层已经不是最早那种危险状态。

### 4.3 爱站与 Wayback 的尾部外部链，已经从“卡住不产出”变成“持续产出”

观察窗：`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 也在持续增长”

### 4.4 爱站快速降级这刀确实有作用

更早一段观察里，`爱站 failed` 还是会堆。  
在把 `DOMAINCHECK_AIZHAN_EXTERNAL_FAST_DEGRADE=1` 灰到远端后，后面的观察窗里：

- `aizhan_failed` 被压到 `0`
- `aizhan_completed` 持续增长

这说明当前主链里，对爱站这类外部依赖异常，“快速降级继续”是有效的。

## 5. 当前怎么理解这些数字

当前最应该盯的不是：

- 单次 `claimed`
- 单次 `pending`
- 某一个瞬间的 `running`

因为这是 `domain_pipeline`，前一步跑完会继续生成下一步，数字天然会波动。

当前更应该盯的是：

1. `completed_total` 是否持续增长  
2. `aizhan_completed / wayback_completed` 是否持续增长  
3. `aizhan_failed / wayback_failed` 是否继续维持低位  

如果这三组数继续保持当前趋势，就说明这套配置是对的。

## 6. 当前不要再乱动的东西

在下一轮更长观察结束前，建议先不要再继续频繁改：

- worker 进程数
- 每进程线程上限
- claim / backlog 批量参数
- wayback / 爱站超时参数

原因很简单：  
现在已经进入“参数开始生效、completed 在涨”的阶段，再频繁动，会把已验证有效的窗口打碎。

## 7. 下一步建议

当前建议先停手观察，不再继续大改参数。

优先做两件事：

1. 继续观察更长窗口  
   建议至少再看 `30 ~ 60` 分钟，确认：
   - `completed_total` 继续增长
   - `aizhan_completed / wayback_completed` 继续增长
   - `aizhan_failed / wayback_failed` 不重新抬头

2. 之后再做正式固化  
   把当前这些热补过的代码和远端有效参数，整理进正式 release，避免后续机器重启或重新发版时丢失。

## 8. 当前一句话结论

**这轮已经验证到：当前 `mainland-controller-01` 上这套“单机性能模式 + 外部依赖快速降级继续”的组合是有效的，主链已经从“线程忙但不出结果”切到“线程忙，同时持续产出 completed”。**