Skip to content

compute: instrument logging dataflow volume and step duration - #39178

Merged
antiguru merged 1 commit into
mainfrom
logging-metrics
Sep 29, 2026
Merged

antiguru merged 1 commit into
mainfrom
logging-metrics

Conversation

@antiguru

@antiguru antiguru commented Sep 27, 2026 •

Copy link
Copy Markdown
Member

Adds two per-worker metrics for the compute logging dataflow, to make its volume and burstiness visible. mz_compute_logging_records_total{log} counts the records each logger (timely, reachability, differential, compute) hands to the logging dataflow. mz_compute_logging_step_duration_seconds observes how long each scheduling of the logging dataflow takes as a whole.

The step histogram comes from the schedule events timely logs for the dataflow root, which the logging dataflow now receives on a dedicated logger. With log_logging set the dataflow keeps the worker's timely logger and the histogram stays empty, because mz_scheduling_elapsed already covers it in that mode.

Posted by Claude Code.

🤖 Generated with Claude Code

@antiguru
antiguru added this pull request to stack #39180 September 27, 2026 18:55
@antiguru antiguru changed the title logging metrics compute: instrument logging dataflow volume and step duration Sep 27, 2026
@antiguru
antiguru marked this pull request as ready for review September 27, 2026 18:58
@antiguru
antiguru requested review from a team as code owners September 27, 2026 18:58
@antiguru
antiguru requested a review from DAlperin September 27, 2026 18:59
@linear-code

linear-code Bot commented Sep 27, 2026

Copy link
Copy Markdown

CPU-266

@DAlperin DAlperin left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks

Add two per-worker metrics for the logging dataflow. The counter
`mz_compute_logging_records_total` counts the records each logger hands to the
logging dataflow, labeled by log. The histogram
`mz_compute_logging_step_duration_seconds` observes how long each scheduling of
the logging dataflow takes as a whole.

The worker logs the start and stop of every dataflow scheduling to the logger
passed at dataflow creation. The logging dataflow now receives a dedicated
logger that turns its own schedule events into histogram observations. With
`log_logging` set, it keeps the worker's timely logger, and the histogram
stays empty because `mz_scheduling_elapsed` covers the dataflow.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
@antiguru
antiguru merged commit d1c6f88 into main Sep 29, 2026
87 checks passed
@antiguru
antiguru deleted the logging-metrics branch September 29, 2026 16:30
antiguru added a commit that referenced this pull request Sep 29, 2026
The logging replay operators only woke up once per introspection
interval, so each worker processed a whole second of timely,
reachability, differential and compute events in one uninterruptible
call. That burst kept all workers busy for about 100 ms each second and
stalled dataflows that need every worker to make progress, such as
subscribes. The burstiness hurt, not the volume: a 100 ms interval used
the same total logging CPU and did not show the tail.

This counts every published log batch towards the replay's existing
activation threshold of 128, so the logging dataflow drains its input in
bounded chunks. The activator stays on the worker thread and never
unparks it, so idle workers keep sleeping.

On a 4-worker replica with 1k subscribe timestamps/s, p99 latency of
results waiting on the subscribe frontier dropped from 78-86 ms to 9-14
ms, close to running with logging disabled. The per-second worst index
`SELECT` latency halved. This was measured on a noisy shared machine;
#39178 adds metrics to confirm the effect elsewhere.

Posted by Claude Code.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5.5 <[email protected]>
@bosconi bosconi mentioned this pull request Oct 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants