getDomain/docs/测试优化分析.md

测试优化分析

说明：这份文档保留作历史分析记录。当前线上执行基线与观察方法，统一以 当前线上最终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 复用

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