troubleshooting yarn-client模式导致的网卡流量激增问题
2016-10-30 00:00
295 查看
很多公司都是通过Yarn来进行调度,mapreduce on yarn、spark on yarn、甚至storm on yarn。
Yarn集群分成两种节点:
ResourceManager负责资源的调度;
NodeManager负责资源的分配、应用程序执行这些东西。
通过Spark-submit脚本来提交,用yarn-client提交模式,这种模式其实会在本地启动起来driver程序
Spark on yarn执行流程
我们写的spark程序,打成jar包,用spark-submit来提交。jar包中的一个main类,通过jvm的命令启动起来。JVM进程,这个进程,其实就是咱们的Driver进程。Driver进程启动起来以后,执行我们自己写的main函数,从new SparkContext()。。。
在客户端给我们启动一个driver
去ResourceManager申请启动container(资源)
通知一个NodeManager在container里面启动ApplicationMaster
ApplicationMaster去找ResourceManager申请Executor
ResourceManager返回可以启动的NodeManager的地址
ApplicationMaster去找NodeManager启动Executor
Executor进程会反过来去向Driver注册上去
最后Driver接收到了Executor资源之后就可以去进行我们spark代码的执行了
执行到某个action就触发一个JOB
DAGScheduler会划分JOB为一个个Stage
TaskScheduler会划分Stage为一个个Task
Task发送到Executor执行
Driver就来进行Task的调度
Application-Master???
yarn中的核心概念,任何要在yarn上启动的作业类型(mr、spark),都必须有一个。每种计算框架(mr、spark),如果想要在yarn上执行自己的计算应用,那么就必须自己实现和提供一个ApplicationMaster相当于是实现了yarn提供的接口,spark自己开发的一个类
spark在yarn-client模式下,application的注册(executor的申请)和计算task的调度,是分离开来的。standalone模式下,这两个操作都是driver负责的。
ApplicationMaster(ExecutorLauncher)负责executor的申请;driver负责job和stage的划分,以及task的创建、分配和调度
yarn-client模式下,会产生什么样的问题呢?
由于咱们的driver是启动在本地机器的,而且driver是全权负责所有的任务的调度的,也就是说要跟yarn集群上运行的多个executor进行频繁的通信(中间有task的启动消息、task的执行统计消息、task的运行状态、shuffle的输出结果)。
咱们来想象一下。比如你的executor有100个,stage有10个,task有1000个。每个stage运行的时候,都有1000个task提交到executor上面去运行,平均每个executor有10个task。接下来问题来了,driver要频繁地跟executor上运行的1000个task进行通信。通信消息特别多,通信的频率特别高。运行完一个stage,接着运行下一个stage,又是频繁的通信。
在整个spark运行的生命周期内,都会频繁的去进行通信和调度。所有这一切通信和调度都是从你的本地机器上发出去的,和接收到的。这是最要人命的地方。你的本地机器,很可能在30分钟内(spark作业运行的周期内),进行频繁大量的网络通信。那么此时,你的本地机器的网络通信负载是非常非常高的。会导致你的本地机器的网卡流量会激增!!!
你的本地机器的网卡流量激增,当然不是一件好事了。因为在一些大的公司里面,对每台机器的使用情况,都是有监控的。不会允许单个机器出现耗费大量网络带宽等等这种资源的情况。运维人员不会允许。可能对公司的网络,或者其他(你的机器还是一台虚拟机),如果你是一台虚拟机的话,和其他机器共享网卡的话,可能对其他机器,公司整个网络环境,都会有负面和恶劣的影响。
解决的方法:
实际上解决的方法很简单,就是心里要清楚,yarn-client模式是什么情况下,可以使用的?
yarn-client模式,通常咱们就只会使用在测试环境中,你写好了某个spark作业,打了一个jar包,在某台测试机器上,用yarn-client模式去提交一下。因为测试的行为是偶尔为之的,不会长时间连续提交大量的spark作业去测试。还有一点好处,yarn-client模式提交,可以在本地机器观察到详细全面的log。通过查看log,可以去解决线上报错的故障(troubleshooting)、对性能进行观察并进行性能调优。
实际上线了以后,在生产环境中,都得用yarn-cluster模式,去提交你的spark作业。
yarn-cluster模式,就跟你的本地机器引起的网卡流量激增的问题,就没有关系了。也就是说,就算有问题,也应该是yarn运维团队和基础运维团队之间的事情了。他们去考虑Yarn集群里面每台机器是虚拟机还是物理机呢?网卡流量激增后会不会对其他东西产生影响呢?如果网络流量激增,要不要给Yarn集群增加一些网络带宽等等这些东西。那就是他们俩个团队的事情了,和你就没有关系了
使用了yarn-cluster模式以后,
就不是你的本地机器运行Driver,进行task调度了。是yarn集群中,某个节点会运行driver进程,负责task调度。
Yarn集群分成两种节点:
ResourceManager负责资源的调度;
NodeManager负责资源的分配、应用程序执行这些东西。
通过Spark-submit脚本来提交,用yarn-client提交模式,这种模式其实会在本地启动起来driver程序
Spark on yarn执行流程
我们写的spark程序,打成jar包,用spark-submit来提交。jar包中的一个main类,通过jvm的命令启动起来。JVM进程,这个进程,其实就是咱们的Driver进程。Driver进程启动起来以后,执行我们自己写的main函数,从new SparkContext()。。。
在客户端给我们启动一个driver
去ResourceManager申请启动container(资源)
通知一个NodeManager在container里面启动ApplicationMaster
ApplicationMaster去找ResourceManager申请Executor
ResourceManager返回可以启动的NodeManager的地址
ApplicationMaster去找NodeManager启动Executor
Executor进程会反过来去向Driver注册上去
最后Driver接收到了Executor资源之后就可以去进行我们spark代码的执行了
执行到某个action就触发一个JOB
DAGScheduler会划分JOB为一个个Stage
TaskScheduler会划分Stage为一个个Task
Task发送到Executor执行
Driver就来进行Task的调度
Application-Master???
yarn中的核心概念,任何要在yarn上启动的作业类型(mr、spark),都必须有一个。每种计算框架(mr、spark),如果想要在yarn上执行自己的计算应用,那么就必须自己实现和提供一个ApplicationMaster相当于是实现了yarn提供的接口,spark自己开发的一个类
spark在yarn-client模式下,application的注册(executor的申请)和计算task的调度,是分离开来的。standalone模式下,这两个操作都是driver负责的。
ApplicationMaster(ExecutorLauncher)负责executor的申请;driver负责job和stage的划分,以及task的创建、分配和调度
yarn-client模式下,会产生什么样的问题呢?
由于咱们的driver是启动在本地机器的,而且driver是全权负责所有的任务的调度的,也就是说要跟yarn集群上运行的多个executor进行频繁的通信(中间有task的启动消息、task的执行统计消息、task的运行状态、shuffle的输出结果)。
咱们来想象一下。比如你的executor有100个,stage有10个,task有1000个。每个stage运行的时候,都有1000个task提交到executor上面去运行,平均每个executor有10个task。接下来问题来了,driver要频繁地跟executor上运行的1000个task进行通信。通信消息特别多,通信的频率特别高。运行完一个stage,接着运行下一个stage,又是频繁的通信。
在整个spark运行的生命周期内,都会频繁的去进行通信和调度。所有这一切通信和调度都是从你的本地机器上发出去的,和接收到的。这是最要人命的地方。你的本地机器,很可能在30分钟内(spark作业运行的周期内),进行频繁大量的网络通信。那么此时,你的本地机器的网络通信负载是非常非常高的。会导致你的本地机器的网卡流量会激增!!!
你的本地机器的网卡流量激增,当然不是一件好事了。因为在一些大的公司里面,对每台机器的使用情况,都是有监控的。不会允许单个机器出现耗费大量网络带宽等等这种资源的情况。运维人员不会允许。可能对公司的网络,或者其他(你的机器还是一台虚拟机),如果你是一台虚拟机的话,和其他机器共享网卡的话,可能对其他机器,公司整个网络环境,都会有负面和恶劣的影响。
解决的方法:
实际上解决的方法很简单,就是心里要清楚,yarn-client模式是什么情况下,可以使用的?
yarn-client模式,通常咱们就只会使用在测试环境中,你写好了某个spark作业,打了一个jar包,在某台测试机器上,用yarn-client模式去提交一下。因为测试的行为是偶尔为之的,不会长时间连续提交大量的spark作业去测试。还有一点好处,yarn-client模式提交,可以在本地机器观察到详细全面的log。通过查看log,可以去解决线上报错的故障(troubleshooting)、对性能进行观察并进行性能调优。
实际上线了以后,在生产环境中,都得用yarn-cluster模式,去提交你的spark作业。
yarn-cluster模式,就跟你的本地机器引起的网卡流量激增的问题,就没有关系了。也就是说,就算有问题,也应该是yarn运维团队和基础运维团队之间的事情了。他们去考虑Yarn集群里面每台机器是虚拟机还是物理机呢?网卡流量激增后会不会对其他东西产生影响呢?如果网络流量激增,要不要给Yarn集群增加一些网络带宽等等这些东西。那就是他们俩个团队的事情了,和你就没有关系了
使用了yarn-cluster模式以后,
就不是你的本地机器运行Driver,进行task调度了。是yarn集群中,某个节点会运行driver进程,负责task调度。
相关文章推荐
- spark troubleshooting--yarn-client模式导致的网卡流量激增问题
- Spark-troubleshooting-yarn-client模式导致的网卡流量激增问题
- troubleshooting之解决yarn-client模式导致的网卡流量激增问题
- spark troubleshooting--解决yarn-cluster模式的JVM栈内存溢出问题
- spark-troubleshooting-网卡流量激增问题
- spark troubleshooting--算子函数返回NULL导致问题
- Spark性能优化-------troubleshooting之解决算子函数返回NULL导致的问题
- 关于win7升级到win10导致Oracel VM VirtualBox中安装rhel6虚拟机网卡设置仅主机模式时不能开机的问题
- spark troubleshooting--YARN队列资源不足导致的application直接失败
- 解决RHEL7.0重启网卡后提示进入紧急模式状态导致修改不成功的问题
- [trouble-shooting]android 无法启动X86模式虚拟机的问题解决。
- iis权限导致worldclient邮件显示问题
- VM虚拟机Bridge模式VMnet0网卡无法启动问题的解决
- 负载均衡热备模式下服务器网卡的主备切换问题 推荐
- 飞机找不到,流量哪去了?记一次移动WAP网关导致的问题
- 教你解决linux与r8168网卡不兼容导致网络时断时续的问题
- 由于插件问题导致iPhone无限重启且进不了安全模式,如何删掉问题插件
- centos6虚拟机克隆导致的网卡问题解决方法
- oracle数据库热备方案中,自动归档模式的相关问题,-------转【一例SPFILE设置错误导致数据库无法启动】
- RHEL Linux 6虚拟机克隆导致的网卡问题解决方法: