github-actions[bot] commented on code in PR #67845:
URL: https://github.com/apache/doris/pull/67845#discussion_r4226925776
##########
be/src/runtime/workload_group/workload_group_manager.cpp:
##########
@@ -694,16 +715,16 @@ int64_t
WorkloadGroupMgr::revoke_memory_from_other_groups_() {
<< " less than 128MB, no need to revoke memory";
return 0;
}
- int64_t freed_mem = static_cast<int64_t>((double)max_exceeded_memory *
0.1);
+ auto need_free_mem = static_cast<int64_t>((double)max_exceeded_memory *
0.1);
// Revoke 10% of memory from the workload group that exceed most memory
- max_wg->revoke_memory(freed_mem, "exceed_memory", profile.get());
+ int64_t freed_mem = max_wg->revoke_memory(need_free_mem, "exceed_memory",
profile.get());
Review Comment:
[P1] Try other over-minimum groups before cancelling the requestor
This now uses the actual zero result from only the most overcommitted group
to trigger the requestor's hard-limit/timeout fallback. With 100 MiB minima,
peer A can have 300 MiB in ten 30 MiB queries (200 MiB excess, all filtered by
`EXCLUDE_IS_SMALL`), while peer B has 250 MiB in one cancellable query (150 MiB
excess). A is always selected and returns zero; B is never tried, so a
below-minimum 4 KiB requestor is cancelled at the hard limit without reclaiming
B's 250 MiB. This is the two-peer case left by the existing single-peer
zero-result fix. Try the other over-minimum groups before falling back, and
cover this case in a test.
--
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]
