Store logs in batches as they are collected instead of dropping them - #83
Open
define-null wants to merge 1 commit into
Open
define-null wants to merge 1 commit into
define-null wants to merge 1 commit into
Conversation
When the buffer filled up, the round dropped every page that arrived after that, signature checks and all, and skipped the remaining workers, only to request the same logs again next round. And no worker was requested while the whole buffer was inserted at the end of the round, which with a large buffer takes a good part of each round. Turn the buffer into a flow-control point: a worker waits for room instead of dropping its page, and a writer stores a batch as soon as MAX_INSERT_BATCH_BYTES has accumulated, while collection goes on, then the rest at the end of the round. When ClickHouse is slower than the workers, rounds get longer instead of wasting work. Workers furthest behind are requested first. A failed INSERT ends the round: the workers still collecting are cancelled and the rest of the buffer is discarded, so the next round collects it again from the watermark. Storing anything past a failed batch would advance a worker's watermark over the failed rows for good. The failed batch isn't retried either: if the INSERT reached ClickHouse before failing, a retry would store it twice, while the watermark already covers it. logs_deferred goes, since nothing is deferred any more, and buffer_max_bytes is now the size at which collection waits for the writer. Bump logs-collector to 2.6.0. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
define-null
force-pushed
the
logs-collector-flush-on-full-buffer
branch
from
September 25, 2026 16:06
2c2d886 to
2667ad8
Compare
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
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.
Each round inserts the whole buffer only after every worker is done, so no worker is requested while it is inserted, and a full buffer drops pages that were already fetched and verified, only to request them again next round. With a large buffer, the insert at the end takes a good part of each round.
Changes
MAX_INSERT_BATCH_BYTES) as soon as one has accumulated, while collection goes on; the rest is stored at the end of the round.MAX_BUFFER_BYTESnow bounds memory under a slow ClickHouse; nothing is re-fetched.HashSetorder.logs_collector_logs_deferred_totalis removed;buffer_max_bytesis now the size at which collection waits for the writer.futuresandtokio-utilare no longer dependencies. Version 2.5.0 → 2.6.0.Notes
MAX_PAGES, timeouts andCONCURRENT_WORKERSare unchanged.MAX_BUFFER_BYTESplus up toCONCURRENT_WORKERSpages held by workers waiting for room. With batches stored as they fill, the buffer stays near one batch unless ClickHouse falls behind, so a raisedMAX_BUFFER_BYTEScan go back towards the 256 MiB default.Dumped logs to storage(withlogs) now reports the whole round's rows; per-batch lines are debug.Rollout: deploy, check that
round_duration_secondsdrops and requests continue through the end of each round, then lowerMAX_BUFFER_BYTESif it was raised.Tested with 14 simulated-time tests, including: batches stored within a round, workers waiting for room without a page being requested twice, a failed batch ending the round without loss or duplicates, an INSERT that fails after writing not being stored twice, and furthest-behind-first order. fmt, clippy (
-D warnings) and workspace tests pass on 1.98. Not yet run against real workers.🤖 Generated with Claude Code