整套大数据学习资料(视频+笔记)百度网盘无门槛下载:http://www.edu360.cn/news/content?id=3377

9.4.2 环境设置

hadoop 小红牛 97℃ 0评论

本节探讨如何设置hadoop-env.sh文件中的变量。

1.内存

在默认情况下,Hadoop为各个守护进程分配1000 MB(IGB)内存。该内存值由 hadoop-env.sh文件的 HADOOP_HEAPSIZE 参数控制。此外,tasktracker 启动独立的子JVM以分别运行mapreduce任务。因此,需要综合考虑上述因素来计算一个工作机器的最大内存需求。

一个tasktracker所能够同时运行別最大map任务数由 mapred.tasktracker.map.tasks.maximum 属性控制,默认是2个任务。相应的,一个tasktracker所能够同时运行的最大reduce任务数由 mapred.tasktracker.reduce.tasks.maximum 属性控制,默认值也是

2。因此,也可以说tasktracker拥有2map槽和2reduce槽。

分配给每个子JVM的内存量由mapred.child.java.opts属性决定,默认值是-Xmx200m,表示每个任务分配200 MB内存。顺便提一句,用户也可以提供其他JVM选项。例如,启用verbose GC Logging工具以调试GC。综上所述,在默认情况下,一个工作机器会占用2800 MB内存(参见 表 9-2)

表9-2.计算工作节点的内存占用量

JVM

默认内存占用量(MB) 8

处理器机器的内存占用量,每个 子任务分配400 MB

datanode

1000

1000

tasktracker

1000

1000

tasktracker 的子 map 任务

2 x 200

7 x 400

tasktracker 的子 reduce 任务

2 x 200

7 x 400

总计

2800

7600

在一个tasktracker上能够同时运行的任务数取决于一台机器有多少个处理器。由于MapReduce作业通常是I/0受限的(即完成整项计算任务的时间开销主要在于I/O操作),因此将任务数设定为超出处理器数也有一定道理,能够获得更好的利用率。至于到底需要运行多少个任务,则依赖于相 关作业的CPU使用情况,但经验法则是任务数(包括mapreduce任务)与处理器数的比值最好在12之间。

 例如,假设客户拥有8个处理器,并计划在各处理器上分别跑2个进程,则可以mapred.tasktracker.map.tasks.maximummapred.tasktracker reduce .tasks.maximum的值分别设为7(考虑到还有datanodetasktracker这两个进程,这两项值不可设为8)。如果各个子任务的可用内存 增至400 MB,则总内存开销将高达7600 MB(参见表9-2)。

 

对于配备8 GB物理内存的机器,该Java内存分配方案是否合理还取决于在这台机器上同时运行的其他进程。例如,若还试图在这台机器运行 Streaming和管道等程序,则该分配方案并不恰当(而且分配到子任务的内存 将会减少),因为无法为其他进程(包括Streaming和管道)分配足够的内存。此时,各进程在系统中不断切换,导致服务性能恶化。精准的内存设置极度依赖于集群自身的特性。用户需要持续监控集群的内存使用情况,并实 时设定优化分配方案。Ganglia(参见10.2.3)就是实时搜集此类信息的有效工具。读者也可参考9.4.5节加深理解。

Hadoop也可设置MapReduce操作所能使用的最大内存量。这类设置分别针对各项作业进行,详情可参见6.4)

对于主节点来说,namenode、辅助namenodejobtracker守护进程在默认情况下各使用1000MB内存,所以总计3000 MB

一个守护进程究竟需要多少内存?

由于namenode会在内存中维护所有文件的每个数据块的引用,因此 namenode很可能会“吃光”分配给它的所有内存。很难套用一个公式来精确计算内弁需求量,因为存需求量取决于多个因素,包括每个文件包含的数据块数、文件名称的在度、文件系统中的目录数等。此外,在不同 Hadoop.本下,namenode的内存需求也不相同。

1000 MB内存(默认配置)通常足够管理数百万个文件。但是根据经验来看,保守估计需要为每1百万个数据块分配1000 MB内存空间。

以一个含200节点的集群为例,假设每个节点有4 TB磁盘空间,数据块大小是128 MB,复本数是3的话,则约有2百万个数据块(甚至更多): 200×4 000 000 MB/(128MBx3)。因此,在本例中,namenode 的内存空间 最好一开始设为2000 MB

也可以只增加namenode的内存分配量而不改变其他Hadoop守妒进程的内存分配,即设置hadoop-env.sh文件的HADOOP_NAMEMODE_OPTS属性包含一个JVM选项以设定内存大小。HADOOP_NAMENODE_OPTS允许向 namenodeJVM传递额外的选项。以SunJVM为例,-Xmx2000m选项表 示为namenode分配2000 MB内存空间

由于辅助namenode的内存需求量和主namenode差不多,所以一旦更改 namenode的内存分配的话还需对辅助namenode做相同更改(使用 HADOOP_SECONDARYNAMENODE_OPTS 变量)。在本例中,辅助 namenode—般与主namenode运行在不同机器上。


此外,也存在设置其他Hadoop守护进程的响存分配量的环境变量。用户 可以利用这些变量更改特定守护进程的内存分配量。详见hadoop-env.sh文件。

2.Java

需要设置Hadoop系统的Java安装的位置。方法一是在hadoop-env.sh文件 中设置JAVA_H0ME项;方法二是在shell中设置JAVA_H0ME环境变量。相比之下,方法一更好,因为只需操作一次就能够保证整个集群使用同一版本的Java。

3.系统日志文件

默认情况下,Hadoop生成的系统日志文件存放在$HADOOP_INSTALL/logs目录之中,也可以通过hadoop-env.sh文件中的HAD00P_L0G_DIR来进行修改。建议修改默认设置,使之独立于Hadoop的安装目录。这样的话,即使 Hadoop升级之后安装路径发生变化,也不会影响日志文件的位置。通常可以将日志文件存放在目录中。实现方法很简单,就是在hadoop-env.sh中加入以下一行:

   export HAD00P_L0G_DIR=/var/log/hadoop

如果日志目录并不存在,则会首先创建该目录(如果操作失败,请确认 Hadoop用户是否有权创建该目录)。运行在各台机器上的各个Hadoop守护 进程会产生两类日志文件。第一类日志文件(以.log作为后缀名)是通过 log4j记录的。鉴于大部分应用程序的日志消息都写到该日志文件中,故障诊断的首要步骤即为检查该文件。标准的Hadoop log4jj配置采用日常滚动文件后缀策略(Daily Rolling File Appender)来命名日志文件(即:首先设定一个日期模式,例如“yyyy-mm-dd”;在某一天产生的日志文件就在名称前缀后面添加一个遵循日期模式的后缀名)。系统并不自动删除过期的日志文 件,而是留待用户定期删除或存档,以节约本地磁盘空间。

第二类日志文件后缀名为.out,记录标准输出和标准错误日志。由于 Hadoop使用log4j记录日志,所以该文件通常只包含少量记录,甚至为空。重启守护进程时,系统会创建一个新文件来记录此类日志。系统仅保留最新的5个日志文件。旧的日志文件会附加一个介于15之间的数字 后缀,5表示最旧的文件。

日志文件的名称(两种类型)包含运行守护进程的用户名称、守护进程名称和本地主机名等信息。例如,hadoop-tom-datanode-sturges.ocal.log.2008-07-04就是一个日志文件的名称。这种命名方法保证集群内所有机器的日志文 件名称各不相同,从而可以将所有日志文件存到一个目录中。

日志文件名称中的“用户名称”部分实际对应hadoop-env.sh文件中 的HADOOP_IDENT_STRING项。若想采用其他名称,可以修改 HADOOP_IDENT_STRING 项。

4.SSH设置

借助SSH协议,用户在主节点上使用控制脚本就能在(远程)工作节点上运 行一系列指令。自定义SSH设置会带来诸多益处。例如,减小连接超时设定(使用ConnectTimeout选项)可以避免控制脚本长时间等待宕机节点的响应。当然,也不可设得过低,否则会导致繁忙节点被跳过。

StrictHostKeyChecking也是一个很有用的SSH设置。设置为no会自动将新主机键加到已知主机文件之中。该项的默认值是ask,提示用户确认 是否已经验证了“键指纹”(key fingerprint),因此不适合大型集群环境®

在hadoop-env.sh文件中定义HADOOP_SSH_OPTS环境变量还能够向SSH传递更多选项。参考sshssh_config手册,了解更多SSH设置。

利用rsync工具,Hadoop控制脚本能够将配置文件分发到集群中的所有节点。默认情况下,该功能并未启用!为了启用功能,需要在hadoop-env.sh文件中定义HADOOP_MASTER项。工作节点的守护进程启动之后,会把以 HADOOP_MASTER为根的目录树与本地的HADOOP_INSTALL目录同步。

如果Hadoop系统的两个主进程(namenodejobtracker)分别运行在不同机器上,该如何执行上述操作?可以任选一台机器为源,另一台机器就能 够像其他工作节点一样通过rsync工具进行同步。实际上,任意一台机器均 可作为rsync的源,即使该机器处在Hadoop集群外部。

在默认情况下并未设置HADOOP_MASTER项,这就引发一个问题:如何确保每个工作节点的文件已经设置好HADOOP_MASTER?对于小型 集群来说很容易解决:编写一个脚本文件,将主节点的心办印文件 复制到所有工作节点即可。对于大型集群来说,既可以采用dsh之类的工具来复制文件,也可以将hadoop-env.sh文件作为自动安装脚本的一部分(例如 Kickstart)

考虑一个已经启用远程同步功能的大型集群。当集群启动时,所有工作节点几乎同时启动,并向主节点发出rsync请求,很可能导致主节点瘫痪。为了避免发生这种情况,需要将HADOOP_SLAVE_SLEEP项设为一小段时间, 例如0.1(表示0.1秒钟),使主节点在相继调用两个工作节点的指令的间隙主动休眠一段时间。

转载请注明:全栈大数据 » 9.4.2 环境设置

喜欢 (0)or分享 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址