ToB企服应用市场:ToB评测及商务社交产业平台

标题: flink 大批量任务提交 yarn 失败问题 [打印本页]
作者: tsx81429    时间: 2024-9-24 10:34
标题: flink 大批量任务提交 yarn 失败问题
问题现象

用户迁移到新集群后,反馈他们开辟平台大量 flink 任务提交失败了,当时集群的 yarn 资源是足够的
排查过程

用户是在他们的开辟平台上提交的,查看他们失败的任务,发现是他们提交端自动 Kill 的,接着沟通发现他们提交平台有个逻辑就是提交到 yarn 的 flink 任务,如果在 2分钟内没有在 yarn 上启动起来,也就是提交的 flink yarn application 没有酿成 running 状态的话,开辟平台会停止这个提交,并判定这个任务的状态为提交失败了.
已知背景如下:
  1. 2022-07-26 17:45:32,355 INFO  org.apache.flink.yarn.AbstractYarnClusterDescriptor           - Submitting application master application_1625727384658_7951
  2. 2022-07-26 17:45:32,577 INFO  org.apache.hadoop.yarn.client.api.impl.YarnClientImpl         - Submitted application application_1625727384658_7951
  3. 2022-07-26 17:45:32,578 INFO  org.apache.flink.yarn.AbstractYarnClusterDescriptor           - Waiting for the cluster to be allocated
  4. 2022-07-26 17:45:32,579 INFO  org.apache.flink.yarn.AbstractYarnClusterDescriptor           - Deploying cluster, current state ACCEPTED
  5. 2022-07-26 17:46:32,801 INFO  org.apache.flink.yarn.AbstractYarnClusterDescriptor           - Deployment took more than 60 seconds. Please check if the requested resources are available in the YARN cluster
  6. 2022-07-26 17:46:33,052 INFO  org.apache.flink.yarn.AbstractYarnClusterDescriptor           
  7. ......
  8. 2022-07-26 17:47:16,655 INFO  org.apache.flink.yarn.AbstractYarnClusterDescriptor           - Deployment took more than 60 seconds. Please check if the requested resources are available in the YARN cluster
  9. 2022-07-26 17:47:16,690 INFO  org.apache.flink.yarn.AbstractYarnClusterDescriptor           - Cancelling deployment from Deployment Failure Hook
复制代码
疑点

把提交平台的 2 分钟判断时间增加到 5分钟是可以或许保证任务成功提交的.
根据 yarn 任务提交流程 ,application 等 master 启动起来后,并向 rm 注册后, application 就从 accepted 状态变为 running 状态了,所以问题是为什么 master 在 2分钟内拉不起了
am 也是一个 container ,一般来说 container 启动过程耗时比较长的资源本地化 localized resource 过程, 从 nm 日志中也确实证实了这一点.
但是资源本地化是一个很简单的操作,如果慢了,问题不会在应用层,一般都是底层网络或者硬件的问题.
于是接着开始转向排查底层操作系统和硬件的问题
分析发现问题节点上的线程数非常多:
ps -efL | grep java | wc -l
有 11 w 个, 当线程数在 5 w 个的时间,是能正常拉起 flink 任务的,这也是旧集群上正常节点上的线程数,但是当提交的任务增加,线程数达到 10 w 以上时,就无法在 2 分钟内拉起提交的 flink 任务.
在问题节点上,发现 ps 执行出现卡顿的现象,从这里排查发现:
因为线程开的太多，导致/proc目录下的子目录过多，导致的遍历这些目录时，getdents 消耗时间过长,只要是会访问/proc目录下的文件，都会因为同样的原因导致处理慢。
于是猜测 flink 提交任务估计也是同样的因素导致拉起超时,接着 使用 strace 工具来跟踪 nodemanager 进程,跟踪启动 am container 的过程:
找到下载jar包的进程/线程pid，然后strace -p pid -f -Ttt 2> strace.log 发现 nm 进程底层会有 /proc 目录的操作.
所以得出结论还是由于起的线程过多,导致proc下的目录过多,引起底层的相关调用变慢,进而导致上层的 java 程序变慢.
但是用户接着提出疑问,新集群 cpu 和内存配置都是旧集群的两倍,为什么支撑不了两倍的 flink 任务提交,并且当时问题节点的 cpu load 并没满
没有其他排查线索了
这时发现问题节点使用的 linux 内核版本是3.10 的,版本比较老,怀疑是内核层面对于多核多线程的处理能力导致的,于是构造环境使用 strace 进行测试,发现确实高版本内核 getdents 调用性能差异巨大


结论

linux 内核版本3.10低版本 对多核数大量线程相关处理缺少优化,导致某些底层系统调用处理性能不高.
升级内核到 4.18 版本即可解决

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4