Uh oh!
There was an error while loading. Please reload this page.
[Opt](cloud-mow) Mow load can force take MS lock - #53086
Conversation
Thearas
commented
Jul 11, 2025
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
2896b84 to
4bb4bf2Comparebobhan1
commented
Jul 16, 2025
run buildall |
doris-robot
commented
Jul 16, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
doris-robot
commented
Jul 16, 2025
TPC-H: Total hot run time: 33943 ms |
doris-robot
commented
Jul 16, 2025
TPC-DS: Total hot run time: 188765 ms |
doris-robot
commented
Jul 16, 2025
ClickBench: Total hot run time: 32.41 s |
doris-robot
commented
Jul 16, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
bobhan1
commented
Jul 16, 2025
run buildall |
hello-stephen
commented
Jul 16, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Jul 16, 2025
FE UT Coverage ReportIncrement line coverage |
doris-robot
commented
Jul 16, 2025
TPC-H: Total hot run time: 34239 ms |
doris-robot
commented
Jul 16, 2025
TPC-DS: Total hot run time: 187357 ms |
doris-robot
commented
Jul 16, 2025
ClickBench: Total hot run time: 33.13 s |
doris-robot
commented
Jul 16, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
| std::string key1 = mow_tablet_job_key({instance_id, table_id + 1, 0}); | ||
| MowTabletJobPB mow_tablet_job; | ||
| std::unique_ptr<RangeGetIterator> it; | ||
| int64_t job_key_num = 0; |
There was a problem hiding this comment.
+1, why not remove by range?
doris-robot
commented
Jul 17, 2025
ClickBench: Total hot run time: 33.28 s |
doris-robot
commented
Jul 17, 2025
BE 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. |
bobhan1
commented
Jul 18, 2025
run buildall |
doris-robot
commented
Jul 18, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
hello-stephen
commented
Jul 18, 2025
FE UT Coverage ReportIncrement line coverage |
doris-robot
commented
Jul 18, 2025
TPC-H: Total hot run time: 34448 ms |
doris-robot
commented
Jul 18, 2025
TPC-DS: Total hot run time: 190388 ms |
doris-robot
commented
Jul 18, 2025
ClickBench: Total hot run time: 33.83 s |
doris-robot
commented
Jul 18, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
bobhan1
commented
Jul 18, 2025
run p0 |
bobhan1
commented
Jul 18, 2025
run external |
### What problem does this PR solve? This PR: 1. changes the mow load's backoff sleep time when get MS lock. 2. Let mow load force take MS lock after the waiting time exceeds a configurable threshold to reduce the load latency tail. ### Test 1: cloud mode, 1 FE, 3 BE(8C 32GB), 5 threads, 120 buckets, 50rows/per load, cumu threads=8 with conf mow_load_force_take_ms_lock_threshold_ms=500 |before|after| |-----------------|-----------------| ||| || | || | ||| ### Test 2: cloud mode, 1 FE, 3 BE(8C 32GB), 1 threads, 120 buckets, 50rows/per load, cumu threads=8 with conf mow_load_force_take_ms_lock_threshold_ms=50 |before|after| |-----------------|-----------------| ||| ||| Note that the txn latency long tail is due to put object during flush phase.
…66082) Related PR: #53086 Problem Summary: Urgent MOW load lock requests currently replace any existing delete bitmap update lock after the force-take threshold. If a heavy schema change owns the lock, the load can invalidate the schema change and make its later commit fail. This change keeps active schema change locks protected in both v1 and v2 lock implementations. Urgent loads continue to preempt compaction and load locks, and stale schema change locks still follow the existing expiration cleanup path. The unit-test matrix directly verifies persisted lock ownership and v2 job-key cleanup for active schema change, expired schema change, compaction, and ordinary load owners. An isolated cloud Docker case pauses schema change after lock acquisition, limits the urgent load to two immediate lock attempts, and verifies that the load fails with the lock conflict while schema change retains ownership. ### Release note Urgent MOW loads no longer preempt active schema change delete bitmap locks.
…66082) Related PR: #53086 Problem Summary: Urgent MOW load lock requests currently replace any existing delete bitmap update lock after the force-take threshold. If a heavy schema change owns the lock, the load can invalidate the schema change and make its later commit fail. This change keeps active schema change locks protected in both v1 and v2 lock implementations. Urgent loads continue to preempt compaction and load locks, and stale schema change locks still follow the existing expiration cleanup path. The unit-test matrix directly verifies persisted lock ownership and v2 job-key cleanup for active schema change, expired schema change, compaction, and ordinary load owners. An isolated cloud Docker case pauses schema change after lock acquisition, limits the urgent load to two immediate lock attempts, and verifies that the load fails with the lock conflict while schema change retains ownership. ### Release note Urgent MOW loads no longer preempt active schema change delete bitmap locks.
…66082) Related PR: #53086 Problem Summary: Urgent MOW load lock requests currently replace any existing delete bitmap update lock after the force-take threshold. If a heavy schema change owns the lock, the load can invalidate the schema change and make its later commit fail. This change keeps active schema change locks protected in both v1 and v2 lock implementations. Urgent loads continue to preempt compaction and load locks, and stale schema change locks still follow the existing expiration cleanup path. The unit-test matrix directly verifies persisted lock ownership and v2 job-key cleanup for active schema change, expired schema change, compaction, and ordinary load owners. An isolated cloud Docker case pauses schema change after lock acquisition, limits the urgent load to two immediate lock attempts, and verifies that the load fails with the lock conflict while schema change retains ownership. ### Release note Urgent MOW loads no longer preempt active schema change delete bitmap locks.
…pache#66082) Related PR: apache#53086 Problem Summary: Urgent MOW load lock requests currently replace any existing delete bitmap update lock after the force-take threshold. If a heavy schema change owns the lock, the load can invalidate the schema change and make its later commit fail. This change keeps active schema change locks protected in both v1 and v2 lock implementations. Urgent loads continue to preempt compaction and load locks, and stale schema change locks still follow the existing expiration cleanup path. The unit-test matrix directly verifies persisted lock ownership and v2 job-key cleanup for active schema change, expired schema change, compaction, and ordinary load owners. An isolated cloud Docker case pauses schema change after lock acquisition, limits the urgent load to two immediate lock attempts, and verifies that the load fails with the lock conflict while schema change retains ownership. ### Release note Urgent MOW loads no longer preempt active schema change delete bitmap locks.
What problem does this PR solve?
This PR:
Test 1: cloud mode, 1 FE, 3 BE(8C 32GB), 5 threads, 120 buckets, 50rows/per load, cumu threads=8
with conf mow_load_force_take_ms_lock_threshold_ms=500
Test 2: cloud mode, 1 FE, 3 BE(8C 32GB), 1 threads, 120 buckets, 50rows/per load, cumu threads=8
with conf mow_load_force_take_ms_lock_threshold_ms=50
Note that the txn latency long tail is due to put object during flush phase.
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)