背景:之所以想确认这个数据,是因为在hadoop的集群系统中,发现各个节点的CPU使用率都不高,并且查看整个集群并发的map和reduce数,都只有6(三台hadoop机器)
分析:为了查清楚,为什么tasktracker都只启动了两个map任务和两个reduce任务,查看了hadoop的相关配置说明。具体细节如下:
hadoop可以配置每个TaskTracker启动的map和reduce任务数(直白的意思是启动多少个线程来同时处理任务);一般来说,
可以根据CPU的个数,配置同时运行的任务数。该配置在文件mapred-site.xml中。如果不配置的话,默认个数为2,当CPU个数大于2时,则不能完全的利用上当前CPU的能力
<property>
<name>mapred.tasktracker.map.tasks.maximum</name>
<value>8</value>
<final>true</final>
</property>
<property>
<name>mapred.tasktracker.reduce.tasks.maximum</name>
<value>8</value>
<final>true</final>
</property>
此外,在该文件中,还有一个类似的配置选项;该配置项对应的是每个job的map数和reduce数,hadoop的默认取值分别是2和1。真正在执行的时候,每个job的map数,是由多个因素决定的,文件中配置的,只能起到参考作用,真正运行的map数未必是该值;但是,运行时的reduce数,就是文件中配置的取值了。reduce task官方建议配置为0.99*mapred.tasktracker.reduce.tasks.maximum,此时所有的reduce都能够同时立即启动。一个job的map个数过多,会给Jobtracker的任务分配带来太大的压力,并且任务的启动也需要时间;至于为什么job的reduce数要和集群中reduce任务个数持平,这个我不太清楚,感觉即使不持平,也不会有很大的差别。
结论:依次修改节点的配置数据,并重启该节点,调整了集群的配置。各个节点的CPU使用率也上去了,执行时间也缩短了。
分析:为了查清楚,为什么tasktracker都只启动了两个map任务和两个reduce任务,查看了hadoop的相关配置说明。具体细节如下:
hadoop可以配置每个TaskTracker启动的map和reduce任务数(直白的意思是启动多少个线程来同时处理任务);一般来说,
可以根据CPU的个数,配置同时运行的任务数。该配置在文件mapred-site.xml中。如果不配置的话,默认个数为2,当CPU个数大于2时,则不能完全的利用上当前CPU的能力
<property>
<name>mapred.tasktracker.map.tasks.maximum</name>
<value>8</value>
<final>true</final>
</property>
<property>
<name>mapred.tasktracker.reduce.tasks.maximum</name>
<value>8</value>
<final>true</final>
</property>
此外,在该文件中,还有一个类似的配置选项;该配置项对应的是每个job的map数和reduce数,hadoop的默认取值分别是2和1。真正在执行的时候,每个job的map数,是由多个因素决定的,文件中配置的,只能起到参考作用,真正运行的map数未必是该值;但是,运行时的reduce数,就是文件中配置的取值了。reduce task官方建议配置为0.99*mapred.tasktracker.reduce.tasks.maximum,此时所有的reduce都能够同时立即启动。一个job的map个数过多,会给Jobtracker的任务分配带来太大的压力,并且任务的启动也需要时间;至于为什么job的reduce数要和集群中reduce任务个数持平,这个我不太清楚,感觉即使不持平,也不会有很大的差别。
结论:依次修改节点的配置数据,并重启该节点,调整了集群的配置。各个节点的CPU使用率也上去了,执行时间也缩短了。