把 compute_ms 拆成排队与纯计算，据此否掉换机器这个方向

compute_ms 一直是「提交进程池到拿到结果」的墙钟时间，排队和纯计算混在一个数里，所以「加核有没有用」只能靠猜——这也是原先打算在 AWS 开第二台比 CPU 的依据。 worker 内部自己计时，连同父进程传入的提交时刻一起回传，拆出 queue_ms 与 inner_ms。实测中位 3ms / 695ms：2 个 worker 跑 3 个币并不排队，因为三个币的收盘消息错峰到达。瓶颈全在单线程，加核压不到。顺带把 README 里的内存数据从臆测的 1.5GB 改成实测 410MiB，并注明跨站点比 CPU 收益有限。 Co-authored-by: Cursor <cursoragent@cursor.com>
2026-08-28 03:02:06 +08:00
parent 95f2b614a2
commit 54792fe015
3 changed files with 73 additions and 10 deletions
@@ -117,10 +117,33 @@ python research/live/compare_sites.py \
 同理，`lag_data_ms` 两站也应当几乎相同（网络那段只有 2ms 空间）。真正该出现
 差异的是 `compute_ms`。如果 `lag_data_ms` 差很多，先查时钟——比查网络更可能。

+⚠ 但先读下面「资源占用」一节：`compute_ms` 的差异几乎全部来自单核性能，而
+现役机型之间单核差距很小。**跨站点比 CPU 这件事本身收益有限**，本节流程保留
+是为了比网络与时钟，不建议为了比 CPU 单独开机器。
+
 ## 资源占用

-本机实测：内存约 1.5GB（两个计算进程 + 盘口缓冲），CPU 单核不满。
-盘口与成交流落盘约 15MB/天（gzip）。一周 168 小时的量级在百 MB 内。
+本机实测（2 vCPU EPYC 9K65 / 3 个币 / 2 worker）：内存 **410MiB**，CPU 均值
+1~3%。盘口与成交流落盘约 15MB/天（gzip），一周在百 MB 内。

-`--workers 2` 是因为信号计算走独立进程池、不能阻塞事件循环。核数少的机型
-可以给 1，但要看心跳里的 `compute_ms`：若接近 60 秒就会开始堆积。
+内存和平均 CPU 都不是约束。约束是**单根 K 线的计算延迟**，而它是纯单线程的：
+
+```
+compute_ms  中位 764ms   父进程测的墙钟，含排队
+  queue_ms  中位   3ms   等空闲 worker
+  inner_ms  中位 695ms   进程内真正在算
+```
+
+`queue_ms` 只有 3ms，说明 **2 个 worker 跑 3 个币并不排队**——三个币的收盘消息
+错峰到达（SOL 最晚，排 66ms），没有真正的并发争抢。
+
+**这条结论直接否掉了「换更强机器」这个方向。** 加核只能压 queue_ms，而它已经
+是 3ms；695ms 全在单线程里，取决于单核性能。t3a.medium（Zen 1，2017）单核比
+本机 Zen 5 慢 1.8~2 倍，换过去 compute_ms 会涨到 1200ms 以上。c7a / c6a 这类
+现代机型单核与本机相当，也换不到东西。
+
+要压这 695ms 只有算法一条路：现在每分钟把 2001 根从头算一遍，其中 2000 根的
+结构与上一分钟完全相同。
+
+`--workers 2` 是因为信号计算走独立进程池、不能阻塞事件循环。币数超过 worker
+数才会看到 queue_ms 上来；届时加 worker 有效，加到与币数相等即可。