Skip to content

Conversation

@github-actions
Copy link
Contributor

@github-actions github-actions bot commented Mar 7, 2025

Cherry-picked from #48687

The initialization of the file cache involves asynchronous loading logic
and synchronous upgrade directories. The latter mainly handles the
conversion from version1 to version2 format and some fallback logic for
problematic directories, which involves a large number of directory
traversals and can be very slow.

Previously, in PR #44429, we changed the initialization of multiple
cache directories from parallel to serial to avoid the disorder caused
by concurrent initialization, which led to a long cache initialization
time and affected the startup speed of the BE.

We found that the upgrade directory is only meaningful during upgrades
and does not need to be executed on every restart. Therefore, if we
detect that the version file has been successfully written, we consider
the cache directory to have completed the upgrade and skip these
redundant directory traversals

Of course, we could further optimize the directory traversal process to
make it asynchronous and not block the BE startup. However, this would
result in three concurrent operations on the file system: asynchronous
loading, asynchronous updating, and lazy loading on query. This would
increase code complexity, the likelihood of errors, and the difficulty
of troubleshooting. Considering that old clusters are not very common
and that a cluster only needs to go through such an upgrade once in its
lifecycle, we assessed that this optimization would have low
cost-effectiveness and decided not to pursue it.

Signed-off-by: zhengyu <zhangzhengyu@selectdb.com>
@github-actions github-actions bot requested a review from dataroaring as a code owner March 7, 2025 03:11
@Thearas
Copy link
Contributor

Thearas commented Mar 7, 2025

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?

@dataroaring dataroaring closed this Mar 7, 2025
@dataroaring dataroaring reopened this Mar 7, 2025
@Thearas
Copy link
Contributor

Thearas commented Mar 7, 2025

run buildall

Copy link
Contributor

@dataroaring dataroaring left a comment

Choose a reason for hiding this comment

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

LGTM

@github-actions github-actions bot added the approved Indicates a PR has been approved by one committer. label Mar 10, 2025
@github-actions
Copy link
Contributor Author

PR approved by at least one committer and no changes requested.

@github-actions
Copy link
Contributor Author

PR approved by anyone and no changes requested.

@dataroaring dataroaring merged commit 3134267 into branch-3.0 Mar 10, 2025
21 of 24 checks passed
@github-actions github-actions bot deleted the auto-pick-48687-branch-3.0 branch March 10, 2025 06:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by one committer. reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants