Uh oh!
There was an error while loading. Please reload this page.
[enhance](memtable) skip memtable in queue to speed up cancel - #53481
Conversation
hello-stephen
commented
Jul 17, 2025
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
sollhui
commented
Jul 17, 2025
run buildall |
doris-robot
commented
Jul 17, 2025
TPC-H: Total hot run time: 33775 ms |
doris-robot
commented
Jul 17, 2025
TPC-DS: Total hot run time: 187078 ms |
doris-robot
commented
Jul 17, 2025
ClickBench: Total hot run time: 32.52 s |
hello-stephen
commented
Jul 17, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Jul 17, 2025
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
sollhui
commented
Jul 18, 2025
run buildall |
doris-robot
commented
Jul 18, 2025
TPC-H: Total hot run time: 34429 ms |
doris-robot
commented
Jul 18, 2025
TPC-DS: Total hot run time: 190132 ms |
doris-robot
commented
Jul 18, 2025
ClickBench: Total hot run time: 32.67 s |
sollhui
commented
Jul 18, 2025
run buildall |
doris-robot
commented
Jul 18, 2025
TPC-H: Total hot run time: 34378 ms |
doris-robot
commented
Jul 18, 2025
TPC-DS: Total hot run time: 189841 ms |
doris-robot
commented
Jul 18, 2025
ClickBench: Total hot run time: 33.11 s |
doris-robot
commented
Jul 18, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Jul 18, 2025
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
sollhui
commented
Jul 20, 2025
run buildall |
sollhui
commented
Jul 20, 2025
run buildall |
doris-robot
commented
Jul 20, 2025
TPC-H: Total hot run time: 34503 ms |
doris-robot
commented
Jul 20, 2025
TPC-DS: Total hot run time: 191023 ms |
doris-robot
commented
Jul 20, 2025
ClickBench: Total hot run time: 32.82 s |
doris-robot
commented
Jul 20, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Jul 20, 2025
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Jul 21, 2025
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Jul 21, 2025
BE Regression && UT Coverage ReportIncrement line coverage Increment coverage report
|
PR approved by at least one committer and no changes requested. |
PR approved by anyone and no changes requested. |
…#53481) At present, if load/update/delete is cancelled, it needs to wait for all submitted memtable task of related `FlushToken` to be completed, included: - flush task wait in thread pool queue - ongoing flushing task It is not need wait flush task still in the thread pool queue which can speed up cancel load/update/delete. <img width="1686" height="660" alt="image" src="https://github.com/user-attachments/assets/8eb8f43c-10d9-4b95-8933-d341f12857ce" /> For example, cancel load1. The current logic is to wait for all submit task(queue+flushing), but for those in the queue, they have to wait for all the previously queued ones to complete before it's their turn. Skip memtable in queue can speed up cancel for: - If there are still memtables for load2 and load3 in front of load1 memtable, cancel block until other load memtable been flushed. - Under more extreme conditions, the submit task count may add when wait submit task finish.
## Problem When a queued memtable flush task starts after `FlushToken::cancel()` has already marked the token shutdown, `_flush_memtable()` can return before the old `flush_running_count++` path but still run the deferred `flush_running_count--`. This can drive the counter below zero and make `cancel()` wait forever for `flush_running_count == 0`. Related PR: #53481 ## Fix Move `flush_running_count++` to the top of `_flush_memtable()` before registering the deferred cleanup so the running-count accounting stays symmetric on every exit path. ## Validation - Reasoned from production stack and gdb evidence showing `flush_running_count = -1` while cancel was blocked in `_wait_running_task_finish()` - Not run locally: the BE UT environment in this workspace would require a full initial `ut_build_ASAN` build
## Problem When a queued memtable flush task starts after `FlushToken::cancel()` has already marked the token shutdown, `_flush_memtable()` can return before the old `flush_running_count++` path but still run the deferred `flush_running_count--`. This can drive the counter below zero and make `cancel()` wait forever for `flush_running_count == 0`. Related PR: #53481 ## Fix Move `flush_running_count++` to the top of `_flush_memtable()` before registering the deferred cleanup so the running-count accounting stays symmetric on every exit path. ## Validation - Reasoned from production stack and gdb evidence showing `flush_running_count = -1` while cancel was blocked in `_wait_running_task_finish()` - Not run locally: the BE UT environment in this workspace would require a full initial `ut_build_ASAN` build
## Problem When a queued memtable flush task starts after `FlushToken::cancel()` has already marked the token shutdown, `_flush_memtable()` can return before the old `flush_running_count++` path but still run the deferred `flush_running_count--`. This can drive the counter below zero and make `cancel()` wait forever for `flush_running_count == 0`. Related PR: #53481 ## Fix Move `flush_running_count++` to the top of `_flush_memtable()` before registering the deferred cleanup so the running-count accounting stays symmetric on every exit path. ## Validation - Reasoned from production stack and gdb evidence showing `flush_running_count = -1` while cancel was blocked in `_wait_running_task_finish()` - Not run locally: the BE UT environment in this workspace would require a full initial `ut_build_ASAN` build
…1684) ## Problem When a queued memtable flush task starts after `FlushToken::cancel()` has already marked the token shutdown, `_flush_memtable()` can return before the old `flush_running_count++` path but still run the deferred `flush_running_count--`. This can drive the counter below zero and make `cancel()` wait forever for `flush_running_count == 0`. Related PR: apache#53481 ## Fix Move `flush_running_count++` to the top of `_flush_memtable()` before registering the deferred cleanup so the running-count accounting stays symmetric on every exit path. ## Validation - Reasoned from production stack and gdb evidence showing `flush_running_count = -1` while cancel was blocked in `_wait_running_task_finish()` - Not run locally: the BE UT environment in this workspace would require a full initial `ut_build_ASAN` build
What problem does this PR solve?
At present, if load/update/delete is cancelled, it needs to wait for all submitted memtable task of related
FlushTokento be completed, included:It is not need wait flush task still in the thread pool queue which can speed up cancel load/update/delete.
Specific Example
If there are still memtables for load2 and load3 in front of load1 memtable, cancel block until other load memtable been flushed.
Under more extreme conditions, the submit task count may add when wait submit task finish.
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)