Skip to content

branch-4.1: [fix](fe) Avoid eager allocations in cloud tablet indexes #66378 - #66406

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

branch-4.1: [fix](fe) Avoid eager allocations in cloud tablet indexes #66378#66406
github-actions[bot] wants to merge 1 commit into
branch-4.1from
auto-pick-66378-branch-4.1

Conversation

@github-actions

@github-actions github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Cherry-picked from #66378

Problem Summary: Cloud tablet route-cache rebuilding calls
fillBeToTablets for current and future placements. The previous
putIfAbsent calls eagerly constructed up to six candidate maps and sets
for every placement even when the keys already existed, and then
performed separate lookups. Use the containers returned by
computeIfAbsent at every level and add a focused unit test that verifies
all six container paths while preserving the global, table, and
partition index contents.

An isomorphic multi-scale JVM allocation model with 2 million entities,
four-route fan-out, current/future passes, and three index scopes
estimated cumulative allocation per modeled rebuild at 12.52 GiB before
and 8.59 GiB after the change, saving 3.93 GiB (31.4%). For 4 million
tablets, the fill-path cumulative-allocation reduction is expected to
remain about 31% under comparable topology, while the absolute GiB
saving depends on cluster and replica fan-out. The retained graph
remained about 3.76 GiB and the peak proxy about 966 MiB, so this change
does not claim a comparable steady-state heap or process-wide reduction.
Timing samples were noisy, so no throughput improvement is claimed.
@github-actions
github-actions Bot requested a review from yiguolei as a code owner August 4, 2026 02:21
@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