# 测试优化分析

> 说明：这份文档保留作历史分析记录。当前线上执行基线与观察方法，统一以 [当前线上最终Runbook.md](/www/wwwroot/getDomain/docs/当前线上最终Runbook.md) 为准。

更新时间：`2026-04-24 14:00`

## 这份文档是干什么的

这份文档不是讲理想情况，而是把这次已经做过的单机压测结果，和当前现场“根本没真正跑起来”的现状，放在一起说清楚。

目的很直接：

- 先把已经验证过的参数结论留档
- 再把现在为什么看起来线程上限很高、实际只跑了很少线程说清楚
- 给后面继续优化的人一个明确顺序，别再一边主链没跑通，一边继续盲目加并发

## 一句话结论

早上那轮“只测一台大陆机器”的压测，已经得出过一个单机最优值：

- `mainland-controller-01` 单机跑时，当前最优参数是 `35 进程 / 900 线程`

但这不等于项目现在已经能按这个参数稳定跑。

按 `2026-04-24 13:22` 左右控制面看到的实时状态，这套链路目前更像是：

- 任务还挂着
- 页面也还能显示“运行中”
- 但真正参与执行的只有很少几个桶
- 总体上属于“没有真正跑起来”

所以现在的主矛盾不是“继续把线程调大”，而是“先让主流程真的跑起来”。

## 这次单机压测是怎么测的

这轮压测不是全链路压测，而是一个故意收缩后的测试环境。

当时做了这几件事：

- 先停掉 `121.204.244.248`，也就是 `mainland-worker-01`
- 只保留 `mainland-controller-01` 单机承担检测
- 停掉 controller 上的 `domaincheck-sync-agent.service`
- 不再继续额外增加新的 Redis 限制动作
- 直接在 controller 本地数据库里看 60 秒窗口真实完成量和更新量

这么做的目的，不是模拟线上真实规模，而是先排除多机互相干扰，看单机能跑到什么水平。

## 单机压测结果

压测时间段大致是 `2026-04-24 05:14 - 05:28`。

当时 controller 本地 60 秒窗口结果如下：

| 参数 | 60 秒完成量 | 60 秒更新量 | Redis 连接数 | 内存已用 | 可用内存 | 实际活跃 worker |
| --- | ---: | ---: | ---: | ---: | ---: | ---: |
| `35/900` | `4092` | `22267` | `751` | `73.6G` | `54.3G` | `35` |
| `40/1000` | `1885` | `1544` | `793` | `75.1G` | `52.9G` | `40` |
| `45/1100` | `388` | `11347` | `818` | `75.7G` | `52.3G` | `45` |
| `50/1200` | `0` | `12118` | `823` | `75.9G` | `52.1G` | `45` |

## 压测结论

从这轮结果里，可以直接得出 4 个结论：

### 1. 单机最优值不是越大越好

当前这套链路下，`35/900` 明显优于后面的更大参数。

也就是说，继续加进程、加线程，并没有带来更高完成量，反而更差。

### 2. 当前单机稳定上限大约在 `45/1100`

`45/1100` 还能勉强活住。

但它已经不是“跑得更快”，只是“还能挂着不死”。

### 3. `50/1200` 已经没有意义

虽然当时把参数抬到了 `50/1200`，但最终实际只活成了 `45` 个 worker，而且完成量已经掉到 `0`。

这说明不是配置没写进去，而是链路已经先撞到别的瓶颈了。

### 4. 当时真正的瓶颈已经不是 Redis

从这轮压测看，Redis 连接数有上升，但没有先爆。

更像是外部检测链路本身先撑不住了，尤其是：

- 注册检测
- 代理池质量
- 会话切换抖动

## 为什么当时测出来 `35/900`，现在页面却只剩 `52` 线程

这就是最容易误判的地方。

早上压测结论成立的前提是：

- 只测 controller 单机
- `mainland-worker-01` 被停掉
- `sync-agent` 被停掉
- 现场是专门为压测收缩过的

而现在你看到的实时状态，已经不是那个压测场景了。

按 `2026-04-24 13:22` 左右接口返回的状态，现在的现场是：

- `detect/job/active` 里的活动任务还是 `job_id=1`
- 这条任务从 `2026-04-21 23:30:42` 就已经是 `running`
- `raw_items_pending=9478`
- `raw_items_running=1`
- `raw_items_completed=4996`
- `raw_items_failed=486`

同时，`runtime/status` 给出的聚合状态是：

- `参与服务器：4`
- `参与进程：4`
- `参与线程：52`
- `运行中：52`
- `线程上限：52 / 2701`

这几组数字合起来说明的不是“系统已经高效跑起来”，而是：

- 页面还能看到一些参与桶
- 但真正持续工作的执行面很薄
- 大量任务还躺在队列里，没有被健康地持续消化

## 当前为什么可以直接判断“根本跑不起来”

不是因为页面数字小，而是因为几条关键事实同时出现了：

### 1. 活动任务太老

当前活动任务还是 `2026-04-21` 开出来的老任务。

如果主链真的健康，它不应该拖这么久还挂在 `running`。

### 2. 待处理量还很大

当前还剩：

- `9478` 条原始 pending
- `3779` 条 claimed
- `1028` 条 running backlog

但真正展示出来的活跃线程只有 `52`。

这个比例说明队列不是空了，而是消化不动。

### 3. 当前节点自己根本不跑本机 worker

当前 `overseas-control-01` 的 `runtime/status` 里明确写着：

- `worker_online=false`
- `worker_process_count=0`
- `worker_runtime_message=inactive/dead`

也就是说，现在这个页面看到的“运行中”，本来就不是本机在跑，而是靠远端汇总。

### 4. 远端参与桶很少，而且口径不稳

现在控制面聚合出的参与节点只有：

- `mainland-worker-01`
- `mainland-controller-01-k`
- `mainland-controller-01-a`
- `mainland-controller-01-s`

这和早上单机压测时的 `35` 个 worker，根本不是一个级别。

所以你现在看到“线程上限 2701”，不要被这个数字迷惑。

它只是汇总上限，不代表这些线程真的都在跑。

## 现在最像什么问题

如果用人话说，现在最像下面这种情况：

- 任务队列里还有很多活
- 但是执行面只剩很薄一层还在动
- 页面还能看到“运行中”，所以看起来像没完全死
- 可真正吞吐已经低到接近“没跑起来”

所以这不是单纯的参数问题，而是主流程状态已经歪了。

## 当前最该先做的事

下一步优化顺序建议固定成这样：

### 第 1 步：先恢复“能持续跑”

先不要继续加进程、加线程。

先确认 4 件事：

- 当前到底是哪几个节点真的在跑
- `mainland-worker-01` 是不是还应该继续停着
- controller 上当前实际活着多少 worker
- 老任务里这些 `claimed/running` 有没有大量卡死项

### 第 2 步：把老任务和会话问题理顺

现在这条 `2026-04-21` 的老任务已经拖太久了。

要优先确认：

- 是不是有很多旧 `session_replaced`
- 是不是有大量任务项一直卡在 `claimed/running`
- 是不是页面显示还在跑，但实际 worker 已经不工作了

### 第 3 步：确认代理链是不是主瓶颈

早上单机压测已经说明，Redis 不是先撞墙的那个点。

下一步更值得盯的是：

- `detect_register` 的真实完成率
- 代理池是否经常空
- RDAP 访问是否大量超时

### 第 4 步：只有主链恢复后，才重新做性能优化

## 13:48 补充结论

这轮又确认了一件非常关键的事：

- `mainland-worker-01` 不是“已经彻底消失”，而是“被标记为停用，但之前还在继续上报运行态”

后来实际做了两步处理：

- 先通过远端 `ops job` 让 `mainland-worker-01` 本机执行 `systemctl stop domaincheck-worker`
- 再把控制面的状态汇总改成：只要节点在 `ops_managed_nodes` 里是 `is_enabled=false`，就不再算进在线 Worker、参与节点和活跃线程

处理完成后，控制面实时口径已经从“2 台参与节点 / 2 个检测进程 / 2 线程”收到了：

- `参与节点：1`
- `参与进程：1`
- `运行中：1`
- 只剩 `mainland-controller-01`

这说明前面那种“明明已经准备单机测了，页面还一直把停用节点算进去”的问题，确实是状态口径 bug，不是现场真的还有两台健康执行机一起在跑。

所以从现在开始再看单机测试结果时，要以这条新口径为准：

- `mainland-worker-01` 已停用，不再参与单机压测统计
- 当前有效执行面只剩 `mainland-controller-01`

等主流程恢复成“真的能持续吃队列”之后，再拿 `35/900` 作为第一版基线。

到那时可以按下面顺序再调：

1. 先验证 `35/900` 在恢复后的现场还能不能稳定
2. 如果稳定，再测 `40/1000`
3. 只有吞吐确实提高了，才继续往上加

## 这份文档的最终结论

可以把这次结果浓缩成两句话：

第一句：

- 单机压测已经证明，当前代码和链路下，`mainland-controller-01` 的最佳参数是 `35 进程 / 900 线程`

第二句：

- 但当前线上真正的问题不是“参数不够大”，而是“主流程根本没有持续跑起来”，所以现在继续加线程没有意义

后面再优化时，应该先解决“为什么只剩 52 线程在动”，再谈如何把吞吐重新抬高。

## 2026-04-24 13:35 补充结论

这份文档写完以后，又继续往下排了一轮，现场有两个非常关键的新结论。

### 1. `52` 线程里有明显口径错配

后来继续核对后发现，页面里那组：

- `参与服务器：4`
- `参与进程：4`
- `参与线程：52`

并不是来自 `detect_job_items` 真表本身。

真实数据库里，`job_id=1` 其实只剩：

- `1` 条 `running`

而且这条记录最后更新时间还停在 `2026-04-22 15:00:56`，本质上已经是老僵死项。

真正把页面抬到 `52` 的，是一条口径 bug：

- 当前 active job 还是老任务 `detect-20260421232649-acfa3d`
- 但控制面又拿到了别的 sync job 的 runtime overlay
- 两套数据被硬合到了一起

简单说就是：

- 任务表是老 job
- 线程数却借用了别的 job 的运行态

### 2. 这条口径 bug 已经修掉了

现在代码已经补成：

- 只有 runtime overlay 的 `job_code / job_id` 和当前 active job 对得上时，才允许覆盖 `queue_health`
- 对不上时，宁可退回真实任务表，也不再把别的 job 的运行态硬套到当前页面上

修完并重启海外控制面 API 之后，实时口径已经从之前的 `52` 收回到了：

- `参与节点：2`
- `参与进程：2`
- `参与线程：2`

当前这 `2` 个真实信号分别来自：

- `mainland-controller-01` 那条老 `running`
- `mainland-worker-01` 当前 heartbeat 上报的 `1` 条活跃线程

这说明一件事：

- 之前那组 `52` 的确主要是错口径，不是实际吞吐

## 目前还剩的真实问题

虽然 `52 -> 2` 这一步已经收准了，但项目还是没有真正恢复健康。

当前还剩 2 个真实问题：

### 1. `mainland-worker-01` 明明已停用，却还在持续推运行态

当前控制面日志里还能持续看到：

- `121.204.244.248` 往海外控制面打 `runtime/debug-ingest`
- 同时也还在打 `ops/agent/pull`

这说明这台机器不是“旧残影”，而是还真的在线、还真的在报活。

所以“已停用”这件事，目前只是在托管配置层停了，但没有真正把它从 Agent / runtime 上报链里摘干净。

### 2. `job_id=1` 这条老任务本身也还没收口

当前老任务依然挂着：

- `job_id=1`
- `job_code=detect-20260421232649-acfa3d`
- `started_at=2026-04-21 23:30:42`

而真实任务表里，它现在已经不是“很多线程在跑”，而是：

- 大部分还在 `pending`
- 只剩 1 条老 `running`

这说明这条老任务本身也需要后续专门处理，不能继续长期挂在 `running`。

## 现在更准确的下一步

到这里为止，下一步就更明确了：

1. 先把 `mainland-worker-01` 真的摘掉。
2. 再处理 `job_id=1` 这条老任务的遗留 `running` 项。
3. 等这两件事收完，再重新看当前真实执行面到底还有没有持续吞吐。

也就是说，现在已经不是“继续猜线程参数”的阶段，而是“先把错误执行面和老任务残留清掉”的阶段。

## 新增一版“单机性能模式”给注册检测

这次为了后面继续压单机吞吐，我已经在代码里补了一版只影响“注册状态检测”的性能模式。

它的目标不是改全局架构，而是先把当前最像瓶颈的那一段链缩短：

- 只改 `detect_register`
- 不碰百度、360、站长、爱站、时光机这些步骤
- 保留当前版的连接复用和失败闭环
- 只把注册检测改得更像老版本那种“先尽快打出去，再说”

### 这版模式做了什么

打开后，注册检测会变成下面这个思路：

- 即使全局 `allow_direct=false`，注册检测这一步也允许直连
- 默认先连续直连 `2` 次
- 这两次之间不再等代理补货
- 只有前面的直连没打通，后面才继续走代理兜底

简单说就是：

- 当前默认模式：代理优先，直连兜底
- 单机性能模式：注册检测直连优先，代理兜底

### 怎么开

这版先做成环境变量开关：

- `DOMAINCHECK_REGISTER_SINGLE_MACHINE_MODE=1`
- `DOMAINCHECK_REGISTER_DIRECT_STREAK_ATTEMPTS=2`

当前默认建议先用这组：

- `进程：35`
- `线程：900`
- `DOMAINCHECK_REGISTER_SINGLE_MACHINE_MODE=1`
- `DOMAINCHECK_REGISTER_DIRECT_STREAK_ATTEMPTS=2`

如果后面继续试更激进一点，再考虑把直连连打次数从 `2` 提到 `3`，但不建议一上来就抬。

### 为什么不是直接回退老版本

老版本真正有参考价值的是“链短、切得快”，不是它的实现本身更先进。

所以这次没有回退这几样东西：

- 没回退到 `20s * 3` 的长超时
- 没回退到“注册失败也继续往后跑”
- 没丢掉当前的 `Session` 复用

换句话说，这次是“借老策略”，不是“退老实现”。