Search before asking
What would you like to be improved?
After updating to Amoro 0.8.0, the production environment's Amoro has many pending tasks, while the optimizer has a lot of idle resources. After investigation, it was found that the optimizer's pollTask sometimes takes a long time to execute. The root cause was traced to an issue with the TableOptimizingProcess.poll() function, likely because it uses the same lock as the commit function, resulting in prolonged wait times before returning. This also affects the execution of the OptimizingQueue.triggerAsyncPlanning function, causing delays in transitioning tasks from pending to planning status.
Here are some trace logs for the TableOptimizingProcess:poll function:
`---ts=2025-05-28 11:04:27.761;thread_name=thrift-server-optimize-manager-20179;id=38456;is_daemon=false;priority=5;TCCL=sun.misc.Launcher$AppClassLoader@764c12b6
`---[15670.296399ms] org.apache.amoro.server.optimizing.OptimizingQueue$TableOptimizingProcess:poll()
+---[100.00% 15670.283697ms ] java.util.concurrent.locks.Lock:lock() #397
+---[0.00% 8.45E-4ms ] java.util.Queue:poll() #400
`---[0.00% 0.006541ms ] java.util.concurrent.locks.Lock:unlock() #403
`---ts=2025-05-28 11:04:27.761;thread_name=thrift-server-optimize-manager-20178;id=38455;is_daemon=false;priority=5;TCCL=sun.misc.Launcher$AppClassLoader@764c12b6
`---[15670.410777ms] org.apache.amoro.server.optimizing.OptimizingQueue$TableOptimizingProcess:poll()
+---[100.00% 15670.395864ms ] java.util.concurrent.locks.Lock:lock() #397
+---[0.00% 8.2E-4ms ] java.util.Queue:poll() #400
`---[0.00% 0.008124ms ] java.util.concurrent.locks.Lock:unlock() #403
`---ts=2025-05-28 11:04:27.765;thread_name=thrift-server-optimize-manager-20182;id=38460;is_daemon=false;priority=5;TCCL=sun.misc.Launcher$AppClassLoader@764c12b6
`---[15666.547514ms] org.apache.amoro.server.optimizing.OptimizingQueue$TableOptimizingProcess:poll()
+---[100.00% 15666.536295ms ] java.util.concurrent.locks.Lock:lock() #397
+---[0.00% 7.27E-4ms ] java.util.Queue:poll() #400
`---[0.00% 0.005393ms ] java.util.concurrent.locks.Lock:unlock() #403
How should we improve?
Optimize the implementation of the TableOptimizingProcess.poll() function to avoid waiting for locks and return immediately if the lock cannot be acquired.
Are you willing to submit PR?
Subtasks
No response
Code of Conduct
Search before asking
What would you like to be improved?
After updating to Amoro 0.8.0, the production environment's Amoro has many pending tasks, while the optimizer has a lot of idle resources. After investigation, it was found that the optimizer's pollTask sometimes takes a long time to execute. The root cause was traced to an issue with the TableOptimizingProcess.poll() function, likely because it uses the same lock as the commit function, resulting in prolonged wait times before returning. This also affects the execution of the OptimizingQueue.triggerAsyncPlanning function, causing delays in transitioning tasks from pending to planning status.
Here are some trace logs for the TableOptimizingProcess:poll function:
How should we improve?
Optimize the implementation of the TableOptimizingProcess.poll() function to avoid waiting for locks and return immediately if the lock cannot be acquired.
Are you willing to submit PR?
Subtasks
No response
Code of Conduct