mirror of
https://github.com/hanzoai/datastore.git
synced 2026-10-30 14:48:37 +00:00
Address review comment 3194583058: the date-range workflow promised
"between A and B" but only filtered ts >= '{{TS_FILTER}}', so a request
like "between 2026-04-01 and 2026-05-01" silently included every nightly
after 2026-05-01 and let cumulative deltas drift as new runs accumulated.
Add a parallel TS_FILTER_END / KEEPER_SKILL_THRESHOLD_END upper bound that
mirrors the existing lower bound at every layer:
- All 6 staging SQL queries: append `AND ts < '{{TS_FILTER_END}}'`.
- `rebuild.sh`: accept `$3` as the upper bound; sed-substitute both
placeholders; export both env vars for the Python pipeline.
- `_common.py`: parse `KEEPER_SKILL_THRESHOLD_END` (defaults to far-future
sentinel `9999-12-31`) so unbounded callers keep today's behavior.
- `build_pr_nightly_map.py` and `compute_deltas.py`: filter PRs against
the half-open `[THRESHOLD, THRESHOLD_END)` interval.
- `SKILL.md`: update Phase 2 invocation and Example 2 ("between
2026-04-01 and 2026-05-01") to pass both bounds.
- `tests/test_common.py`: 2 new cases for the `THRESHOLD_END` default
and explicit-env-var parse path. 23 -> 25 cases, all pass.
Backward-compat regression contract: invoking `rebuild.sh ... 2026-03-25`
(no upper bound) still produces `cumulative_gains.tsv` md5
e5a27e01008ef7e23597ee041f68103b and the `#99651` PR-branch isolation row
bit-identical. Bounded smoke (`... 2026-03-25 2026-04-15`) verified to
produce strictly fewer rows in `bench_summary.tsv` and `merged_metrics.tsv`,
with max `run_ended` < `2026-04-15` and all `pr_to_nightly.tsv` `merged_at`
< `2026-04-15`.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
50 lines
1.8 KiB
SQL
50 lines
1.8 KiB
SQL
-- container metrics: peak memory bytes; CPU rate (cores) p95 & max
|
|
WITH base AS (
|
|
SELECT scenario, backend, commit_sha, name, node,
|
|
toUnixTimestamp(ts) AS t,
|
|
max(value) AS v
|
|
FROM keeper_stress_tests.keeper_metrics_ts
|
|
WHERE source = 'container'
|
|
AND branch = 'master'
|
|
AND ts >= '{{TS_FILTER}}'
|
|
AND ts < '{{TS_FILTER_END}}'
|
|
AND node IN ('keeper1', 'keeper2', 'keeper3')
|
|
AND name IN ('container_cpu_usage_usec', 'container_memory_bytes')
|
|
GROUP BY scenario, backend, commit_sha, name, node, ts
|
|
),
|
|
cpu_rated AS (
|
|
SELECT scenario, backend, commit_sha, node,
|
|
(v - lagInFrame(v, 1) OVER (PARTITION BY scenario, backend, commit_sha, node ORDER BY t))
|
|
/ nullIf(t - lagInFrame(t, 1) OVER (PARTITION BY scenario, backend, commit_sha, node ORDER BY t), 0) / 1e6 AS cores
|
|
FROM base
|
|
WHERE name = 'container_cpu_usage_usec'
|
|
),
|
|
cpu_agg AS (
|
|
SELECT scenario, backend, commit_sha,
|
|
round(avg(cores), 2) AS avg_cpu_cores,
|
|
round(quantile(0.95)(cores), 2) AS p95_cpu_cores,
|
|
round(max(cores), 2) AS max_cpu_cores
|
|
FROM cpu_rated
|
|
WHERE cores IS NOT NULL AND cores >= 0
|
|
GROUP BY scenario, backend, commit_sha
|
|
),
|
|
mem_agg AS (
|
|
SELECT scenario, backend, commit_sha,
|
|
round(max(v) / 1e9, 3) AS peak_mem_gb,
|
|
round(avg(v) / 1e9, 3) AS avg_mem_gb
|
|
FROM base
|
|
WHERE name = 'container_memory_bytes'
|
|
GROUP BY scenario, backend, commit_sha
|
|
)
|
|
SELECT
|
|
coalesce(m.scenario, c.scenario) AS scenario,
|
|
coalesce(m.backend, c.backend) AS backend,
|
|
coalesce(m.commit_sha, c.commit_sha) AS commit_sha,
|
|
m.peak_mem_gb, m.avg_mem_gb,
|
|
c.avg_cpu_cores, c.p95_cpu_cores, c.max_cpu_cores
|
|
FROM mem_agg m
|
|
FULL OUTER JOIN cpu_agg c
|
|
ON m.scenario = c.scenario AND m.backend = c.backend AND m.commit_sha = c.commit_sha
|
|
ORDER BY scenario, backend, commit_sha
|
|
FORMAT TSVWithNames
|