Skip to content

Optimize the performance of optimizer pollTask#3583

Merged
xxubai merged 2 commits intoapache:masterfrom
lintingbin:improvement_pollTask_performance
May 29, 2025
Merged

Optimize the performance of optimizer pollTask#3583
xxubai merged 2 commits intoapache:masterfrom
lintingbin:improvement_pollTask_performance

Conversation

@lintingbin
Copy link
Contributor

Why are the changes needed?

Close #3582.

Brief change log

  • Optimize the implementation of the TableOptimizingProcess.poll() function to avoid waiting for locks and return immediately if the lock cannot be acquired.

How was this patch tested?

  • Add some test cases that check the changes thoroughly including negative and positive cases if possible

  • Add screenshots for manual tests if appropriate

  • Run test locally before making a pull request

Documentation

  • Does this pull request introduce a new feature? no
  • If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

…tion to avoid waiting for locks and return immediately if the lock cannot be acquired.
@github-actions github-actions bot added the module:ams-server Ams server module label May 29, 2025
Copy link
Contributor

@czy006 czy006 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your contribution,Suggestion add 0.8.1 release fix it

@codecov-commenter
Copy link

Codecov Report

Attention: Patch coverage is 40.00000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 28.26%. Comparing base (58c6013) to head (8557e41).
Report is 2 commits behind head on master.

Files with missing lines Patch % Lines
...pache/amoro/server/optimizing/OptimizingQueue.java 40.00% 1 Missing and 2 partials ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##             master    #3583      +/-   ##
============================================
+ Coverage     21.76%   28.26%   +6.50%     
- Complexity     2391     3702    +1311     
============================================
  Files           431      614     +183     
  Lines         40501    49766    +9265     
  Branches       5745     6434     +689     
============================================
+ Hits           8816    14068    +5252     
- Misses        30938    34690    +3752     
- Partials        747     1008     +261     
Flag Coverage Δ
core 28.26% <40.00%> (?)
trino ?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@xxubai xxubai merged commit 31b064c into apache:master May 29, 2025
6 checks passed
@zhoujinsong
Copy link
Contributor

Hi, I am not sure if this is the right path to fix this issue.

Do we find which process got the process lock? @lintingbin @xxubai

@xxubai
Copy link
Contributor

xxubai commented Jun 6, 2025

Do we find which process got the process lock? @lintingbin @xxubai

Not yet. I have deployed the release 0.8.0-incubating in our non-production environment and so far have not encountered similar issues.

@lintingbin
Copy link
Contributor Author

@lintingbin @xxubai It seems that the committing phase is locked. Before we optimized the clients parameter, there were many queues in the committing phase.
9f1125b772902bdb1f9a77d4ad7bd65d

@zhoujinsong
Copy link
Contributor

The committing tables will get the process lock and block the poll task process because it is not removed from the tableQueue.

It should be improved, but it is not a new issue for 0.8.0

@lintingbin
Copy link
Contributor Author

The committing tables will get the process lock and block the poll task process because it is not removed from the tableQueue.

It should be improved, but it is not a new issue for 0.8.0

👌

@Jzjsnow Jzjsnow mentioned this pull request Aug 11, 2025
52 tasks
Jzjsnow pushed a commit to Jzjsnow/amoro that referenced this pull request Aug 20, 2025
Optimize the implementation of the TableOptimizingProcess.poll() function to avoid waiting for locks and return immediately if the lock cannot be acquired.

Co-authored-by: Xu Bai <xuba@apache.org>

Resolve conflicts in
src/main/java/org/apache/amoro/server/optimizing/OptimizingQueue.java
(cherry picked from commit 31b064c)
@Jzjsnow Jzjsnow mentioned this pull request Aug 20, 2025
3 tasks
zhoujinsong pushed a commit that referenced this pull request Aug 25, 2025
Optimize the implementation of the TableOptimizingProcess.poll() function to avoid waiting for locks and return immediately if the lock cannot be acquired.

Co-authored-by: Xu Bai <xuba@apache.org>

Resolve conflicts in
src/main/java/org/apache/amoro/server/optimizing/OptimizingQueue.java
(cherry picked from commit 31b064c)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

module:ams-server Ams server module

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Improvement]: Optimize the performance of optimizer pollTask

5 participants