spark两个节点2.2GB数据的orderby算子测试（下）

与（上）的不同点：

1. 输入数据在两台机器上都有拷贝，读取时直接本地读取

2. 直接输出数据到本地，每台机器上输出的是自己运行的分区

 

 

读取数据时slave5仍然只读了4个分区，等会可以看出原因，读取数据时的tasks如下：

 

这就导致了这次的jobs，stages，tasks的分配和上次比可以说是一样，再上一张shuffle read的总览图：

 

下面是ganglia的测试图，我们可以看出原因：

master1：

slave5：

 

上次是因为网络io导致的slave5只读取了4个分区，这次数据在本地了，磁盘io又严重影响了性能，注意master1是固态盘，slave5是机械盘

 

除了这些数据，这次还记录了executor的gc日志和sink ganglia的数据，

这次我先只关注和分析master1，也就是executor1的数据：

应用开始时的一段gc日志（第一个字段是应用开始运行时为时间零点的秒数）：

sink ganglia有很多指标，先上几个觉得重要的：

上个jobs的图方便对应时间：

下面是ganglia的数据：时间（第1小格应用还没提交，大概为第2小格读取数据，之后5格shuffle write ，再之后shuffle read）

左bytesread.count  右byteswrite.count： 磁盘读写，第二格为什么是空的？

 

 

下一幅图：左上是 deserializedTime.count 右边显示一半的单词是spill

executor1共执行14个tasks，4个轮次，可以看出因不同轮次导致数据写到磁盘不计入spill

shuffle read导致反序列化用时快速增长

gc时间增长较均衡，水平部分是由于等待slave5完成tasks

 

跟堆空间和gc相关的一些指标：再上一段开始60秒后的gc日志，这时的堆内存已经扩展到650m， 新生代340m，已经达到executor可用内存的限制了，之后差不多都维持在这个水平，shuffle read阶段开始下降

 

57-58分钟的数据都没有，从gc日志上看这段时间堆空间使用在400m左右，怀疑是网络问题导致的，sink ganglia的数据实在太多了

测试总结：

这两次实验的性能问题都是数据分配不均衡导致的：

第一次由于数据在master1上，要靠网络io传输到slave5上，导致slave5只处理了少量数据。

第二次虽然两台机器上都有拷贝，但是slave5是机械硬盘，磁盘io又影响了slave5获取数据的速度，导致slave5只处理了少量数据。

针对这个问题的优化方法：

1.数据分散存储或拷贝

2.统一使用固态硬盘

3.网络优化

4.防止数据倾斜（orderby算子的水塘抽样算法可以降低倾斜概率）

5.jvm调优

以上都是大方向，具体应用还有很多要学习的地方。

项目也接近尾声了，这次的学习不只是分析了一个算法，还让我实际感受到了课本上的知识，非常感谢唐洁老师的耐心指导，占用您太多时间，感谢师兄的帮助，祝你前程似锦！