Backport #24554 to 7.82.x: keep broker_timestamps in memory and persist every 5 minutes#24592
Merged
Conversation
…minutes (#24554) * kafka_consumer: keep broker_timestamps in memory and persist every 5 min Loading and marshalling the whole broker_timestamps cache on every run created a large, growing transient allocation each cycle (the cache grows toward its per-cluster cap), which fragments the heap. Keep the cache in memory across runs (loading from disk only once) and persist it to disk at most every 5 minutes, so per-run allocation churn no longer scales with the cache size. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Add changelog entry for periodic broker_timestamps persistence Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Address review: drop leading underscores on new cache attributes, remove comments Rename broker_timestamps / broker_timestamps_last_save without a leading underscore per the repo naming convention (leading underscores are reserved for Pydantic private attributes), and drop the explanatory comments. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> (cherry picked from commit 3c3a9fe)
piochelepiotr
marked this pull request as ready for review
July 17, 2026 14:19
|
Backport evaluation: View Slack thread |
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 7410371 | Docs | Datadog PR Page | Give us feedback! |
nubtron
approved these changes
Jul 20, 2026
Contributor
Validation ReportAll 21 validations passed. Show details
|
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.
What does this PR do?
Backports #24554 to the
7.82.xbranch. Keeps the DSMbroker_timestampshistory in memory across check runs (loaded from the persistent cache only once, on the first run) and persists it back to disk at most once every 5 minutes, instead of loading and dumping the whole structure on every run.Motivation
With Data Streams enabled, the
broker_timestampscache grows toward its per-cluster entry cap. Loading it from disk and re-dumping it on every run created a large transient allocation each cycle that scales with the cache size, fragmenting the heap and driving agent RSS up. Holding the structure in memory removes the per-run load/dump churn; periodic persistence (every 5 min) preserves restart durability while keeping write churn low. On agent restart at most a few minutes of timestamp history is lost, which is acceptable for lag-in-seconds interpolation.See #incident-57455 for the impact on memory fragmentation.
Note: the
7.82.xbranch still persistsbroker_timestampsviajson.dumps/json.loads, since the switch tobase64+marshalserialization landed onmasterin a separate, later commit not covered by #24554. This backport applies the same in-memory/periodic-persistence behavior on top of the existing json-based read/write, and does not pull in the marshal/base64 change.Review checklist (to be filled by reviewers)
qa/requiredif this PR needs QA validation, orqa/skip-qaif it does not. Exactly one of the two is required.backport/<branch-name>label to the PR and it will automatically open a backport PR once this one is merged