一次因为数据问题引起的reduce被卡住streaming作业问题排查

标签：streaming   python   mapreduce   

        广告产品技术部有一个作业总是卡在某个reduce上，运行了好几个小时也运行不完，经过他们初步排查找不着问题原因，发邮件让我帮看看，我看了一下这个streaming作业是用python实现的，而且听他们描述，3月17之前该作业是没问题的，以下是可能存在问题的地方：

1、集群节点有问题

2、作业的配置参数不对，导致reduce运行有问题

3、数据问题

那就一一来排查这些问题吧。

第一点，我看了一下被卡住reduce运行的节点，NodeManager日志正常，dmesg日志正常，负载和内存使用都很正常，排查了集群问题的可能性。

第二点，我找到了被卡住reduce正在运行的java进程，通过jstat -gcutil $pid 和top -p $pid查看内存和cpu使用情况都很正常，堆内存是够用的，很长时间才出现一次FGC，不是内存的问题，看cpu使用情况，才0.3%的使用，严重正常，看来根本不是cpu的问题。

第三点，我看了一下reduce的日志，reduce任务已经完成了copy和merge，是在进行数据处理的时候出现被卡住的，那就是在执行python脚本的时候被卡住的，因为之前运行成功过，所以脚本应该是没问题的，那应该是数据问题了，由于问题总是被卡住在后缀是“r_000119”的reduce任务上，我找了一下mapreduce的环境变量，让他在执行reduce任务的python脚本里面加了一个逻辑，如果环境变量mapreduce_task_id(任务id)包含字符串“r_000119”，就把数据打印到标准错误输出以好排查问题，因为问题只会出现在“r_000119”的任务上，所以其他的reduce就不要打了，免得占用大量的集群空间，最后发现果然是数据问题，按逻辑来说一个key的数据不会超过1000，但是通过打印发现某些key的value只已经超过10000了，而python代码逻辑里面最多就任务数据不会超过1000，没做好容错方面的考虑，导致该任务长时间卡住。

总结：

问题排查时用到了mapreduce的环境变量mapreduce_task_id，其实还存在其他常用的环境变量，我这里列一下，以后好备用：

一次因为数据问题引起的reduce被卡住streaming作业问题排查

标签：streaming   python   mapreduce   

原文地址：http://blog.csdn.net/bigdatahappy/article/details/44514219