ci: 刷新计时表并把 linux 分片上限抬到 4 —— 3 片已经装不下了 - #189
Merged
Merged
Conversation
`linux default 0/3` 在 run 31266814148 被 90 分钟上限砍掉,成员全绿,死在
cache/artifact 的 post 步骤。查下来既不是冷缓存也不是 runner 争抢,是工作量
真的超了,而**陈旧的计时表把这件事盖住了**。
## 计时表漏了两个重家伙
`tests/member-timings.tsv` 停在 62 行 linux,而 workspace 已经有 67 个成员。
`plan_shards` 对表里没有的成员按**中位数**计价,于是:
mysql-connector-cpp 实测 881s 被当成 ~60s
libmysqlclient 实测 329s 被当成 ~60s
两个加起来 20 分钟的工作量,被当轻的塞进了已经扛着 grpc-codegen 的 shard 0。
这两个数是从 run 31266814148 的 `linux default 0/3` 步骤耗时里量的 —— 那一片
正好被砍,timings artifact 从没上传,而它们又正是导致溢出的成员。这个先有鸡还
是先有蛋只能手工破一次。表的其余部分来自 run 31260545520 的 member-timings
artifact(顺带补上 cli11 / cmdline / llmapi,并修正 curl 26→264s、
eui-neo-sdl2 119→591s)。
## 刷完表才看清:3 片本来就不够
刷新后 linux 总量 15891s = 265 分钟。按当前表模拟最慢分片:
3 片 98 分 ← 超 90 分钟 job 上限
4 片 74 分
5 片 60 分
`shards_for` 的公式 `secs / 4200 + 1` 对这个总量算出来就是 4,一直被
`cap 3` 压回 3。所以这不是新问题被引入,是旧上限被工作量长过去了 —— 旧表让
总量看起来只有 13570s,刚好还压得住。
## 上限 3 -> 4
旧注释给这个上限的理由是"linux 实测并发 3,第 4 片会排队"。这个前提已经两头
失效:工作量长大了,而且自 #184 起 linux 每轮发 2 x N 个 job,任何 N 都会排队。
排队是对的取舍 —— 背靠背跑完的分片仍然完成,超过上限的分片不会。
代价:linux 每轮 8 个 job(原 6),模拟确认 `.shards` 读作 4、四片覆盖 67/67。
同时把那段容量注释改成现在为真的样子,并写明"表要保持新鲜"不是打扫卫生:
一个没计时的成员按中位数打包,一个重的新成员就会像轻的一样被塞进任何地方。
tests/member-timings.tsv 在 select 的 case 里一条都不匹配 —— 不是 tests/*.sh, 不是 tests/examples/*,不是 pkgs/*.lua,也不在忽略清单里 —— 于是落进 `*) full "unclassified change"`。 这张表决定活儿怎么在分片间分配,从不决定构建什么:没有任何成员的结果会因为 一个实测数字变了而改变。让它触发全量,是这份 workflow 里"花最大代价测试零 东西"的做法,而下一次真正的全量运行本来就会读到新数字。 代价写在注释里了:这样一来这个文件对 CI 不可见,坏行是静默的,而 plan_shards 对解析不了的东西按中位数计价 —— 正是刚刚撑爆一个分片的那个失效 模式。真要咬到就在 lint 里加校验。
这张表之前列出每个成员,于是每加一个测试它就过期一次 —— 而这次撑爆分片的
正是"表里没有的成员按中位数计价":mysql-connector-cpp 实测 881s,被当成 60s。
但打包决策其实只由重的那几个做出。linux 上 top10 占总量的 69%,其余 57 个平
均 86s、中位 24s。把它们从表里拿掉,最慢分片一分钟都不动:
完整表 67 行,4 片 74 / 64 / 63 / 63 最慢 74 分
top10 表,4 片 74 / 73 / 60 / 58 最慢 74 分
## 兜底价必须是固定常数,不能再取中位数
直接缩表会当场炸:表里只剩 10 个重的,中位数就变成"第 5 重的那个",在 linux
上是 875s,于是 57 个小成员每个都按 875s 计价 ——
top10 表 + 中位数兜底 90 / 48 / 81 / 46 最慢 90 分 ← 正好撞 job 上限
改成固定 90s(未计时成员的实测均值 86s 取整)。这个值不吃调参:兜底价从 30s
到 300s,最慢分片始终在 72–84 分之间,全都在 90 以下。这种不敏感正是"表可以
长期不动"的依据。
## shards_for 也得跟着改,否则片数会掉回去
它原本直接把表里的行加起来当工作量。表一缩,linux 总量从 15891s 读成 10965s
→ 3 片,而 3 片在这张表下最慢 107 分,直接超时。
给 plan_shards 加一个 `<platform> 0 0` 模式返回总量,shards_for 改调它。这样
"有哪些成员"和"未计时的算多少钱"只有一份定义,而不是 yaml 和 lua 各一份等着
漂移。估算精度:linux 16095s vs 实测 15891s,+1.3%。macOS / windows 的成员比
默认价便宜,总量偏高 —— 两者本来就顶着 cap 2,而且偏多分片是安全方向。
## timings job 同步产出 top10
否则下次刷新又胖回 197 行。
端到端复核:总量 16095s → 4 片,四片覆盖 67/67,最慢 74 分。
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
workspace (linux default 0/3)在 run 31266814148 被 90 分钟 job 上限砍掉 —— 28 个成员全绿,死在 cache/artifact 的 post 步骤。我先后猜过两个原因,都被数据否掉了:
matrix.toolchain进缓存键,开了新键命名空间),但另一轮同样冷缓存的default 0/3只用了 60 分钟。真正的原因在计时表。
计时表漏了两个重家伙
tests/member-timings.tsv停在 62 行 linux,而 workspace 已有 67 个成员。plan_shards对表里没有的成员按中位数计价:mysql-connector-cpplibmysqlclient20 分钟的工作量被当轻的,塞进了已经扛着
grpc-codegen的 shard 0。这两个数是从 run 31266814148 的
linux default 0/3步骤耗时里量出来的 —— 那一片正好被砍,timings artifact 从没上传,而它们又恰恰是导致溢出的成员。这个先有鸡还是先有蛋只能手工破一次,已在表头注明。表的其余部分来自 run 31260545520 的
member-timingsartifact,顺带补上cli11/cmdline/llmapi,并修正curl26→264s、eui-neo-sdl2119→591s。刷完表才看清:3 片本来就不够
刷新后 linux 总量 15891s = 265 分钟。按新表模拟最慢分片:
shards_for的公式secs / 4200 + 1对这个总量算出来就是 4,一直被cap 3压回去。所以这不是新引入的问题,是旧上限被工作量长过去了 —— 旧表让总量看起来只有 13570s,刚好还压得住。上限 3 → 4
旧注释给这个上限的理由是「linux 实测并发 3,第 4 片会排队」。这个前提已经两头失效:工作量长大了,而且自 #184 起 linux 每轮发
2 × N个 job,任何 N 都会排队。排队是对的取舍 —— 背靠背跑完的分片仍然完成,超过上限的分片不会。
代价:linux 每轮 8 个 job(原 6)。模拟确认
.shards读作 4、四片覆盖 67/67(#186 那个「数腿不数 job」的修复在 4 片下同样成立)。顺带
那段容量注释改成了现在为真的样子,并写明表要保持新鲜不是打扫卫生:一个没计时的成员按中位数打包,一个重的新成员就会像轻的一样被塞到任何地方 —— 这次就是这么炸的,而且陈旧的表还反过来把溢出藏了起来(总量看着比实际小 2300 秒)。
值得单独想一下的后续:能不能让「members 里有、计时表里没有」直接在
select阶段告警。现在这类漏计是静默的,而它的后果要等 90 分钟才以超时的形式出现。