xy720 opened a new pull request, #55753:
URL: https://github.com/apache/doris/pull/55753
### What problem does this PR solve?
I found when there are large amount of garbage(about 90000 partitions) in
recycle bin, the Fe's table lock will be hold for long time by
DynamicPartitionScheduler thread, the stack is like:
```
"recycle bin" #28 daemon prio=5 os_prio=0 cpu=73880509.81ms
elapsed=96569.50s allocated=9212M defined_classes=9 tid=0x00007f0b545c1800
nid=0x2f4540 runnable [0x00007f0b251fd000]
java.lang.Thread.State: RUNNABLE
at
org.apache.doris.catalog.CatalogRecycleBin.getSameNamePartitionIdListToErase(CatalogRecycleBin.java:539)
- locked <0x000000020d6d6130> (a
org.apache.doris.catalog.CatalogRecycleBin)
at
org.apache.doris.catalog.CatalogRecycleBin.erasePartitionWithSameName(CatalogRecycleBin.java:556)
- locked <0x000000020d6d6130> (a
org.apache.doris.catalog.CatalogRecycleBin)
at
org.apache.doris.catalog.CatalogRecycleBin.erasePartition(CatalogRecycleBin.java:510)
- locked <0x000000020d6d6130> (a
org.apache.doris.catalog.CatalogRecycleBin)
at
org.apache.doris.catalog.CatalogRecycleBin.runAfterCatalogReady(CatalogRecycleBin.java:1012)
at
org.apache.doris.common.util.MasterDaemon.runOneCycle(MasterDaemon.java:58)
at org.apache.doris.common.util.Daemon.run(Daemon.java:119)
Locked ownable synchronizers:
- None
"DynamicPartitionScheduler" #41 daemon prio=5 os_prio=0 cpu=115405.50ms
elapsed=87942.53s allocated=16637M defined_classes=96 tid=0x00007f0b545cc800
nid=0x2f4545 waiting for monitor entry [0x00007f0b247fe000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.doris.catalog.CatalogRecycleBin.recyclePartition(CatalogRecycleBin.java:187)
- waiting to lock <0x000000020d6d6130> (a
org.apache.doris.catalog.CatalogRecycleBin)
at
org.apache.doris.catalog.OlapTable.dropPartition(OlapTable.java:1164)
at
org.apache.doris.catalog.OlapTable.dropPartition(OlapTable.java:1207)
at
org.apache.doris.datasource.InternalCatalog.dropPartitionWithoutCheck(InternalCatalog.java:1895)
at
org.apache.doris.datasource.InternalCatalog.dropPartition(InternalCatalog.java:1884)
at org.apache.doris.catalog.Env.dropPartition(Env.java:3212)
at
org.apache.doris.clone.DynamicPartitionScheduler.executeDynamicPartition(DynamicPartitionScheduler.java:605)
at
org.apache.doris.clone.DynamicPartitionScheduler.runAfterCatalogReady(DynamicPartitionScheduler.java:729)
at
org.apache.doris.common.util.MasterDaemon.runOneCycle(MasterDaemon.java:58)
at
org.apache.doris.clone.DynamicPartitionScheduler.run(DynamicPartitionScheduler.java:688)
```
The DynamicPartitionScheduler thread is waiting the CatalogRecycleBin thread
while it is holding the table write lock.
In Fe log, you can see the CatalogRecycleBin thread is running something big
and cost almost 5~10 mins every run:
```
fe.log.20250907-2:2025-09-07 04:15:50,740 INFO (recycle bin|28)
[CatalogRecycleBin.erasePartition():516] erasePartition eraseNum: 0 cost:
375503ms
fe.log.20250907-2:2025-09-07 04:23:14,109 INFO (recycle bin|28)
[CatalogRecycleBin.erasePartition():516] erasePartition eraseNum: 0 cost:
413369ms
fe.log.20250907-2:2025-09-07 04:30:01,187 INFO (recycle bin|28)
[CatalogRecycleBin.erasePartition():516] erasePartition eraseNum: 0 cost:
377077ms
fe.log.20250907-2:2025-09-07 04:38:22,769 INFO (recycle bin|28)
[CatalogRecycleBin.erasePartition():516] erasePartition eraseNum: 0 cost:
471581ms
fe.log.20250907-2:2025-09-07 04:45:42,552 INFO (recycle bin|28)
[CatalogRecycleBin.erasePartition():516] erasePartition eraseNum: 0 cost:
409782ms
fe.log.20250907-2:2025-09-07 04:54:30,825 INFO (recycle bin|28)
[CatalogRecycleBin.erasePartition():516] erasePartition eraseNum: 0 cost:
498272ms
fe.log.20250907-2:2025-09-07 05:01:36,311 INFO (recycle bin|28)
[CatalogRecycleBin.erasePartition():516] erasePartition eraseNum: 0 cost:
395485ms
```
This may leads to whole Fe hang because the table lock is used for many
threads.
<img width="1230" height="438" alt="Clipboard_Screenshot_1757283600"
src="https://github.com/user-attachments/assets/59ec8707-82f8-4daf-8dae-b9ebea2b2959";
/>
This commit mainly optimize the logic of recycling the same name meta,
adding caches to reduce the time complexity.
### Release note
None
### Check List (For Author)
- Test <!-- At least one of them must be included. -->
- [ ] Regression test
- [ ] Unit Test
- [ ] Manual test (add detailed scripts or steps below)
- [ ] No need to test or manual test. Explain why:
- [ ] This is a refactor/code format and no logic has been changed.
- [ ] Previous test can cover this change.
- [ ] No code files have been changed.
- [ ] Other reason <!-- Add your reason? -->
- Behavior changed:
- [x] No.
- [ ] Yes. <!-- Explain the behavior change -->
- Does this need documentation?
- [ ] No.
- [ ] Yes. <!-- Add document PR link here. eg:
https://github.com/apache/doris-website/pull/1214 -->
### Check List (For Reviewer who merge this PR)
- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label <!-- Add branch pick label that this PR should
merge into -->
--
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]
