最近一个从Hbase捞取数据进行统计值的Spark Job 计算经常报警，执行时间大大超过以前的平均执行时间。
于是打开一个application
image.png
发现这个application 有4个job，如上图所示，但是执行时间有点长。
于是我点开正在执行的job
然后点开一个执行比较的stage
在页面点开event TimeLine 看到如下
image.png
居然有一个task执行特别慢，刚开始以为是数据倾斜，后来仔细一看数据量和其他task是一致的。所以顿时怀疑是这台机器是要么有硬件问题，要么就是资源不够了。
于是登陆这台机器
top 一下 在 加 Shift + m 按照内存排序
image.png
内存和cpu 看起来都ok，那是不是磁盘满了？
再看
image.png
看起来磁盘容量也没问题啊。
没啥办法，于是我又去我们ganggalia上去看读写等指标
读写次数和其他机器也没有太大的区别。
是不是读写hbase有问题，于是查看hbase相关的监控，发现数据分布均匀，而且没有什么异常。比如超时的
然后我想看看磁盘的读写速度吧
输入
iostat -x
image.png
突然发现上图中的有一个w-wait 也就是写入耗时，都到了300多ms了，然后我又看了一下其他机器的w-wait 发现都是20以下，所以基本断定是这个磁盘的问题了。然后通知运维，让运维换盘。
问题解决。
image.png
总结一下步骤：
1、查看spark日志，err日志等看是否有什么异常（常见的网络，连接问题，磁盘空间等异常常见）
2、查看每个stage 数据是否发生切斜,
3、确认持久化级别，是否是全部内存，查看是否出现spillToDisk
4、查看是否有单个节点执行时间比较长
5、登陆有问题的节点，查看load，内存以及网络属性
6、查看磁盘读写情况
