Skip to content

branch-4.0: [Opt](warmup) Limit the download rate of warmup task (#60180)#60841

Open
bobhan1 wants to merge 1 commit intoapache:branch-4.0from
bobhan1:branch-4.0-pick-60180
Open

branch-4.0: [Opt](warmup) Limit the download rate of warmup task (#60180)#60841
bobhan1 wants to merge 1 commit intoapache:branch-4.0from
bobhan1:branch-4.0-pick-60180

Conversation

@bobhan1
Copy link
Contributor

@bobhan1 bobhan1 commented Feb 26, 2026

pick #60180

  Summary

This PR adds rate limiting support for warmup download tasks in file
cache and introduces a generic DEFINE_ON_UPDATE macro for config update
callbacks.

  Key changes:
- Add new config file_cache_warmup_download_rate_limit_bytes_per_second
(default 100MB/s, ≤0 means no limit)
- Introduce DEFINE_ON_UPDATE macro to register callbacks triggered when
config values change at runtime
- Implement S3RateLimiterHolder in ExecEnv for node-level warmup
download rate limiting
- Add bvar metrics for monitoring: warmup_download_rate_limit_latency,
warmup_download_rate_limit_ns, warmup_download_rate_limit_exceed_req_num
  - Rate limit can be dynamically updated at runtime without restart

  Problem & Solution

When file cache warmup tasks download large amounts of data from remote
storage (e.g., S3), they can consume excessive bandwidth and impact
normal query performance. This PR introduces a configurable rate limiter
specifically for warmup downloads to prevent bandwidth saturation.

The DEFINE_ON_UPDATE mechanism enables runtime config changes to take
effect immediately by triggering registered callbacks, allowing the rate
limiter to be adjusted dynamically without service restart.

  Test plan

- Added unit tests for DEFINE_ON_UPDATE callback mechanism
(config_on_update_test.cpp)
- Tests cover Int64, String, and Bool config types with callback
invocation verification
@bobhan1 bobhan1 requested a review from yiguolei as a code owner February 26, 2026 02:37
@Thearas
Copy link
Contributor

Thearas commented Feb 26, 2026

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?

@bobhan1
Copy link
Contributor Author

bobhan1 commented Feb 26, 2026

run buildall

@doris-robot
Copy link

BE UT Coverage Report

Increment line coverage 55.26% (21/38) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 52.99% (19130/36100)
Line Coverage 36.17% (178111/492396)
Region Coverage 32.75% (137919/421068)
Branch Coverage 33.73% (59913/177633)

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.

3 participants