github-actions[bot] commented on code in PR #66088:
URL: https://github.com/apache/doris/pull/66088#discussion_r3655243894
##########
be/src/exec/scan/scanner_scheduler.cpp:
##########
@@ -397,7 +397,7 @@ int ScannerScheduler::get_remote_scan_thread_queue_size() {
int ScannerScheduler::default_min_active_scan_threads() {
return config::min_active_scan_threads > 0
? config::min_active_scan_threads
- : config::min_active_scan_threads = CpuInfo::num_cores() *
2;
+ : config::min_active_scan_threads =
default_local_scan_thread_num();
Review Comment:
[P2] Tie the implicit target to the workload-group pool size
Workload groups may set `scan_thread_num` to a small value (even 1), and BE
creates/resizes that scheduler with the custom value as its actual min/max
thread count, but it still passes this process-wide fallback as
`_min_active_scan_threads`. On a four-core host the change raises that fallback
from 8 to 48; because `_get_margin()` fills active-plus-queued work toward it,
enough contexts in a one-thread group can accumulate roughly 48 scan tasks.
That creates an unnecessary backlog (and on the supported FIFO backend can put
later query work behind it) despite the group's explicit capacity. Please
derive or clamp the unset fallback from the scheduler instance's actual
capacity on create/reset, while still honoring an explicit configured override,
and test a small initial pool plus a downsize.
--
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]
