ClickHouse Keeper 压测结果分析实战从 keeper_stress_tests 数据仓库到可归因的性能回归报告【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本文以 ClickHouse 仓库内置的keeper-stress-analysis技能SKILL.md为主体完整讲解如何基于play.clickhouse.com上的keeper_stress_tests.keeper_metrics_ts数据仓库Grafanakeeper-stress-run-details看板的数据源对 ClickHouse Keeper 的夜航nightly压测结果做端到端分析拉取 6 张 staging 表、构建派生表、选择正确的对比方法、应用血泪教训检查项最终产出可复现、可归因的 PR 级回归报告。读完后你将掌握一套能回答某个 PR 是否让 Keeper 变慢/变坏的完整分析工作流以及避免 cgroup 内存误判、co-merge 污染、噪声地板等常见陷阱的方法论。这个技能解决什么问题ClickHouse 对 Keeper其 ZooKeeper 兼容的 Raft 协调服务维护着一套持续运行的压测框架每个 master nightly 在多个场景scenario× 后端default/rocks上跑完整压测PR 分支在合并前还要跑 3 场景的 smoke 压测所有指标统一写入keeper_stress_tests.keeper_metrics_ts。CI 侧的入口是 keeper_stress_job.py它定义了keeper-stress-run-details、keeper-stress-run-comparison、keeper-stress-historical三块 Grafana 看板的 UID压测框架本体位于 tests/stress/keeper/场景定义在 core_no_faults.yaml 与 core_faults.yaml负载生成器则是 programs/keeper-bench/keeper-bench工具。keeper-stress-analysis技能把拿到看板数据 → 判断某个 PR 或某段日期窗口的 Keeper 是否回归/改进这件重复劳动固化为一个五阶段流水线并沉淀了多条被反复验证过的方法论教训。它只覆盖 Keeper 压测框架这一套数据不触碰其他 CI 数据。触发场景包括Validate these Keeper PRs against the stress tests验证这批 PRWhat changed in Keeper between 2026-04-01 and 2026-05-01?区间累计变化Did PR #X cause any regression in Keeper stress?单 PR 归因Why did p99 spike on date Y?自由分析Give me a summary report of Keeper stress runs总结报告技能目录结构、工作目录与 rebuild.sh技能主目录是包含 SKILL.md 的目录本仓库位于.claude/skills/keeper-stress-analysis/完整布局路径作用SKILL.md五阶段工作流 Phase 5 检查清单本文主体scripts/rebuild.sh编排器拉 6 条 SQL → 构建全部派生 TSVscripts/keeper_stress.pyPython 子命令分发入口merge/prmap/deltas/prmetrics/prisol/cumulative/diff/noisescripts/_common.py共享工具时间窗阈值、fault 判定、ISO 周、显著性分档scripts/tests/test_common.py29 个单测守住方法论与代码的一致性queries/6 条 staging SQL01_bench_summary ~ 06_pr_branchreferences/methodology.md三种对比方法、显著性区间、环境偏移references/known_confounds.md负载生成器bench侧伪回归编目references/metric_glossary.md每列指标的真实含义与使用禁忌references/report_templates.mdfull / tight / one-liner 三套等宽报告模板examples/sample_outputs/PR_PERF_TABLE.md标准范例数据支撑的 per-PR 表格工作目录约定默认工作目录为当前目录下的tmp/keeper_stress_skill/编排器 rebuild.sh 接受 3 个位置参数——$1工作目录、$2下界时间戳过滤默认2026-03-25即当前压测框架上线日、$3上界默认9999-12-31即无上界上界是开区间ts $3所以含 B 的闭区间 A→B要传 B1 天。两个边界经{{TS_FILTER}}/{{TS_FILTER_END}}占位符注入 SQL同时导出为环境变量KEEPER_SKILL_THRESHOLD/KEEPER_SKILL_THRESHOLD_END供build_pr_nightly_map.py和compute_deltas.py做窗口内 vs 窗口外切分。分析别的窗口只需换参数无需改源码。# 定位技能目录用户级 ~/.claude/skills/... 或项目级 repo/.claude/skills/... 均可 SKILL_HOME$(find ~/.claude/skills .claude/skills -maxdepth 2 -type d -name keeper-stress-analysis 2/dev/null | head -1) $SKILL_HOME/scripts/rebuild.sh tmp/keeper_stress_skill 2026-03-25 # 闭区间窗口分析例如 2026-04-01 到 2026-05-01 $SKILL_HOME/scripts/rebuild.sh tmp/keeper_stress_skill 2026-04-01 2026-05-01rebuild.sh的完整动作见 scripts/rebuild.sh把queries/*.sql和scripts/*.py拷入工作目录脚本以自身位置为 ROOT 找staging/兄弟文件依次对https://play.clickhouse.com/?userplay用curl --data-urlencode执行 6 条查询--fail-with-body保证 4xx/5xx 立刻中止并把服务器错误写进对应 staging 文件构建merged_metrics.tsv——每行对应一个 scenario × backend × commit约 95 列覆盖 bench / prom / mntr / container 四类指标若work_dir/../pr_meta.tsv存在PR 集合分析时由调用方提供则追加构建 per-PR 流水线prmap→deltas→prmetrics→prisol最后构建cumulative_gains.tsv与cumulative_gains_summary.tsv。落在staging/下的 6 张表各司其职bench_summary.tsv—— 负载生成器自报的 run 级汇总rps、p99、errors、ops、memprom_rates.tsv—— Keeper Prometheus 计数器按秒速率、分节点prom_gauges.tsv—— Prometheus gauge 累计失败计数器mntr.tsv—— ZooKeeper 4LWmntr命令输出container.tsv—— cgroup CPU 内存pr_branches.tsv—— PR 分支 smoke 压测每分支 3 场景。以 01_bench_summary.sql 为例可以看到数据模型的关键细节过滤source bench AND stage summary AND branch master按(scenario, backend, commit_sha)分组并且用argMaxIf(value, ts, name rps)而非朴素maxIf——当同一 commit 被重试过时argMaxIf保证取的是最新一次 run的每个指标值避免把不同 run 的峰值混进同一行。时间窗占位符ts {{TS_FILTER}} AND ts {{TS_FILTER_END}}正是rebuild.sh两个参数注入的位置。五阶段工作流Phase 1 — 捕获意图把用户请求归入四种形态决定跑哪条流水线请求形态识别信号执行的流水线日期窗口between A and B、since X、last N weeks累计增益流水线方法 BPR 集合PR 号列表、validate these PRsper-PR per-nightly 流水线单 PR 深挖单个 PR 号、did #X causeper-PR 卡片 相邻 nightly PR 分支隔离自由分析为什么 D 日 M 指标变了时间序列检查 交叉比对 known_confounds.md若用户没给窗口则必须追问日期区间、PR 集合或具体问题三选一默认窗口为2026-03-25当前框架上线日至今。Phase 2 — 拉取 staging 数据如前所述先无条件跑完 6 条 SQL 到work_dir/staging/再进入任何分析。Phase 3 — 构建派生表所有 Python 步骤统一经 keeper_stress.py 分发到各模块的main()意图运行命令日期窗口python3 keeper_stress.py cumulativePR 集合python3 keeper_stress.py prmapdeltasprmetrics需要pr_meta.tsvPR 分支隔离python3 keeper_stress.py prisol从pr_to_nightly.tsv读 PR 列表 分支任意两 commit Δpython3 keeper_stress.py diff shaA shaB8 位前缀或全 SHA噪声标定python3 keeper_stress.py noise按 (scenario, backend, metric) 出 median/stddev/cv/p95自由问答不跑流水线——直接对merged_metrics.tsv用awk/python查询PR 集合分析要求调用方提供pr_meta.tsv列为pr / title / mergedAt / mergeCommit / base / headRefName文件放在工作目录上一级../pr_meta.tsv以便所有脚本都能找到。headRefName对build_pr_branch_isolated.py是必需的——缺了它该步骤会静默产出空结果。缺失时可用gh生成{ printf pr\ttitle\tmergedAt\tmergeCommit\tbase\theadRefName\n for pr in numbers do out$(gh pr view $pr --repo ClickHouse/ClickHouse \ --json title,mergedAt,mergeCommit,baseRefName,headRefName \ -q [.title,.mergedAt,.mergeCommit.oid,.baseRefName,.headRefName] | tsv 2/dev/null) printf %s\t%s\n $pr $out done } tmp/keeper_stress_skill/../pr_meta.tsvper-PR 的 Markdown 矩阵不由脚本生成——由分析者直接基于per_pr_metrics_long.tsv长表格式 per-PR Δ 行与per_pr_summary.tsv窗口累计数撰写结构以 PR_PERF_TABLE.md 为模板判定verdict是分析者结合数据与 Phase 5 检查做出的判断不存在查表式的标准答案。Phase 4 — 生成产出按请求类型选产出物用户要什么去哪里取材总结报告report_templates.md 三套等宽模板full / tight / one-linerPer-PR Markdown 表PR_PERF_TABLE.md累计增益撰写从cumulative_gains_summary.tsv按模板格式组装Per-PR mover 矩阵 / 进度归因per_pr_metrics_long.tsvper_pr_summary.tsv完整验证报告per-PR 表 累计增益 caveats结构镜像标准范例填模板时永远交叉比对标准范例没有数据出处就不写结论句。常用自由配方——大多数切片查询不需要新流水线直接awk现有 TSV 即可# 某 PR 是否专门回归了 fault 场景 awk -F\t $1PR $3 ~ /-fault\[/ tmp/keeper_stress_skill/per_pr_scenario_deltas.tsv # 单场景验证一行含全部指标 Δ awk -F\t $1PR $3prod-mix-no-fault[default] tmp/keeper_stress_skill/per_pr_scenario_deltas.tsv # Δ 可疑时的 co-merge 诊断——看 per_pr_summary 的 co_merged 列 awk -F\t NR1 || $1PR tmp/keeper_stress_skill/per_pr_summary.tsv # 单个 (scenario, backend, metric) 的 per-commit 时间序列按 ts 升序 awk -F\t NR1 {for(i1;iNF;i) if($iMETRIC) ci; next} $1scenario $2backend $c! {print $5, $4, $c} \ tmp/keeper_stress_skill/merged_metrics.tsv | sort只有当目标切片在merged_metrics.tsv/per_pr_*.tsv里既不是现成的列也不是现成的行时才值得动用流水线。Phase 5 — 应用血泪教训检查引用任何数字之前必做1. 内存检查最常见陷阱报告任何 5% 的内存 Δ 之前必须分别查两个指标container_memory_bytes—— cgroup 峰值对 bench 侧 page cache 极度敏感KeeperApproximateDataSize—— Keeper 自报的内存状态znode 树、ephemeral、watch。若 cgroup 动了而KeeperApproximateDataSize没动则这个 Δ 是bench 侧的不是 Keeper 侧的。快速核对模式awk -F\t NR1 {next} $1SCENARIO $2BACKEND { date$5; gsub(/ .*/, , date) printf %s sha%s KeeperApproxDataSize%5.2fGB container_peak%5.2fGB\n, date, $4, $7/1e9, $720 } merged_metrics.tsv | sort2. 阶跃变化检查某个指标以单日阶跃形式出现在多个互不相关的场景上几乎必然是 bench 侧变化。对照 known_confounds.md#100670keeper-bench: go faster2026-04-04 合入——影响读密集场景内存与 multi-writeerror_pct#101801keeper-bench: more features2026-04-11 合入——影响 rocks 侧 write-multi 内存。3. 噪声地板检查单个 nightly 的 Δ 噪声地板是rps/p99 上的 ±3-5%。纯错别字 PR#102739不可能影响 Keeper 性能在 PR 分支隔离法下仍表现出 ±5% 的 rps Δ——这就是地板线。没有隔离手段时绝不宣称 3% 的 per-PR 效应。PR 分支隔离池的规则同周池子不足 2 个条目时用datetime的 ISO 周运算把池子放宽到 ±1 个 ISO 周正确处理 W01/W52-53 年边界同一分支的历史 run 从池中排除以免先前 WIP 提交把中位数拉偏。4. CPU 尖峰检查container_cpu_usage_usec速率会因计数器不连续run 内容器重启冒出虚假的 18-38 核尖峰。一律使用p95_cpu_cores永远不要用max_cpu_cores。5. 服务端失败检查窗口内这四个计数器必须全零KeeperCommitsFailedKeeperSnapshotCreationsFailedKeeperSnapshotApplysFailedKeeperRequestRejectedDueToSoftMemoryLimitCount任何非零值直接推翻一切通过结论。检查分两个作用域Per-PR仅合并后compute_deltas.py已在首个包含该 PR 的 nightly上计数写入per_pr_summary.tsv的server_failures_post列非零则 verdict 翻转为regression(server-failure)。整个窗口门禁对staging/prom_gauges.tsv跑下面的配方必须零输出# 全窗口门禁——不应产生任何行 awk -F\t NR1 $4 ~ /(CommitsFailed|SnapshotCreationsFailed|SnapshotApplysFailed|RejectedSoftMemoryLimit)/ $50 0 { print } staging/prom_gauges.tsv # 空结果 所有 nightly 均干净6. Co-merge 污染检查用户提供 PR 列表并计算 master 相邻 nightly Δ 时同一 Δ 对落在同一 nightly 窗口内的所有PR 联合可归因。per-PR 表必须带co_merged列效应量 5% 的联合窗口 Δ 绝不可记在单个 PR 头上。三种对比方法与显著性区间methodology 核心references/methodology.md 定义了三种方法的选择方法 A — 相邻 nightly 对比per-PR 归因pre PR 合并前最近一次、kind 匹配的 master nightlypost 合并后首个 kind 匹配 nightlyΔ (post - pre) / pre × 100。注意 kind 匹配的兜底规则有些 nightly 只跑 fault 场景、有些只跑 no-fault若缺匹配 kind 的基线回退到 kind 无关的 primary 基线per_pr_metrics_long.tsv的baseline_kind列会记录这一点如fault(fallback-primary-pre)——这是有意设计跨 kind 对比更吵但宁可降精度也不丢行。局限单端点带 ±3-5% 噪声同窗口多 PR 时 Δ 是联合的。方法 B — median-of-3 窗口对比累计baseline 窗口内前 3 个 no-fault nightly 的中位数current 后 3 个的中位数。用于过去 N 周累计效应能抹平单 nightly 噪声但无法在 5% 精度上归因到具体 PR且窗口内的 bench-harness 改动会被一并捕获。方法 C — PR 分支隔离最干净的 per-PR但场景受限每个 PR 分支跑 3 场景 smokeprod-mix-no-fault[default]、read-multi-no-fault[default]、write-multi-no-fault[default]其数值相对 master nightly 系统性偏移约 12%不同基础设施负载更低的 runner、更少的并行场景。取 PR 分支 HEAD 值对同周其他PR 分支 run 的中位数池求 Δ。仅 3 个场景、池大小取决于当周活跃 PR 数sanity 检查仍用#102739±5% rps Δ 噪声地板。显著性区间什么才算真变化指标方向cleanwatchregressionrps越高越好Δ ≥ −5%−5% ~ −15%Δ −15%read_p99_ms/write_p99_ms越低越好Δ ≤ 10%10% ~ 30%Δ 30%error_pct越低越好绝对 ΔPP 0.050.05 ~ 0.5≥ 0.5peak_mem_gb越低越好Δ ≤ 10%10% ~ 30% 30%硬失败计数器绝对值恰好为 0n/a任何非零这些数字的标定来源就是#102739这个不可能影响性能的 typos PRPR 分支隔离下表现出 ~5% rps 摆动、~10% p99 摆动因此 5% 是 rps 噪声地板、10% 是 p99/内存噪声地板clean设在地板处watch设在 3 倍地板处。这套区间在 scripts/_common.py 中以CLASSIFY_BANDS固化rps: (5,15)、read_p99_ms/peak_mem_gb: (10,30)等classify()函数按方向 × 区间输出 clean/watch/regression并由 tests/test_common.py 的 29 个用例守护——修改classify、iso_week、CLASSIFY_BANDS或HEADLINE_METRICS后必须跑cd skill_home/scripts python3 -m unittest tests.test_common -v一旦测试失败说明方法论与代码已经漂移——二者必须改回一致其中 methodology.md 的 rubric 是约束性契约。Bench-harness 混淆项把压测器变了和Keeper 变了分开known_confounds.md 编目了那些改动压测器、不改 Keeper却让看板指标出现单日阶跃的 PR#100670keeper-bench: go faster2026-04-04仅改programs/keeper-bench/*删除了负载生成器的 producer→queue→consumer 架构每个线程拥有自己的请求生成器与 RNG 种子内部队列原先对 worker 限流被移除。从 2026-04-04 起 master nightly 的表现读密集场景peak_mem_gbcgroup单日阶跃下降list-heavy-no-fault[default]0.86 → 0.55 GB−36%、read-multi-no-fault[default]0.71 → 0.50 GB−30%、read-no-fault[default]0.69 → 0.51 GB−26%、churn-no-fault[default]1.74 → 1.55 GB−11%multi-write 场景error_pct跳升约 3%原先被队列背压掩盖的 bench 侧客户端超时暴露出来KeeperApproximateDataSize不变——这是决定性证据cgroup 掉了、Keeper 自身状态没掉变化在 bench 不在 Keeper。#101801keeper-bench: more features2026-04-11同样仅改programs/keeper-bench/*write-multi-no-fault[rocks]内存 6.03 → 9.36 GB55%znode_delta 23.6M → 27.3M15%因为 bench 现在为每个 multi 生成更多子操作而 RocksDB 支撑的状态存储与内存态存储的行为不同default后端无此现象其 znode 基数已饱和。rps 全程不变~3060失败计数器为 0。新混淆项的识别流程某指标在同一日期、多个场景上同步阶跃 → 拉 5 个以上场景的时间序列确认同日 → 用git log master --sinceDATE --untilDATE1day过滤programs/keeper-bench/*查当日合入内容 → 把新发现补进编目。Keeper 侧 vs bench 侧的判别信号表信号Keeper 变化Bench 变化同日多个不相关场景联动不太可能Keeper 改动通常只影响特定路径很可能KeeperApproximateDataSize与container_memory_bytes相关性是否阶跃 vs 渐变通常渐变通常阶跃服务端计数器随之变化可能绝不可能rocks 与 default 是否对称是有时不对称指标字典要点哪些列能用、哪些列是陷阱metric_glossary.md 逐列说明了keeper_metrics_ts的真实含义核心禁忌值得单独列出来源标记sourcebench生成器自报stagesummary、promKeeper 的 Prometheus 端点含ClickHouseProfileEvents_*/ClickHouseAsyncMetrics_*/ClickHouseMetrics_*、mntr4LW 命令、containercgroup、dirs、lgif、gate。内存问Keeper 内存时必须用KeeperApproximateDataSizeKeeper 自报的 znode 树/ephemerals/watches 大小不含 page cache而不是container_memory_bytesmemory.usage_in_bytes RSS page cache slab 容器内一切。CPU用p95_cpu_cores每秒核数的 p95禁用max_cpu_cores。四个王牌失败计数器KeeperCommitsFailedRaft 日志条目提交失败、KeeperSnapshotCreationsFailed快照序列化失败、KeeperSnapshotApplysFailedfollower 快照 apply 失败、KeeperRequestRejectedDueToSoftMemoryLimitCount内存 tracker 拒绝请求——声明干净交付前必须确认全部场景 × 全部 nightly 为 0。锁争用KeeperStorageLockWaitMicroseconds取速率后 1000 µs/s 约等于一个核的 0.1%基本是噪声其下降是#100876KeeperLogStore改shared_mutex与#101502降低 profiled-lock 开销这类锁优化的签名特征。ZK mntr 指标zk_max_latency是自服务端启动以来观测到的最大延迟单尾离群点会把它吹爆绝对值 ≤500ms 的变化应视为噪声zk_avg_latency是长期平均变化缓慢。每请求类型计数器KeeperMultiRequest、KeeperSetRequest等是累计 ProfileEvents取速率后可用于校验负载构成如read-multi应以KeeperMultiReadRequest为主。日志缓存KeeperLogsEntryReadFromFile多 缓存 miss 主导 坏信号应与KeeperLogsEntryReadFromLatestCache/KeeperLogsEntryReadFromCommitCache对比。Leader 归属KeeperIsLeader/KeeperIsFollower中每次 run 三节点里恰好一个 leader1leader 在 run 内粘滞、跨 run 轮换属正常现象不是回归。标准范例per-PR 数据表长什么样PR_PERF_TABLE.md 是该技能沉淀的完整范例33 个 PR 中 11 个性能 PR 的逐 PR 表格它示范了本方法论全部要点的落地每个 PR 只报与其意图匹配的指标集锁争用 PR 报StorageLockWaitrps内存 PR 报peak_mem_gbKeeperApproximateDataSize快照 PR 报SnapshotWritten_B_per_sSnapshotApplysFailed。例如#100876KeeperLogStore改shared_mutex的签名正是读吞吐上升 锁等待时间下降read-multi-no-fault[default]的StorageLockWait_us_per_s_avg72.91 → 64.88−11.01%四个读密集场景 rps 2.7% ~ 4.7%。窗口内 PR 用 pre/post 直接测量如#100778并行读请求read-no-fault[default]rps 173,604 → 183,2315.55%阈值前2026-03-25 前合入的 PR 效应已折叠进基线只能给累计联合签名不能做直接归因。诚实声明局限非性能 PR 出现指标 Δ 的两大来源是 co-merge 污染与 run-to-run 噪声typos PR 在multi-large上表现出 215.8% 的StorageLockWaitΔ但绝对量 142 µs/s 仅占一个核的 0.014%文末给出该数据集能支撑/不能支撑哪些结论的置信度矩阵并明确33 个 PR 无一引入服务端失败模式。累计口径11 个性能 PR 联合效果为读密集 4.1% ~ 5.3% rps、读 p99 −1.4% ~ −12.9%、峰值内存 −10.6% ~ −26.4%写密集 write p99 −5.7% ~ −7.2%。三个典型工作流示例示例 1 — 单 PR 深挖PR #99651 是否让 Keeper 回归gh pr view 99651 --repo ClickHouse/ClickHouse --json title,mergedAt,mergeCommit取元数据跑rebuild.sh tmp/keeper_stress_skill 2026-03-25在merged_metrics.tsv中过滤合并前 nightlyfdf46ee1与合并后 nightlye02b59d7的prod-mix-no-fault[default]、write-multi-no-fault[default]应用 Phase 5 内存检查prod-mix peak_mem 2.92→2.72 GB−6.9%只出现在 cgroup而KeeperApproximateDataSize平稳 → 判定为 bench 侧噪声/快照时序假象不是 Keeper 真实改进确认其后 18 个 nightly 上KeeperSnapshotApplysFailed0输出 per-PR 卡片verdict 为 clean— 无回归prod-mix peak_mem 下降是单 nightly 的 cgroup 假象。示例 2 — 日期窗口2026-04-01 到 2026-05-01 Keeper 变了什么rebuild.sh tmp/keeper_stress_skill 2026-04-01 2026-05-01——闭区间必须传两个边界第三个参数钉住上界ts 2026-05-01防止更新的 nightly 渗进结果跑cumulativemedian-of-3 vs median-of-3产出cumulative_gains_summary.tsv应用 Phase 5 检查并点名窗口内的 bench-harness 混淆项#10067004-04与#10180104-11都在窗口内因此任何读密集内存或 rocks 侧 write-multi 内存 Δ 都必须带上混淆项注释按 report_templates.md 格式输出带保守 Δ caveats 的累计增益报告。示例 3 — PR 集合总结用gh构建pr_meta.tsv→ 跑完整流水线 → 按意图给 PR 分类性能/正确性/工具链/重构/净零→ 填 full 模板 → 应用 Phase 5 caveats窗口内有 bench-harness 变更时按 PR 号点名。数据正确性验证点分析完成后应抽查三个已知数据点全部固化在 examples/sample_outputs/ 中mastere02b59d72026-04-02在write-multi-no-fault[default]上必须errors0bench 变更之前master18dfe15a2026-04-04同场景必须errors≈325k、error_pct≈3.67。两者不符说明 bench-summary 查询写错了。2026-03-25 以来所有 master nightly 的四个硬失败计数器必须全零任何非零要么数据损坏要么有真实故障要报告。740b4a5keeper-object-based-snapshots分支在prod-mix-no-fault[default]上必须显示rps5,764、read_p99545 ms、write_p99535 ms、errors0——这是#99651的验证锚点。输出纪律请求的是分析而非套模板报告时产出固定三段式核心结论—— 1-2 句直接给 verdict支撑表格—— 每个论断都有具体的 scenario metric 数值Caveats—— 噪声地板、co-merge、bench-harness 局限。无隔离证据时绝不给出 5% 效应量的 confident per-PR 百分比。用户要求更严格时默认走保守方法median-of-3 PR 分支隔离并报区间而非点估计。适用前提与限制数据源是play.clickhouse.com的公开实例keeper_stress_tests.keeper_metrics_ts库查询通过 HTTP?userplay接口执行无需本地部署当前压测框架自2026-03-25起运行早于该日期的 PR 只能获得累计联合签名级别的证据无法直接归因单 nightly 对比的测量分辨率为 rps/p99 ±3-5%、error_pct±0.05pp低于该分辨率的效应如非性能 PR 的 sub-3% 副作用)在本数据集上不可判定所有日期、SHA、PR 号均指仓库内文档与范例中记录的 2026 年数据窗口复现分析时请以rebuild.sh实际拉取的数据为准。这套技能的价值不在任何单条 SQL 或脚本而在于它把哪些数字可信、哪些数字是陷阱变成了可执行的检查清单与可测试的代码classify的 29 个单测让这个 PR 有没有弄坏 Keeper从一次性的手工考证变成一条可重复、可复核的流水线。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考