sollhui opened a new pull request, #67781:
URL: https://github.com/apache/doris/pull/67781
### What problem does this PR solve?
Problem Summary:
The tablet and load delete bitmap executors currently keep fixed thread
limits while memtable flush already adapts to queue depth and CPU/IO pressure.
Register `calc_delete_bitmap` and `calc_delete_bitmap_for_load` as independent
groups in the shared storage-engine startup path, reusing the existing flush
adjustment policy with each executor's own queue.
Add registration with absolute thread limits so each executor retains its
configured maximum and minimum of one thread. The load executor's non-positive
configuration continues to resolve to `max(1, CPU cores / 2)`. The existing
per-CPU registration API delegates to the same implementation for flush groups.
`enable_adaptive_flush_threads` controls all three groups.
Both local and cloud engines use this registration path. Their existing
shutdown paths stop the controller before destroying the executors. No
transaction, delete bitmap calculation, storage format, or RPC changes are
introduced.
### Release note
Delete bitmap calculation thread pools now adapt independently to their
queue depth and system CPU/IO pressure when `enable_adaptive_flush_threads` is
enabled, within their existing configured thread limits.
### Check List (For Author)
- Test:
- Added BE unit tests for absolute limits, disabled adjustment,
independent delete bitmap queue recovery, and storage-engine registration.
- Compilation and test execution were skipped at the author's request.
Initial attempts stopped during dependency setup; no BE test results are
claimed.
- clang-format 16 check passed for all changed C++ files.
- Build header hygiene and `git diff --check` passed.
- Behavior changed: Yes. Delete bitmap executors participate in adaptive
adjustment under the existing switch.
- Does this need documentation: Configuration comments are updated to
describe the shared switch and preserved limits.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
