[大牛翻译系列]Hadoop（12）MapReduce 性能调优：诊断硬件性能瓶颈

2022-09-09 09:16:12

6.2.5 硬件性能问题

尽管单独的硬件的MTTF（平均失效前时间）都数以年记，然而在集群中就完全不是这么一回事了。整个集群的MTTF就要小得多。这一节要介绍如何确定CPU，内存，磁盘和网络是否过度利用了，以及如何将它们的利用率调节到一个合理的水平。

技术39 查找硬件的失效

节点失效可能有如下原因：磁盘控制器失效，磁盘空间事故，其他硬件事故，以及Hadoop自身的缺陷（可能性较低）。节点失效将会导致MapReduce作业执行时间变长。在较小的集群上的影响要更为明显。接下来就要介绍如何确定集群中的节点是否失效。

问题

需要确定是否是由于硬件故障导致作业运行缓慢，并查看节点的黑名单和灰名单。

方案

使用JobTracker UI来检查黑名单或灰名单中的节点。

讨论

图6.24介绍了在哪里可以看到黑名单和灰名单。

小结

在集群中，特别是较小的集群是不希望看到有节点在黑名单或灰名单里的。灰名单中的节点会时不时地失效。这些节点会导致部分任务失败，拉长作业执行时间。黑名单中的节点根本不会有任何作用，这样使作业的性能远远小于预期。

如果需要了解节点进入黑名单或灰名单的原因，则需要查看任务，任务跟踪器（TaskTracker），或数据节点的日志。一旦出现了这种情况，则需要调查那些失效的节点。

比较好的一个方法是设置对黑名单和灰名单中节点的监控，这样就可以在它们失效时快速反应。通过Nagios监视器（http://goo.gl/R6deM）可以达到这个目的。它的原理是使用curl从JobTracker上通过http://127.0.0.1:50030/machines.jsp?type=blacklisted下载黑名单网页，并检查其中是否有节点。

技术40 CPU竞争

如果节点过度利用了CPU，那么会导致大量的时间被消耗在上下文切换，进而减少作业获得的计算能力。

问题

需要确定是否由于CPU过度利用导致了作业运行缓慢。

方案

使用Linux工具vmstat来观测CPU的上下文切换。

讨论

从vmstat中可以得到CPU利用率，IO等待，上下文切换等信息。通过这些信息可以快速评估主机的繁忙程度。图6.25说明了vmstat的执行方法和执行选项。（图的对齐有问题，这个暂时没有修正。请谅解。）

图6.26指出了需要观察的项目

小结

Linux的运行队列越长，Linux内核的进程间上下文切换的时间就越多。上写文切换是昂贵的。它需要CPU保存当前进程的状态，读入下一个进程的状态。也就是说，只要观察到了过度的上下文切换，很可能的原因就是主机上运行的任务太多了。有两个配置项mapred.tasktracker.map.tasks.maximum和mapred.tasktracker.reduce.tasks.maximum。它们的总和应当大约在主机的逻辑内核个数的120%左右。

有时候任务跟踪器会和CPU挂钩，并导致CPU利用率过高。这需要用top查看任务跟踪器是否是CPU绑定的，并考虑是否解绑。

还有如下工具可以参考：

procinfo。查看是否有设备导致了过高的中断数量。
sar。采集并将系统数据保存到文件。
mpstat。给出基于单个CPU的统计数据，而不是所有CPU的。

技术41 内存交换

当内存使用量超过了物理内存上限，操作系统机会根据内存溢出机制使用磁盘作为。（我们一般叫这个虚拟内存。）这样就会产生内存交换。

磁盘的读写速度是远远小于内存的。内存交换也就会使节点的性能大为降低。

问题

需要是否由于内存交换导致作业运行缓慢。

方案

使用Linux工具vmstat来观察是否存在内存和磁盘间的交换。

讨论

图6.27介绍如何使用执行vmstat和它的执行选项。（图的对齐有问题，这个暂时没有修正。请谅解。）

图6.28标注了需要观察的项目。（图的对齐有问题，这个暂时没有修正。请谅解。）

小结

如果存在内存交换，就需要考虑增加这个节点上的内存或减少这个节点上的map和reduce任务的并发数了（mapred.tasktracker.map.tasks.maximum and mapred.tasktracker.reduce.tasks.maximum）。

技术42 磁盘健康

即便是不过载的集群也对磁盘和磁盘控制器有很大的压力。这一节中将介绍如何评估磁盘的健康程度。此外，还将介绍如何诊断由磁盘只读装载所带来的IO错误。

问题

需要确定磁盘是否在降级运行或只读状态。

方案

使用Linux工具iostat得到磁盘的请求队列和IO等待时间。使用Linux工具dmesg得到磁盘的只读状态。

讨论

在Linux工具中，iostat是非常复杂的一个。图6.29介绍了如何执行iostat和它的执行选项。（图的对齐有问题，这个暂时没有修正。请谅解。）

图6.30标注了iostat的输出中需要注意的项目。（图的对齐有问题，这个暂时没有修正。请谅解。）

另外一个需要观察的重要事项是：文件系统是否处于只读状态。这会由Linux的磁盘或RAID控制器的缺陷引发，并可能使节点出问题。在这种情况下任务追踪器和数据节点日志中会记录：无法向磁盘写入数据。另外，可以用dmesg检查/var/log/messages中的消息。查看其中是否标识：文件系统被转换成只读状态。命令如下。

$ dmesg | grep read-only

小结

磁盘过载导致的读写缓慢以及文件系统只读带来的IO错误都会导致节点变残（cripple）。
You can use hdparm to measure the sequential read rate of your hard disk. Replace
/dev/md1 with the name of your disk device (consult /etc/fstab for device names):

可以使用hdparm来测量硬盘的序列读取速率。使用下面的命令，需要将/dev/md1换成真实的磁盘设备。

$ cat /etc/fstab

...

/dev/md1 /usr ext3 defaults 1 2

...

$ sudo /sbin/hdparm -t /dev/md1

/dev/md1:

Timing cached reads: 30656 MB in 1.99 seconds = 15405.72 MB/sec

Timing buffered disk reads: 108 MB in 3.03 seconds = 35.63 MB/sec

如果数据节点有IO等待问题，可以通过在各个节点上加装硬盘，并配置dfs.data.dir使用它们，来提高读写速率。

技术43 网络

由于MapReduce和HDFS对网络重度依赖，如数据传输等，如果网络问题，将会产生重大影响。这个技术将介绍如何正确配置节点，以及如何测试节点间的网络吞吐量。

问题

需要诊断是否是由于网络原因导致作业运行缓慢。

方案

使用Linux工具ethtool和sar的输出可以帮助诊断网络的配置问题。

讨论

首先检查以太网卡是否在正确的速度上以全双工运行。图6.31介绍了如何用ethtool获得相应信息。