xy720 opened a new pull request, #68038:
URL: https://github.com/apache/doris/pull/68038

   ### What problem does this PR solve?
   
   We found that when the number of mtmv in the cluster reaches a large number 
(e.g. 80,000+) , the restart of fe becomes very slow.
   
   The jstack of a fe that is currently being transfer to master is captured as 
follows:
   
   <img width="1167" height="425" alt="Clipboard_Screenshot_1789501873" 
src="https://github.com/user-attachments/assets/46c94f74-8397-48c5-9124-c7941fad3fe1";
 />
   
   And there are amount of FE logs like this:
   
   ```
   2026-09-14 21:27:12,249 INFO (leaderCheckpointer|33718) 
[MTMVRelationManager.refreshMTMVCache():174] refreshMTMVCache,relation: 
org.apache.doris.mtmv.MTMVRelation@200613dd, mtmvInfo: 
BaseTableInfo{tableName='xxx', dbName='xxx', ctlName='internal'}
   2026-09-14 21:27:12,268 INFO (leaderCheckpointer|33718) 
[MTMVService.unregisterMTMV():88] deregisterMTMV: xxx
   2026-09-14 21:27:12,286 INFO (leaderCheckpointer|33718) 
[MTMVService.registerMTMV():80] registerMTMV: xxx
   2026-09-14 21:27:12,286 INFO (leaderCheckpointer|33718) 
[MTMVRelationManager.refreshMTMVCache():174] refreshMTMVCache,relation: 
org.apache.doris.mtmv.MTMVRelation@200613dd, mtmvInfo: 
BaseTableInfo{tableName='xxx', dbName='xxx', ctlName='internal'}
   2026-09-14 21:27:12,304 INFO (leaderCheckpointer|33718) 
[MTMVService.refreshComplete():144] refreshComplete: xxx
   ```
   
   or
   
   ```
   2026-09-14 21:11:04,926 INFO (leaderCheckpointer|33718) [Env.loadDb():2407] 
start loading db from image
   2026-09-14 21:11:04,967 INFO (leaderCheckpointer|33718) 
[MTMVService.registerMTMV():80] registerMTMV: xxx
   2026-09-14 21:11:04,967 INFO (leaderCheckpointer|33718) 
[MTMVRelationManager.refreshMTMVCache():174] refreshMTMVCache,relation: 
org.apache.doris.mtmv.MTMVRelation@510324a6, mtmvInfo: 
BaseTableInfo{tableName='xxx', dbName='xxx', ctlName='internal'}
   ```
   
   Each invocation of the `registerMTMV()` function takes about 20ms, the 
`Env.loadDb()` and `ENV.postProcessAfterMetadataReplayed()` methods of the 
checkpoint thread invoke the `registerMTMV()` function once for each mv,and the 
`transferToMaster()` will also invoke the `registerMTMV()` function once for 
each mv.
   
   Therefore, the total time of transfering to master + restarting fe with 
80000+ mtmv is 4800+s(about 1.5h)
   
   This commit:
   1、Skip doing `registerMTMV()` in MTMV compatible when there is nothing was 
actually migrated.
   2、Add reverse index reduce the time complex of `registerMTMV()` from O(N^2) 
to O(k) in the mtmv's own base count
   
   
   
   Problem Summary:
   
   ### Release note
   
   None
   
   ### Check List (For Author)
   
   - Test <!-- At least one of them must be included. -->
       - [ ] Regression test
       - [x] 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?
       - [x] 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]

Reply via email to