mrhhsg commented on code in PR #67845:
URL: https://github.com/apache/doris/pull/67845#discussion_r4227070077
##########
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:
Fixed in 35dbc9cf7ce. `revoke_memory_from_other_groups_()` now collects
every workload group that exceeds its min memory limit, sorts them by excess
(largest first) and calls `revoke_memory()` on them in turn until one actually
releases memory; a group whose queries are all too small to be cancelled
returns 0 and the next one is tried. The 128 MiB threshold stops the walk,
since the remaining groups exceed even less. Added
`process_mem_exceeded_below_min_memory_tries_next_peer` with exactly this
two-peer shape (A: ten 30 MiB queries, 200 MiB excess; B: one 250 MiB query,
150 MiB excess): B's query is cancelled, A's queries stay, and the 4 KiB
requestor keeps waiting for the release instead of being cancelled at the hard
limit. The case fails without the fix.
--
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]
