getDomain/docs/当前已验证有效的线上参数与改动清单.md

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

说明：这份文档保留作阶段留档。后续执行和观察，统一以 当前线上最终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”。