Skip to content

branch-4.1: [fix](file cache) keep the cache monitor off the LRU recorder lock #67315 - #67495

Open
github-actions[bot] wants to merge 1 commit into
branch-4.1from
auto-pick-67315-branch-4.1
Open

branch-4.1: [fix](file cache) keep the cache monitor off the LRU recorder lock #67315#67495
github-actions[bot] wants to merge 1 commit into
branch-4.1from
auto-pick-67315-branch-4.1

Conversation

@github-actions

@github-actions github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

Cherry-picked from #67315

…67315)

run_background_monitor() ended its loop with
update_shadow_queue_element_count_metrics(), which takes _mutex_lru_log.
The LRU log replay thread holds that lock for as long as it takes to
drain the log queue, so a slow consumer froze the monitor with it:
check_disk_resource_limit(), check_need_evict_cache_in_advance() and
every gauge stopped running, and the disk resource limit mode stayed at
whatever value it happened to hold. Gauges were observed frozen for up
to 40 minutes in production.

The call was redundant from the start. #64798 added the shadow queue
element count gauge and published it in two places: inside
replay_queue_event(), under the same lock that mutates the shadow queue,
and again from the monitor every
file_cache_background_monitor_interval_ms as a periodic refresh. Nothing
outside replay_queue_event() mutates a shadow queue, so that refresh
could only rewrite a value that had just been published and could not
have changed since. What it did add was a dependency from the disk
protection loop onto a lock owned by a background consumer.

Drop the call, and update_shadow_queue_element_count_metrics() with it:
it existed only for that refresh, and leaving a public method that takes
_mutex_lru_log invites the next background loop to reintroduce the
coupling. The gauge is still published by replay, now on the replay
interval instead of the monitor interval. Its test is replaced by one
asserting that replay publishes the gauge on its own.

How long replay holds the lock is a separate problem, addressed
separately.
@github-actions
github-actions Bot requested a review from yiguolei as a code owner September 3, 2026 12:00
@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@hello-stephen

Copy link
Copy Markdown
Contributor

run buildall

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