ci: probe the tic statement's analysis cost on a runner (do not merge) - #563
Closed
MarcusKainth wants to merge 2 commits into
Closed
MarcusKainth wants to merge 2 commits into
MarcusKainth wants to merge 2 commits into
Conversation
Temporary. Measures one stage1 and stage2 resident analysis alone, four at once, and four at once beside a run_statement batch tic, from system.query_log on ubuntu-latest. The first-tic timeout is raised so a loaded runner still finishes its analyses. Not for merging.
github-actions
Bot
added
area: ci
Owner
Author
|
Measurement done: runs 36059942650 (attempts 1 and 2). Closing without merging. |
1 task done
MarcusKainth
added a commit
that referenced
this pull request
Sep 25, 2026
A dated post for docs/blog/ on the CI work of 24 and 25 September: the required check that no job reported, one statement analysis per test, the analyser pass that hashed nested subqueries for every comparison in a chain, the smaller test archive and the regrouping, and the nightly regression record. Every figure cites a committed file, a pull request body or a CI run by id. The runner probe's and the queue delay's figures were added to the bodies of #563 and #564 so the post has a durable source for them.
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.
What this changes, and why
A measurement, not a change to merge. It adds a temporary workflow that runs on
ubuntu-latest and reports, from system.query_log, what one resident stage1 and
stage2 analysis of the tic statement costs: one session alone, four sessions at
once in separate databases, and four at once beside one
run_statementbatchtic. The CI plan uses these numbers in place of local numbers scaled by a
guessed ratio.
The first-tic timeout is raised to 1,800 s on this branch only, so a loaded
runner finishes its analyses and they reach query_log.
Evidence
The probe job's log carries the runner's CPU model, core count, RAM and the
query_log table. Run ids are recorded when the runs finish.
Invariants
None. Nothing here is meant to land.
Spec impact
Anything else
Close without merging.
Written mostly by Claude Opus 5.5.
Results
Run 36059942650, two attempts on ubuntu-latest (4 vCPU, 15 GiB), ClickHouse 26.8.2.7,
ProfileEvents['QueryAnalysisMicroseconds']fromsystem.query_log. Attempt 1 ran on an AMD EPYC 7763, attempt 2 on an AMD EPYC 9V74. Run 36059341362 failed before measuring (the probe script had no exec bit).Stage1 analysis, seconds (EPYC 7763 / EPYC 9V74):
run_statementticStage2 analysis: 2.9 / 2.8 s alone, 12.8 to 18.1 s with four at once. Peak memory per stage1 about 860 MiB.
Alone, a runner analyses 3.5 to 3.7 times slower than a development machine's 40.9 s. The analysis is single-threaded and CPU-bound, and four at once take about three times as long each while CPU time rises from about 150 s to about 215 s: the 4-vCPU runner behaves as about two physical cores, so it completes about one analysis per 110 s whatever the thread count.