Skip to content

branch-3.0: [file cache]add some stats for file_cache_statistics #51484 #51900

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: branch-3.0
Choose a base branch
from

Conversation

github-actions[bot]
Copy link
Contributor

Cherry-picked from #51484

…t_cache_in_advance stat/metrics when false

### What problem does this PR solve?

Currently, file_cache_statistics only exposes the overall hit rate, as
well as the 5-minute and 1-hour hit rates, which makes it impossible to
flexibly and accurately calculate the hit rate for any arbitrary time
period. Therefore, this PR exposes metrics such as the number of cache
reads and hits, enabling precise calculation of cache hit rates at the
query level.

Additionally, this PR also exposes the current states of
need_evict_cache_in_advance and disk_resource_limit_mode, as they
significantly impact cache performance and query hit rates. By making
them available in file_cache_statistics, users can easily retrieve these
metrics via SQL.

If the parameter enable_evict_file_cache_in_advance is set to false,
then the _need_evict_cache_in_advance_metrics should be set to 0.
@github-actions github-actions bot requested a review from dataroaring as a code owner June 18, 2025 11:58
@Thearas
Copy link
Contributor

Thearas commented Jun 18, 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 reopened this Jun 18, 2025
@Thearas
Copy link
Contributor

Thearas commented Jun 18, 2025

run buildall

@doris-robot
Copy link

BE UT Coverage Report

Increment line coverage 16.67% (1/6) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 41.16% (10902/26487)
Line Coverage 31.97% (93264/291703)
Region Coverage 31.05% (48096/154891)
Branch Coverage 27.52% (24638/89528)

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.

4 participants