HuangZL-github commented on issue #10993: URL: https://github.com/apache/seatunnel/issues/10993#issuecomment-4667007243
> 检查了您提供的配置和故障日志后，这看起来更像是资源调度/集群大小问题，而不是新的引擎错误。 > > 关键在于您的集群配置了固定槽位： > > * `dynamic-slot: false` > * 工人`slot-num: 20` > * `job-schedule-strategy: WAIT` > > `PENDING`在这种设置下，即使可用槽位耗尽，新提交的作业预计也会保留在调度器中，因为`WAIT`这意味着调度器会将作业排队而不是拒绝。您提供的堆栈跟踪也是一个特定的作业失败路径（`Timeout expired after 60000ms while awaiting InitProducerId`），而不是调度器本身卡住的直接证据。 > > 为了确定是否存在真正的排程缺陷，请检查以下几点： > > 1. 集群槽位状态（`totalSlot`/ `unassignedSlot`）在作业仍处于待处理状态时的状态 > 2. 所报告的数据`160 tasks`是平台侧计数，还是实际的SeaTunnel运行任务组计数？ > 3. 在内存溢出/重启窗口之后，之前失败的某些作业是否仍然占用着资源槽位。 > > 如果您希望所有这些作业同时运行，那么当前固定槽位容量对于这种工作负载来说非常有限。请先尝试验证集群端的槽位使用情况和调度压力。如果在此期间作业仍然处于挂起状态`unassignedSlot > 0`，请更新此帖，提供主调度日志以及一个挂起作业的 REST 作业信息，以便我们继续检查是否存在真正的调度器错误。 针对生产环境，worker服务器的slot正常一般都设置为CPU核数的2倍，若离线任务确实越来越多的情况下，要么增加现有worker服务器的cpu核数，要么新增worker节点，瓶颈是不是在worker上，而不是master节点上，现在情况是任务越来越多，能执行完，但是执行完的时间越来越长，比如任务少的时候一个任务10s执行完，现在任务多了，相同任务执行完要好几分钟，主要卡在任务已经提交完后面那个阶段。 -- 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]
