分析和优化云集群性能 mapred.reduce.parallel.copies 等

标签: Hadoop | 发表时间:2012-06-08 17:29 | 作者:jrckkyy
出处:http://hi.baidu.com/jrckkyy

简介

Hadoop 是一个灵活的开放源码 Java 框架,用于在一般硬件网络上执行大规模数据处理。它的思想来源于最初由 Google Labs 开发的 MapReduce 和 Global File System (GFS) 技术,由于具有高效、可靠和可伸缩的优点,它越来越流行了。Hadoop 现在是顶级 Apache 项目,IBM、Google、Yahoo! 和 Facebook 等许多公司都支持和使用 Hadoop,它已经成为大规模数据处理方面事实上的行业标准框架。

Hadoop 对于云计算意味着什么?云计算的目的之一是,以尽可能低的开销为计算机资源提供高可用性。Hadoop 能够处理数千个节点和 PB 量级的数据,可以自动地处理作业调度、部分失败和负载平衡,因此它是实现这个目标的完美工具。

要想充分使用计算机资源,优化性能是非常重要的,包括 CPU、内存和 I/O(磁盘和网络)。Hadoop 可以自动地改进性能,同时向用户提供接口,让他们可以针对自己的应用程序优化性能。本文介绍重要的 Hadoop 可配置参数以及分析和调优性能的方法。

建立环境

部署 Hadoop 环境的步骤

在执行性能调优之前,需要先构建 Hadoop 集群环境。步骤如下:

准备集群节点,在这些节点上安装 Linux OS、JDK 1.6 和 ssh。确保每个节点上都在运行 sshd。

访问 The Apache Software Foundation 站点,下载稳定的 Hadoop 发行版。

选择自己的 NameNode (NN)、JobTracker (JT) 和 Secondary NameNode (SNN);其他节点是 DataNode (DN) 和 TaskTracker (TT)。本文假设选择 host001 作为 NN,host002 作为 JT,host003 作为 SNN。

让 NN、JT 和 SNN 能够通过 ssh 无需密码地访问所有 DN 和 TT。

在每个节点上解压下载的 Hadoop 发行版;下面使用 $HADOOP_HOME 代表解压位置。

在 NN 上,进入 $HADOOP_HOME 目录并修改配置文件。

把 host003 添加到 $HADOOP_HOME/conf/masters 中。

把所有 DN/TT 节点的 IP 地址/主机名添加到 $HADOOP_HOME/conf/slaves 中,每个主机一行。 注意:如果使用主机名,就需要通过配置 /etc/hosts 文件确保集群中的所有节点都知道每个主机名。

把以下属性添加到 $HADOOP_HOME/conf/core-site.xml 中以设置 NN IP/端口:

<property>

<name>fs.default.name</name>

<value>hdfs://host001:9000</value>

</property>

把以下属性添加到 $HADOOP_HOME/conf/mapred-site.xml 中以设置 JT IP/端口:

<property>

<name> mapred.job.tracker </name>

<value>host002:9001</value>

</property>

注意:如果使用 Hadoop 0.21.0,这个属性名应该是 mapreduce.jobtracker.address。

如果在 NN 上有多个网络接口,那么把以下属性添加到 $HADOOP_HOME/conf/hdfs-site.xml 中:

<property>

<name>dfs.datanode.dns.nameserver</name>

<value>eth1</value>

<description>The name of the Network Interface from which a data node

should report its IP address.

</description>

</property>

把上面提到的所有配置文件从 NN 复制到集群中所有其他节点上的 $HADOOP_HOME/conf/ 目录中。

在 NN 上进入 $HADOOP_HOME/bin 目录。

使用 $./hadoop namenode -format 命令格式化 NN。

启动 start-all.sh 脚本以启动 Hadoop 守护进程。

更详细的信息参见 Hadoop Common。注意:如果选用 Hadoop 0.21.0,那么必须使用当前的 JDK(由 JIRA HADOOP-6941 跟踪)。

安装并配置 nmon 性能监视工具

nmon 是一个系统管理、调优和基准测试工具,可以简便地监视大量重要的性能信息。可以在整个性能调优过程中使用 nmon 作为监视工具。按以下步骤安装并配置 nmon,建立自己的性能监视系统:

从 nmon for Linux 站点下载 nmon 二进制包。找到适合您的 Linux OS 的版本,把它复制到 Hadoop 集群的所有节点。下面使用 $NMON_HOME 代表放置 nmon 二进制代码的位置。

因为已经让 NN、JT 和 SNN 能够通过 ssh 无需密码地访问所有其他节点,而且将在 JT 上提交所有 map/reduce 作业,所以选择 JT 作为中心节点收集所有 nmon 数据。登录 JT 节点,然后执行以下步骤。

使用以下命令在 JT (host002) 上创建一个目录(例如 /home/hadoop/perf_share)并通过 NFS 共享它:

创建目录:$mkdir /home/hadoop/perf_share

修改 /etc/exports 文件,在其中包含以下行:/home/hadoop/perf_share *(rw,sync)

重新启动 NFS 服务:$/etc/rc.d/init.d/nfs restart

在所有其他节点上创建这个目录并把它们挂装到 JT 上的 perf_share 目录:

$mkdir/home/hadoop/perf_share

$mount host002: /home/hadoop/perf_share /home/hadoop/perf_share

创建以下脚本以便在所有节点上启动 nmon:

hosts=( shihc008 shihc009 shihc010 shihc011 shihc012 shihc013 shihc014 shihc015

shihc016 shihc017)

# Remove all data in /home/hadoop/perf_share

for host in ${hosts[@]}

do

ssh $host "cd /home/hadoop/perf_share;rm -rf *"

done

# Start nmon on all nodes

for host in ${hosts[@]}

do

ssh $host " /usr/bin/nmon -f -m /home/hadoop/perf_share -s 30 -c 360"

done

在最后的 nmon 命令中,-f 表示希望把数据保存到文件中,并不在屏幕上显示;-m 表示保存数据的位置;-s 30 表示希望每 30 秒捕捉一次数据;-c 360 表示需要 360 个数据点(即快照),总数据收集时间为 30x360 秒,即 3 小时。

从 nmonanalyser wiki 下载 nmonanalyser(这个 Excel 电子表格接受 nmon 的输出文件,生成一些漂亮的图表以帮助分析),用它分析收集到的监视数据。

Hadoop 可配置参数

Hadoop 提供许多配置选项,用户和管理员可以通过它们进行集群设置和调优。core/hdfs/mapred-default.xml 中有许多变量,可以在 core/hdfs/mapred-site.xml 中覆盖它们。一些变量指定系统上的文件路径,而其他变量对 Hadoop 的内部进行深入的调整。

性能调优主要有四个方面:CPU、内存、磁盘 I/O 和网络。本文介绍与这四个方面最相关的参数,您可以使用后面介绍的方法研究 *-default.xml 中的其他参数。

与 CPU 相关的参数: mapred.tasktracker.map 和 reduce.tasks.maximum

决定由任务跟踪器同时运行的 map/reduce 任务的最大数量。这两个参数与 CPU 利用率最相关。这两个参数的默认值都是 2。根据集群的具体情况适当地增加它们的值,这会提高 CPU 利用率,由此提高性能。例如,假设集群中的每个节点有 4 个 CPU,支持并发多线程,每个 CPU 有两个核;那么守护进程的总数不应该超过 4x2x2=16 个。考虑到 DN 和 TT 要占用两个,map/reduce 任务最多可以占用 14 个,所以这两个参数最合适的值是 7。

在 mapred-site.xml 中设置此参数。

与内存相关的参数: mapred.child.java.opts

这是用于 JVM 调优的主要参数。默认值是 -Xmx200m,这给每个子任务线程分配最多 200 MB 内存。如果作业很大,可以增加这个值,但是应该确保这不会造成交换,交换会严重降低性能。

我们来研究一下这个参数如何影响总内存使用量。假设 map/reduce 任务的最大数量设置为 7,mapred.child.java.opts 保持默认值。那么,正在运行的任务的内存开销为 2x7x200 MB =2800 MB。如果每个工作者节点都有 DN 和 TT 守护进程,每个守护进程在默认情况下占用 1 GB 内存,那么分配的总内存大约为 4.8 GB。

在 mapred-site.xml 中设置此参数。

与磁盘 I/O 相关的参数: mapred.compress.map.output、mapred.output.compress 和 mapred.map.output.compression.codec

这些参数控制是否对输出进行压缩,其中 mapred.compress.map.output 用于 map 输出压缩,mapred.output.compress 用于作业输出压缩,mapred.map.output.compression.codec 用于压缩代码。这些选项在默认情况下都是禁用的。

启用输出压缩可以加快磁盘(本地/Hadoop Distributed File System (HDFS))写操作,减少数据传输的总时间(在 shuffle 和 HDFS 写阶段),但是在另一方面压缩/解压过程会增加开销。

根据个人经验,启用压缩对于使用随机键/值的操作序列是无效的。建议只在处理大量有组织的数据(尤其是自然语言数据)时启用压缩。

在 mapred-site.xml 中设置这些参数。

io.sort.mb 参数

这个参数设置用于 map 端排序的缓冲区大小,单位是 MB,默认值是 100。这个值越大,溢出到磁盘就越少,因此会减少 map 端的 I/O 时间。注意,增加这个值会导致每个 map 任务需要的内存增加。

根据个人经验,在 map 输出很大而且 map 端 I/O 很频繁的情况下,应该尝试增加这个值。

在 mapred-site.xml 中设置此参数。

io.sort.factor 参数

这个参数设置在 map/reduce 任务中同时合并的输入流(文件)数量。这个值越大,溢出到磁盘就越少,因此会减少 map/reduce 的 I/O 时间。注意,如果给每个任务分配的内存不够大,增加这个值可能会导致更多垃圾收集活动。

根据个人经验,如果出现大量溢出到磁盘,而且排序和 shuffle 阶段的 I/O 时间很高,就应该尝试增加这个值。

在 mapred-site.xml 中设置此参数。

mapred.job.reduce.input.buffer.percent 参数

这个参数设置用于在 reduce 阶段保存 map 输出的内存的百分比(相对于最大堆大小),默认值是 0。当 shuffle 结束时,内存中剩余的 map 输出必须少于这个阈值,然后 reduce 阶段才能够开始。这个值越大,磁盘上的合并就越少,因此会减少 reduce 阶段本地磁盘上的 I/O 时间。注意,如果给每个任务分配的内存不够大,增加这个值可能会导致更多垃圾收集活动。

根据个人经验,如果 map 输出很大而且在 reduce 到排序阶段本地磁盘 I/O 很频繁,应该尝试增加这个值。

在 mapred-site.xml 中设置此参数。

mapred.local.dir 和 dfs.data.dir 参数

这两个参数决定把 Hadoop 中的数据放在什么地方,mapred.local.dir 决定存储 MapReduce 中间数据( map 输出数据)的位置,dfs.data.dir 决定存储 HDFS 数据的位置。

根据个人经验,把这些位置分散在每个节点上的所有磁盘上可以实现磁盘 I/O 平衡,因此会显著改进磁盘 I/O 性能。

在 mapred-site.xml 中设置 mapred.local.dir,在 hdfs-site.xml 中设置 dfs.data.dir。

与网络相关的参数: topology.script.file.name

这个参数指向一个用户定义的脚本,这个脚本判断机架-主机(rack-host)映射以配置机架感知。在 core-site.xml 文件中设置此参数。

机架感知是对于提高网络性能最重要的配置,强烈建议按

http://hadoop.apache.org/common/docs/current/cluster_setup.html#Hadoop+Rack+Awareness 和

http://wiki.apache.org/hadoop/topology_rack_awareness_scripts 上的说明配置它。

mapred.reduce.parallel.copies 参数

这个参数决定把 map 输出复制到 reduce 所使用的线程数量,默认值是 5。增加这个值可以提高网络传输速度,加快复制 map 输出的过程,但是也会增加 CPU 使用量。

根据个人经验,增加这个值的效果不太明显,建议只在 map 输出非常大的情况下增加这个值。

注意:上面列出的参数名都是 Hadoop 0.20.x 中的;如果使用 0.21.0,名称可能有变化。除了 Hadoop 参数之外,还有一些会影响

体性能的系统参数,比如机架间带宽。

如何调优和提高性能

介绍了上面的预备知识之后,现在讨论如何调优和提高性能。可以把整个过程划分为以下步骤。

步骤 1:选择测试基准

整个 Hadoop 集群的性能由两个方面决定:HDFS I/O 性能和 MapReduce 运行时性能。Hadoop 本身提供几个基准,比如用于 HDFS I/O 测试的 TestDFSIO 和 dfsthroughput(包含在 hadoop-*-test.jar 中)、用于总体硬件测试的 Sort(包含在 hadoop-*-examples.jar 中)和 Gridmix(它模拟网格环境中的混合工作负载,放在 $HADOOP_HOME/src/benchmarks 目录中)。可以根据自己的测试需求选择任何基准。

在所有这些基准中,当输入数据很大时,Sort 可以同时反映 MapReduce 运行时性能(在 “执行排序” 过程中)和 HDFS I/O 性能(在 “把排序结果写到 HDFS” 过程中)。另外,Sort 是 Apache 推荐的硬件基准。(可以通过 Hadoop Wiki 找到相关信息。)因此,本文使用 Sort 作为示例测试基准讲解性能调优方法。

步骤 2:构建基线

测试环境:

基准:Sort

输入数据规模:500 GB

Hadoop 集群规模:10 个 DN/TT 节点

所有节点都是相同类型的

节点信息:

Linux OS

两个 4 核处理器,支持并发多线程

32 GB 内存

5 个 500 GB 磁盘

测试脚本:下面是测试使用的脚本(关于运行 Sort 基准的更多信息参见 Hadoop Wiki)。所有脚本都应该在 JT 节点上运行。

注意:把上面提到的 start_nmon.sh 脚本和以下脚本放在存储测试结果的目录中。

baseline_test.sh

run_sort_baseline.sh

基线测试使用的参数值:

Hadoop 参数值:

mapred.tasktracker.map.tasks.maximum = 2 (默认值)

mapred.tasktracker.reduce.tasks.maximum = 2 (默认值)

mapred.reduce.parallel.copies = 5 (默认值)

mapred.child.java.opts = -Xmx200m (默认值)

mapred.job.reduce.input.buffer.percent = 0 (默认值)

io.sort.mb = 100 (默认值)

io.sort.factor = 10 (默认值)

mapred.local.dir = /hadoop/sdb

dfs.data.dir = /hadoop/sdc, /hadoop/sdd, /hadoop/sde

系统参数值:

机架间带宽 = 1 Gb

基线测试结果:

执行时间:10051 秒

资源使用量汇总:

详细的图表:

获得所有 nmon 数据之后,可以使用 nmonanalyser 生成图表。因为 nmonanalyser 是一个 Excel 电子表格,所以只需打开它,单击 analyse nmon data,选择 nmon 文件。然后就可以得到经过分析的图表。

图 1. 使用 nmonanalyser 分析 nmon 数据

nmonanalyser 对于基线测试生成的详细图表如下:

图 2. NameNode 图表

图 3. JobTracker 图表

图 4. DataNode/TaskTracker 图表

步骤 3:寻找瓶颈

需要根据监视数据和图表仔细地研究系统瓶颈。因为主要的工作负载分配给 DN/TT 节点,所以应该首先观察 DN/TT 节点的资源使用量(下面只给出 DN/TT 节点的 nmon 图表以节省篇幅)。

通过研究基线监视数据和图表,可以发现系统中有几个瓶颈:在 map 阶段,没有充分使用 CPU(大多数时候不到 40%),而且磁盘 I/O 相当频繁。

步骤 4:打破瓶颈

首先尝试提高 map 阶段的 CPU 利用率。前面对 Hadoop 参数的说明指出,要想提高 CPU 利用率,需要增加 mapred.tasktracker.map 和 reduce.tasks.maximum 参数的值。

在测试环境中,每个节点有两个支持并发多线程的 4 核处理器,所以有 16 个可用的位置,可以把这两个参数设置为 7。

为了完成这一修改,需要在 mapred-site.xml 中设置 mapred.tasktracker.map 和 reduce.tasks.maximum 参数,重新启动集群,再次启动 baseline_test.sh(因为在 mapred-site.xml 文件中进行配置,所以这里不需要修改脚本)。修改后的 mapred-site.xml 如下所示:

下面是调优后的测试结果:

执行时间:8599 秒

资源使用量汇总:

图 5. 调优后的 DataNode/TaskTracker 图表

步骤 5:新一轮调优,重复步骤 3 和 4

增加每个 TaskTracker 中 map/reduce 任务的最大数量之后,观察获取的数据和图表,可以看到在 map 阶段已经充分使用 CPU 了。

是与此同时,磁盘 I/O 频率仍然很高,所以需要新一轮调优-监视-分析过程。
需要重复这些步骤,直到系统中没有瓶颈,每种资源都充分使用为止。

注意,每次调优不一定会提高性能。如果出现性能下降,需要恢复以前的配置,尝试用其他调优措施打破瓶颈。在这次测试中,最终取得的优化结果如下:

执行时间:5670 秒

系统参数值:机架间带宽 = 1Gb

资源使用量汇总:

图 6. DataNode/TaskTracker 图表 - 第二轮调优

步骤 6:可伸缩性测试和改进

为了进一步检验调优结果,需要在使用优化后的配置的情况下增加集群规模和输入数据规模,从而测试配置的可伸缩性。具体地说,把集群规模增加到 30 个节点,把输入数据规模增加到 1.5TB,然后再次执行上面的测试过程。

由于篇幅有限,这里不详细描述调优过程。监视和分析方法与上面提到的完全相同,发现的主要瓶颈出现在网络中。当输入数据增加到 TB 量级时,机架间带宽变得不足。把机架间带宽增加到 4 Gb,10 节点集群优化后的所有其他参数保持不变,最终的执行时间是 5916 秒,这相当接近 10 节点集群优化后的结果(5670 秒)。

结束语

您现在了解了如何监视 Hadoop 集群、使用监视数据分析系统瓶颈和优化性能。希望这些知识能够帮助您充分使用 Hadoop 集群,更高效地完成作业。可以使用本文描述的方法进一步研究 Hadoop 的可配置参数,寻找参数配置与不同作业特征之间的关联。

另外,这种基于参数的调优比较 “静态”,因为一套参数配置只对于一类作业是最优的。为了获得更大的灵活性,您应该研究 Hadoop 的调度算法,寻找提高 Hadoop 性能的新方法。

阅读全文
类别: Hadoop  查看评论

相关 [分析 优化 集群] 推荐:

分析和优化云集群性能 mapred.reduce.parallel.copies 等

- - 学着站在巨人的肩膀上
Hadoop 是一个灵活的开放源码 Java 框架,用于在一般硬件网络上执行大规模数据处理. 它的思想来源于最初由 Google Labs 开发的 MapReduce 和 Global File System (GFS) 技术,由于具有高效、可靠和可伸缩的优点,它越来越流行了. Hadoop 现在是顶级 Apache 项目,IBM、Google、Yahoo.

elasticsearch 1.x集群优化

- - ITeye博客
欢迎发送邮件至 [email protected]. 本博文为 Elasticsearch Server2nd的部分第7章部分章节的翻译,版权归原作者. 设置Filter cache. 缓存是提高性能的很重要的手段,es中的filter cache能够把搜索时的filter条件的结果进行缓存,当进行相同的filter搜索时(query不同,filter条件相同),es能够很快的返回结果.

Hadoop集群与Hadoop性能优化

- - 学着站在巨人的肩膀上
本文讲解一下Hadoop集群、Hadoop性能优化、Hadoop机架感知实现、Hadoop配置等,下面是有关这些命令的具体介绍. Hadoop性能优化:Hadoop机架感知实现及配置:分布式的集群通常包含非常多的机器,由于受到机架槽位和交换机网口的限制,通常大型的分布式集群都会跨好几个机架,由多个机架上的机器共同组成一个分布式集群.

Quartz应用与集群原理分析

- - 美团技术团队
美团CRM系统中每天有大量的后台任务需要调度执行,如构建索引、统计报表、周期同步数据等等,要求任务调度系统具备高可用性、负载均衡特性,可以管理并监控任务的执行流程,以保证任务的正确执行. 美团CRM系统的任务调度模块经历了以下历史方案. 每天晚上运行定时任务,通过SQL脚本+crontab方式执行,例如,.

quartz集群调度机制调研及源码分析

- - CSDN博客推荐文章
quartz2.2.1集群调度机制调研及源码分析. quratz是目前最为成熟,使用最广泛的java任务调度框架,功能强大配置灵活.在企业应用中占重要地位.quratz在集群环境中的使用方式是每个企业级系统都要考虑的问题.早在2006年,在ITeye上就有一篇关于quratz集群方案的讨论: http://www.iteye.com/topic/40970 ITeye创始人@Robbin在8楼给出了自己对quartz集群应用方案的意见..

Hadoop集群硬盘故障分析与自动化修复

- - CSDN博客推荐文章
作者:Zhang, Haohao. 硬盘在服务器中起着至关重要的作用,因为硬盘里面存储的是数据,随着制造业技术的提高,硬盘的类型也在逐渐的改变. 对于硬盘的管理是IAAS部门的责任,但作为业务运维也需要懂得相关的技术. 有的公司采用LVM来管理硬盘,这样做方便扩缩容,也有的公司直接用裸盘来存数据,这样做的好处是不会因LVM而损失掉一部分硬盘I/O速度.

mysql优化之profile查询分析

- - 数据库 - ITeye博客
通过慢日志查询可以知道哪些SQL语句执行效率低下,通过explain我们可以得知SQL语句的具体执行情况,索引使用等,还可以结合show命令查看执行状态. 如果觉得explain的信息不够详细,可以同通过 profiling命令得到更准确的SQL执行消耗系统资源的信息. 这里还需要注意一点就是,需要安装profile模块才能实现.

Go程序调试、分析与优化

- - Tony Bai
Brad Fitzpatrick在 YAPC Asia 2015(Yet Another Perl Conference)上做了一次技术分享,题为:" Go Debugging, Profiling, and Optimization". 个人感觉这篇分享中价值最大的是BradFitz现场演示的一个有关如果对 Go程序进行调试、分析和优化的 Demo,Brad将demo上传到了他个人在github.com的 repo中,但不知为何,repo中的代码似乎与repo里talk.md中的说明不甚一致(btw,我并没有看video).

从未降级的搜索技术 – HBase集群升级与优化

- - 搜索技术博客-淘宝
战争从来都是拼后勤拼平台支撑的,天猫双十一这一天对于我们搜索事业部来说,就是一场高强度的数字化战争. 为了这一天,各兄弟业务线的战友们已经摩拳擦掌,纷纷亮出各种新式武器,而我们原有的离线系统平台却渐渐显出疲态,慢慢被来自各业务线的不断提升的压力需求搞得捉襟见肘了. 个性化搜索实时数据处理平台(Pora)在双十一将正式亮相,当时我们预计会有数以十亿计的新增HBase读写请求,如果不进行升级优化,原有的离线集群预计将无法承受这一前所未有的压力;天猫业务线的增量在双十一更是重中之重,届时预计会有数倍甚至十多倍的增长,不断流,不延迟对于原有的离线集群来说也是巨大的考验;主搜、国际站等业务线也都对底层平台提出了越来越高的要求,凌晨全量的时间极其有限,不能出现任何闪失.

mysql性能优化-慢查询分析、优化索引和配置

- - 数据库 - ITeye博客
profiling分析查询. MySQL 数据库是常见的两个瓶颈是CPU和I/O的瓶颈,CPU在饱和的时候一般发生在数据装入内存或从磁盘上读取数据时候. 磁盘I/O瓶颈发生在装入数据远大于 内存容量的时候,如果应用分布在网络上,那么查询量相当大的时候那么平瓶颈就会出现在网络上,我们可以用mpstat, iostat, sar和vmstat来查看系统的性能状态.