[fix](cloud) speed up file cache initializtion #48687
Merged
Conversation
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
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 apache#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>
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
Contributor
Author
|
run buildall |
1 similar comment
Contributor
Author
|
run buildall |
TPC-H: Total hot run time: 32557 ms |
TPC-DS: Total hot run time: 184843 ms |
ClickBench: Total hot run time: 31.24 s |
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
gavinchou
reviewed
Mar 6, 2025
| Status FSFileCacheStorage::upgrade_cache_dir_if_necessary() const { | ||
| /// version 1.0: cache_base_path / key / offset | ||
| /// version 2.0: cache_base_path / key_prefix / key / offset | ||
| /* |
Contributor
There was a problem hiding this comment.
add more log to show whether we need to "upgrade", print previous and current version before right after "read_file_cache_version"
add some stats like file count, time consumption and etc when upgrade
Signed-off-by: zhengyu <zhangzhengyu@selectdb.com>
Contributor
Author
|
run buildall |
1 similar comment
Contributor
Author
|
run buildall |
gavinchou
approved these changes
Mar 6, 2025
github-actions
bot
added
the
approved
Contributor
|
PR approved by at least one committer and no changes requested. |
Contributor
|
PR approved by anyone and no changes requested. |
TPC-H: Total hot run time: 32687 ms |
TPC-DS: Total hot run time: 191997 ms |
ClickBench: Total hot run time: 30.46 s |
Contributor
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
github-actions bot
pushed a commit
that referenced
this pull request
Mar 7, 2025
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>
dataroaring
pushed a commit
that referenced
this pull request
Mar 10, 2025
Closed
koarz
pushed a commit
to koarz/doris
that referenced
this pull request
Jun 4, 2025
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 apache#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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
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.
What problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)