This website requires JavaScript.

Hadoop 性能优调

本文为Cloudera CDH 官方性能管理系列文章的翻译

Optimizing Performance in CDH

本节提供了一些性能问题的解决方案,并描述了配置的最佳实践。

重要:与您的网络管理员和硬件供应商联系以确保你有适当的网卡固件,驱动程序。并且进行恰当配置。Cloudera认为网络安装和升级是具有挑战性的问题,并将尽力分享有用的经验。

继续阅读:

屏蔽Transparent Hugepage Compaction

CDH5支持的大多数Linux系统都支持一个叫做transparent hugepage compaction特性。该特性会导致Hadoop的工作负载和性能会严重降低。

症状: top或其他系统监控工具显示了system CPU这个类别的CPU处理耗用很大。如果system CPU使用>=30%则你的系统可能会遇到这个问题。

怎么做:

**注意:**接下来的指导中defrag_file_pathname的路径取决于你所用的系统: •Red Hat/CentOS: /sys/kernel/mm/redhat_transparent_hugepage/defrag •Ubuntu/Debian, OEL, SLES: /sys/kernel/mm/transparent_hugepage/defrag

1.要确认transparent hugepage compaction是否开启,请通过以下命令查看:

$ cat defrag_file_pathname

 · [always] never 表示transparent hugepage compaction被启用  · always [never] 表示transparent hugepage compaction未被启用

2.要关闭 transparent hugepage compaction,将一下命令加入/etc/rc.local:

echo never > defrag_file_pathname

你也可以直接在Shell中关闭transparent hugepage compaction,不过要注意重启以后就失效了

使用root权限临时关闭transparent hugepage compaction

# echo 'never' > defrag_file_pathname

使用sudo权限临时关闭transparent hugepage compaction

$ sudo sh -c "echo 'never' > defrag_file_pathname"

设置vm.swappiness(Setting the vm.swappiness Linux Kernel Parameter)

Linux内核参数vm.swappiness的值范围为0-100.主要用来把内存中应用数据存到磁盘上的虚拟内存中。值越高,交换的越频繁,反之亦然。

在大多数系统中vm.swappiness默认设置为60。这个设定并不使用Hadoop群集,因为即使内存足够,进程有时也会进行内存交换。这会导致冗长的垃圾收集致使重要系统守护进程卡顿,影响性能和稳定性。

Cloudera建议将vm.swappiness设置为1~10之间,最好设置为1(最小交换).

查看当前vm.swappiness的设置,运行:

cat /proc/sys/vm/swappiness

设置 vm.swappiness 为1,运行:

sudo sysctl -w vm.swappiness=1

注意: 之前Cloudera建议把 vm.swappiness 设置为0,在Linux内核3.5-rc1 (fe35004f)有个改动,会导致OOM(frequent out of memory)错误。更多信息请查看Evan Klitzke的博文 ,这个被backport到了 RHEL / CentOS 6.4Ubuntu 12.04 LTS(长期维护版)

改善Shuffle操作及IFile性能(Improving Performance in Shuffle Handler and IFile Reader)

MapReduce shuffle handler 及 IFile reader 使用原生Linux调用(posix_fadvise(2)sync_data_range)

Shuffle Handler

你可以通过启用shuffle预读(shuffle readahead)来提供MapReduce shuffle的性能。这使得TaskTracker或Node Manager在它被传送给reducer之前就可以预先读取map输出。

  • 为YARN启用, 设置mapreduce.shuffle.manage.os.cache为true (默认). 可以修改mapreduce.shuffle.readahead.bytes.进行调优,默认值为4 MB.
  • 为MapReduce启用,设置mapred.tasktracker.shuffle.fadvise为true (默认).可以修改 mapred.tasktracker.shuffle.readahead.bytes.进行优调,默认值为4 MB.

IFile Reader

启用 IFile 预读可以增加合并操作的性能,MRv1或YARN中启用它, 设置mapreduce.ifile.readahead为true (默认). 可以修改mapreduce.ifile.readahead.bytes进行优调,默认值为 4MB.

MapReduce配置最佳实践(Best Practices for MapReduce Configuration)

下面介绍的配置设置可以减少MapReduce执行的固有延迟。你可在mapred-site.xml设置这些值。

当任务完成时就发心跳

设置mapreduce.tasktracker.outofband.heartbeat为ture。当任务完成的时候TaskTracker会发送‘外带心跳’来减少延迟。默认值为false

<property>
    <name>mapreduce.tasktracker.outofband.heartbeat</name>
    <value>true</value>
</property>

减少对单节点系统jobclient状态报告间隔

jobclient.progress.monitor.poll.interval 属性定义了Jobclient报告向中断报告状态及检查job是否完整的间隔时间(毫秒)。把这个值设低可以提升单节点测试的速度。在大群集中调整这个值可能导致不必要的服务器-客户端流量。

<property>
    <name>jobclient.progress.monitor.poll.interval</name>
    <value>10</value>
</property>

调整JobTracker心跳间隔

将TaskTracker到JobTracker的最小心跳间隔调小,可以提高小群集中MapReduce的性能。

<property>
    <name>mapreduce.jobtracker.heartbeat.interval.min</name>
    <value>10</value>
</property>

立即启动MapReduce JVM

The mapred.reduce.slowstart.completed.maps property specifies the proportion of Map tasks in a job that must be completed before any Reduce tasks are scheduled. For small jobs that require fast turnaround, setting this value to 0 can improve performance; larger values (as high as 50%) may be appropriate for larger jobs.

mapred.reduce.slowstart.completed.maps属性指定多少比率的Map任务需要在Reduce任务计划之前完成,对于需要快速转换的小Job,将此值设置为0可以提高性能;更大的值(高达50%)适当的大job

<property>
    <name>mapred.reduce.slowstart.completed.maps</name>
    <value>0</value>
</property>

Job的最佳技巧和实践

本节所述的内容你可以在job层级修改

使用分布式缓存来传输JAR

使用分布式缓存来传送job JAR比使用JobConf(Class)构造器和 JobConf.setJar() 、JobConf.setJarByClass() 方法要好.

把JAR包添加到classpath, 使用-libjars jar1,jar2. 这个会把本地JAR文件拷贝到HDFS然后通过分布式缓存机制确保每个任务节点都可以访问

The advantage of this, over JobConf.setJar, is that if the JAR is on a task node, it does not need to be copied again if a second task from the same job runs on that node, though it will still need to be copied from the launch machine to HDFS.

这样做的好处是相比jobconf.setjar如果JAR在任务节点,如果在这个节点上有第二个同样job不需要被再次复制,虽然它还需要从HDFS复制。

Note: -libjars 只有使用ToolRunner的情况下才起作用. 否则你需要使用分布式缓存 (Cloudera 不推荐)

更多信息,请看博客How to Include Third-Party Libraries in Your MapReduce Job里面的item 1

修改Job的日志级别 (MRv1)

你可以针对个别Job修改日志级别。在job配(JobConf)设置以下属性。

  • mapreduce.map.log.level
  • mapreduce.reduce.log.level

有效值 NONE, INFO, WARN, DEBUG, TRACE, All

例子:

JobConf conf = new JobConf();
...

conf.set("mapreduce.map.log.level", "DEBUG");
conf.set("mapreduce.reduce.log.level", "TRACE");
...

Choosing and Configuring Data Compression

对于压缩的概述,请参见Data Compression

压缩类型指导

  • GZIP比Snappy和LZO占用更多CPU资源,但是提供了高压缩比。对于冷数据来说Gzip非常适合,因为访问频次低。Snappy及LZO适合经常访问的热数据。
  • BZip2的压缩比对一些文件的压缩比比GZIP还要高,但是需要压缩解压的时候需要更多的时间成本。HBase不支持Bzip2压缩。
  • Snappy通常优于LZO。值得你做一些测试来查看差异。
  • 对于MapReduce,如果你希望你压缩的数据可以被分割,那么使用BZip2和LZO格式。Snappy和GZip块无法分割,不过,Snappy块里面的文件是SequenceFileor Avro格式就可以被分割。 Snappy最好用SequenceFiles或者Avro数据文件,如果直接用文本文件,因为无法分割的关系,MapReduce没法并行处理。HBase无所谓数据是否可以分割。
  • 对于MapReduce,中间数据及输出数据均可以压缩。调整MapReduce参数即可,以下是压缩中间数据和输出的例子,第一个例子为MR2,后一个是MR1。

 MRv2

hadoop jar hadoop-examples-.jar sort "-Dmapreduce.compress.map.output=true"
"-Dmapreduce.map.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec"
"-Dmapreduce.output.compress=true"
"-Dmapreduce.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec" -outKey
org.apache.hadoop.io.Text -outValue org.apache.hadoop.io.Text input output

 MRv1

hadoop jar hadoop-examples-.jar sort "-Dmapred.compress.map.output=true"
"-Dmapred.map.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec"
"-Dmapred.output.compress=true"
"-Dmapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec" -outKey
org.apache.hadoop.io.Text -outValue org.apache.hadoop.io.Text input output

数据压缩配置

使用Cloudera Manager进行数据压缩配置

要使得Cloudera Manager支持LZO,你必须安装GPL扩展包,然后进行配置使用。具体请查看Installing the GPL Extras ParcelConfiguring Services to Use the GPL Extras Parcel

使用命令行进行数据压缩配置

重要: • 如果你使用Cloudera Manager,就不要用命令行。 • 以上提示仅限 CDH 5.9.x. 如果你用的是低版本CDH,请查看相关文档Cloudera Documentation.

在CDH中配置LZO请查看Step 5: (Optional) Install LZOConfiguring LZO。CDH直接支持Snappy。

在MapReduce中使用Snappy请查看Using Snappy with MapReduce LZO的使用方法是一样的,用com.hadoop.compression.lzo.LzopCodec代替即可。

Tuning Hive

Hive组件堆大小及垃圾收集

本节介绍如何调整HiveServer2和Hive Metastore的内存和垃圾回收属性。

内存建议

HiveServer2和Hive Metastore需要足够的内存才能正常运行。 每个组件的默认堆大小为256 MB不足以用于生产工作负载。 考虑以下准则,根据您的集群大小调整每个组件的堆大小。

并行数量HiveServer2 Heap
最小建议
Hive Metastore Heap
最小建议
40个并发连接(当HiveServer2
内存设置大于12G时,Cloudera
建议您将HiveServer2拆分为多个
实例进行负载平衡。目的是减小
Java垃圾回收对服务进程的影响。
12 GB12 GB
20个并发连接6 GB10 GB
10个并发连接4 GB8 GB
单一连接2 GB4 GB

**重要信息:**这些数字仅供一般参考,可能受列数,分区数,复杂join和客户端活动等因素的影响。 建议您部署前多做测试来调整改进,以为您的环境获得最佳配置。

另外,如果你使用Beeline命令行,那么heap大小至少要2GB。

permGenSize 需要设置为512M

配置堆大小及垃圾回收

要配置HiveServer2和Hive metastore的堆大小,如果使用Cloudera Manager请在Hive-env.sh的advanced configuration snippet中配置HADOOP_OPTS变量-Xmx参数,设置为所需的最大堆大小。否则编辑/etc/hive/hive-env.sh文件。

要配置Beeline CLI的堆大小,请在Cloudera Manager hive-env.sh advanced configuration snippet中设置HADOOP_HEAPSIZE变量或者直接在/etc/hive/hive-env.sh中设置

以下示例进行下列配置:

  • HiveServer2堆12GB
  • Hive metastore堆12GB
  • Hive clients堆2GB

设置修改了下面文档中-Xmx12288m及HADOOP_HEAPSIZE=2048部分,默认情况下,下面的行都被注释掉(前缀为#字符)。 通过删除#字符取消注释行。

if [ "$SERVICE" = "cli" ]; then
if [ -z "$DEBUG" ]; then
    export HADOOP_OPTS="$HADOOP_OPTS -XX:NewRatio=12 -Xmx12288m -Xms10m -XX:MaxHeapFreeRatio=40 -XX:MinHeapFreeRatio=15 -XX:+useParNewGC -XX:-useGCOverheadLimit"
else
    export HADOOP_OPTS="$HADOOP_OPTS -XX:NewRatio=12 -Xmx12288m -Xms10m -XX:MaxHeapFreeRatio=40 -XX:MinHeapFreeRatio=15 -XX:-useGCOverheadLimit"
fi
fi

export HADOOP_HEAPSIZE=2048

您可以通过在上面的HADOOP_OPTS行中使用-XX:+useParNewGC或-XX:+useConcMarkSweepGC来进行并发和垃圾回收控制,也可以通过设置-XX:-useGCOverheadLimit来优化垃圾回收限制,要启用垃圾回收限制,请删除设置或将其更改为-XX:+ useGCOverheadLimit。

表分区

提示: Cloudera建议表的分区少于2至3千以确保性能

当Hive查询引用超过几千个分区时,性能可能会受到影响。查询必须通过Hive Metastore数据库以检索和更新这些分区,并且HDFS必须移动这些文件。

为了获得最佳性能,请为较少列的表进行分区,或者采用粗粒度的时间范围,例如按天而不是按小时。 此外,查询中尽量限定为分区的子集。

在Amazon S3上优化Hive写入性能

Tuning Hive on Spark

最小需求权限: Configurator(Cluster Administrator, Full Administrator也可以)

Hive on Spark 与 Hive on MapReduce 在同样features的情况下提供了更好的性能。运行Hive on Spark不需要修改用户的查询语句,原先的UDF( user-defined functions)也支持。而且多数性能相关的配置也是相似的。

本篇主要介绍如何优化Hive on Spark的性能。我们架设你的群集由Cloudera Manager管理,并且你用YARN作为Spark的群集管理器。

以下示例以40个YARN运算节点,每个节点32核,120G内存进行配置。

YARN配置

YARN的yarn.nodemanager.resource.cpu-vcores 以及yarn.nodemanager.resource.memory-mb属性决定了Hive on Spark(或者其他YARN应用)可以使用的资源。这两值的设定取决于你节点的性能和非YARN应用跑在这些节点上的数量。一般来说工作节点只安装YARN NodeManager和HDFS DataNode 服务

内核配置

每个服务分配1核,另外给系统用2核,剩下的28核都给YARN。

yarn.nodemanager.resource.cpu-vcores=28

内存配置

20G内存分配给服务和系统使用,剩余的都分配给YARN。

yarn.nodemanager.resource.memory-mb=100 GB

更多YARN的优化文档请查看Tuning YARN

Spark 配置

分配好YARN的资源以后你需要对Spark的executor和driver的内存,并行数量等进行配置。

配置Executor内存

Spark executor 配置的描述可以参考Configuring Spark on YARN Applications

设置executor内存的时候考虑以下因素:

  • executor的内存越多,查询的map join就越快,不过这样会导致内存回收压力增加。
  • 在executor内核分配过多的情况下有可能导致HDFS客户端并发写入性能下降。

为使最小化未使用内核,Cloudera建议把spark.executor.cores 设置为 4,5或6 这取决于你分配给了YARN多少内核。

因为28核可被4整除,所以设置spark.executor.cores=4,如果设置为6则会有4个内核未使用,同理设置为5则有3个内核未使用.spark.executor.cores设置为4的时候最多可并行的executor为7(28/4) .内存总数除以executor数量,则每个executor可用14G内存 (100/7)

一个executor可使用的总内存为spark.executor.memoryspark.yarn.executor.memoryOverhead之合 .Cloudera建议设置spark.yarn.executor.memoryOverhead为总内存的15-20% . 按照本例来说spark.executor.memoryOverhead=2 G spark.executor.memory=12 G.

以上配置表示,每个host可以运行7个executor,每个executor可以运行4个task(每个内核一个) .然后每个任务平均可使用内存3.5GB(14/4) 同一个executor运行的tesk共享heap space.

注意:确保spark.executor.memoryOverhead和spark.executor.memory总数小于yarn.scheduler.maximum-allocation-mb

配置Driver内存

你也需要配置Spark driver的内存:

  • spark.driver.memory 每个Spark dirver的最大运行内存
  • spark.yarn.driver.memoryOverhead 每个driver的额外堆的可从YARN获得的堆内存。这个加上spark.driver.memory 是YARN可以用来创建一个driver 的JVM的总内存。

虽然Spark driver内存不直接影响性能,但是让job跑在driver不受内存约束还是很好的.可以根据以下yarn.nodemanager.resource.memory-mb的值来计算.

  • 超过50G设置为12G
  • 12G至50G之间设置为4G
  • 1G至12G之间设置为1G
  • 少于1G设置为256M

同样的spark.yarn.driver.memoryOverhead也应该是总数的10-15% .这个例子中yarn.nodemanager.resource.memory-mb=100GB, 所以总内存可以设置为12GB .也就是说 spark.driver.memory=10.5 GB spark.yarn.driver.memoryOverhead=1.5 GB

Executor 数量的选择

executor的数量取决于每个host的executor数量以及整个群集工作节点的数量. 如果你的群里面有40个工作节点. 那么最大的executor数量为160(40*4) (实际会少点,比如本例中driver要占一个内核和12G内存)当然这是指没有其他YARN应用运行的情况下。否则要视情况而定。

Hive的性能直接跟查询所用executor的数量有关。不过每个查询都是不一样的,一般情况下性能与executor的数量成正比,比如使用4个executor要比2个快一倍。然而性能到达一定峰值以后再增加executor就没用了,有些情况下,甚至性能会降低。

大多数情况下,使用一般的群集计算能力就可以提供很好的性能支持.要达到最大性能,我们可以设定可用executor的数值. 在我们的案例中可以把spark.executor.instances设置为160

动态Executor分配

虽然设置spark.executor.instances可以最大程度榨干性能,但是在生产环境中(多用户查询的情况下) 并不建议这样操作.应避免对一个session设置固定的executor数量。因为空闲的executor是无法被其他用户使用的。在正式环境需要拟订资源共享计划。

Spark 允许你动态分配群集资源, 开启动态分配,请参考Dynamic Allocation .除了某些情况 ,Cloudera强烈建议开启动态分配

并行

想要executor被充分利用,那就需要足够多的task并行执行,多数情况下Hive会自动帮你确定并行的数量,不过你也可以做一些优化。在数据输入阶段,Map Task的数量等同你输入数据被切分的数量。例如在 Hive on Spark,输入的数据格式为CombineHiveInputFormat,可以根据需要将输入的数据进行分组分割。你以用‘取巧’的方式控制并行。调整hive.exec.reducers.bytes.per.reducer来控制每个reducer处理数据的数量,然后Hive就会根据可用的executor,executor内存设置等优化分区数量。 实验下来当足够的task生成以后,Spark对hive.exec.reducers.bytes.per.reducer的设置就不怎么敏感了(相对MapReduce)。为了优化性能,我们可以设置一个值来让Hive生成足够的Task充分利用可用的exector。

更多信息可以查看Tuning Spark Applications

Hive 配置

Hive on Spark 与Hive本身相关的性能配置大多是一致的. 你做的设置其实与MapReduce没多大区别.不过hive.auto.convert.join.noconditionaltask.size  可能会成为map join的性能瓶颈,影响会很大.虽然这个配置Hive on MapReduce 和Hive on Spark都有,但是他们的意思是不同的.

size数据描述为两部分统计:

  • totalSize -- 数据在磁盘上的大小
  • rawDataSize -- 数据在内存中的大小

Hive on MapReduce使用totalSize,当他们都使用的时候Hive on Spark使用rawDataSize.因为压缩以及序列化,同一个数据集的totalSize和rawDataSize 的差异可能是巨大的.  对于Hive on Spark,你可能需要指定一个大数值来设置hive.auto.convert.join.noconditionaltask.size 来进行join map的转换.当然这个值设置的过高可能导致小表占用了大量内存。然后task因为内存益处而失败。根据你的群集调整大小吧。

你可以设置属性hive.stats.collect.rawdatasize控制rawDataSize统计是否会被回收。(Cloudera 建议在Hive中设置为ture,默认是开启的)

Cloudera 还建议建议在advanced configuration snippet for HiveServer2 里面开启以下两个属性

  • hive.stats.fetch.column.stats=true
  • hive.optimize.index.filter=true

下面的属性也是建议开启的,虽然他们并非针对Hive on Spark

hive.optimize.reducededuplication.min.reducer=4
hive.optimize.reducededuplication=true
hive.merge.mapfiles=true
hive.merge.mapredfiles=false
hive.merge.smallfiles.avgsize=16000000
hive.merge.size.per.task=256000000
hive.merge.sparkfiles=true
hive.auto.convert.join=true
hive.auto.convert.join.noconditionaltask=true
hive.auto.convert.join.noconditionaltask.size=20M(might need to increase for Spark, 200M)
hive.optimize.bucketmapjoin.sortedmerge=false
hive.map.aggr.hash.percentmemory=0.5
hive.map.aggr=true
hive.optimize.sort.dynamic.partition=false
hive.stats.autogather=true
hive.stats.fetch.column.stats=true
hive.compute.query.using.stats=true
hive.limit.pushdown.memory.usage=0.4 (MR and Spark)
hive.optimize.index.filter=true
hive.exec.reducers.bytes.per.reducer=67108864
hive.smbjoin.cache.rows=10000
hive.fetch.task.conversion=more
hive.fetch.task.conversion.threshold=1073741824
hive.optimize.ppd=true

预热 YARN Containers

当你在一个新的会话提交查询的时候首次运行你会等待很长时间才开始执行查询,然后你执行发现它比原来执行的块.

这是因为Spark executor需要额外的时间来初始化Spark on YARN集群,因此导致很大延迟,实际上Spark不会等所有executor全部准备妥当才执行.然而job启动时候executor的多上很大程度上会决定reducer的数量.当准备好的executor没到达最大值,job可能就不是最大并发的运行.这会影响job的性能.

如果一个Session时间很长,那么这个影响可能不大因为只是第一次查询的时候需要初始化.但是job比较短的话.就会有很大影响,比如在Oozie中.

为了减少启动时间你可以设置以下属性:

设置hive.prewarm.enabled=ture 来开启预热,同时你可以可以设置预热数量 hive.prewarm.numcontainers ,默认为10

具体预热的executor受限于spark.executor.instances (static allocation)或spark.dynamicAllocation.maxExecutors (dynamic allocation) ,hive.prewarm.numcontainers 不应该超过允许用户会话数量.

**注意:**虽然对于短时间的会话预热的效果不错.但是hive.prewarm.numcontainers的值不要超过实际群集的可用数量,否则可能会多花30秒的时间.

Tuning the Solr Server

Tuning Spark Applications

YARN 优化(Tuning YARN)

该主题只适用于YARN管理的群集,为大家介绍YARN群集的优化配置。

你可以下载YARN优化表来帮你计算优化配置,还有一个YARN视频也可以参考。

概览(Overview)

这里对YARN优化的配置项进行了简单描述和指导。

YARN由许多主机组成。主机提供内存和CPU资源 yarn_host_memory_vcores

调优YARN主要包括在工作主机上优化容器(container)。 你可以把容器看成一个由内存和vcores组成的矩形图。 容器执行任务。 yarn_container

某些任务使用大量内存,对大量数据处理资源较少。 yarn_memory_intensive

其他任务需要大量的处理能力,但使用更少的内存。 例如,蒙特卡罗模拟评估许多可能的“如果”?的场景在相对较小的数据集上需要使用大量的计算资源。 yarn_vcore_intensive

YARN的ResourceManager以尽可能最有效的方式使用所有可用资源。 理想状态下很少或没有资源被闲置。 yarn_resource_manager

应用程序是由包含一个或多个任务的YARN客户端程序组成的。 通常,任务使用容器中的所有可用资源。 任务不能消耗多于其指定分配的资源,确保它不能使用所有主机CPU资源或超过其内存分配。 yarn_mapreduce_task

调整您的YARN主机以优化CPU和内存的使用,方法是‘满负荷’配置容器

xyarn_optimized_host

YARN调优有三个方面,对应YARN调优表

1.群集配置,配置各主机 2.YARN配置,配置内存和CPU资源 3.MapReduce配置,为每个map和reduce任务分配最大和最小资源。

YARN和MapReduce有许多配置属性,完整列表请查看Cloudera Manager Configuration Properties YARN优化表只是其中一部分,主要用来改善常规MapReduce程序的性能。

群集配置(Cluster Configuration)

在“Cluster Configuration”选项卡中,您可以YARN配置工作节点和集群大小。

Step 1: 计算节点配置

Step 1 用来配置单个计算节点。 xyarn_step_1_worker_config

与任何系统一样,可用的内存和CPU资源越多,集群可以处理大量数据的速度就越快。 图中具有8个CPU,每个CPU有6个内核,每个主机48个核心。

2U的服务器上有12个槽装满了3TB的磁盘(JBOD),该表格创建的时候这样配置是根据性能和价格的平衡而得。现在磁盘的成本更低,所以你可以考虑4TB的磁盘。不过大的磁盘更贵而且不一定适合所有使用场景。

文档发布的时候1G的网卡对吞吐量是够用的,如果成本降下来10G的网卡也可以作为选择。

Step 2: 计算节点计划

Step 2 用来配置每个计算节点的资源

操作系统至少占用8G内存,CM需要1G,如果除了CDH之外还有其他服务,则需要增加相应的资源。

HDFS DataNode 至少使用1个核心和1G内存,同YARN NodeManager一样。

表格中有三个可选服务,Impala至少需要16G内存,HBase RegionServer需要12-16G内存,Solr服务器至少需要1G内存。

剩下的资源可以归YARN应用程序使用 (Spark and MapReduce). 本例中有 44 CPU 核心可用, 记得设置每个核心的并发线程。(Physical Cores to Vcores Multiplier)

Step 3: 群集规模

在您的集群中定义了每个主机的规格,请输入支持您的业务案例所需的计算节点的数目。要获得并行计算的好处,请将主机的数量至少设置为10。

xyarn_step_3_cluster_size

YARN 配置

在YARN Configuration页面,验证你可分配的资源,并且设置每个container的最小最大资源限制。

Step 4 & 5:检查设置

Step 4 两个属性的值直接引用了Step 2 中内存和CPU的剩余资源。 Step 5 为整个群集内存和CPU资源。

xyarn_steps_4_5_verify_settings

Step 6: 验证群集上容器的设置

在这个步骤中,你可以修改4个属性以影响容器的大小。

最小虚拟核心应该设为1,需要的时候一次增加一个是比较有效的分配方式。设置最大虚拟内核数量,确保不会被耗用所有资源。

同样的内存最小设置为1G,最高8G,每次增加512M。

xyarn_step_6_verify_container_settings

Step 6A: 集群容器容量

Step 6A 根据你之前填写的数字让你查看一下群集中最小及最大容器数量。

xyarn_step_6a_cluster_container_capacity

Step 6B: 容器配置检查

查看你的容器配置是否正确。

xyarn_step_6b_container_sanity_checking

MapReduce 配置

Step 7: MapReduce 配置

你可以增加对applicationmaster,map 任务,reduce任务的内存分配。每个任务的最少使用内核总归为1. Spill/Sort 内存分配为256应该是足够的,如果你觉得频繁的存储到硬盘导致性能降低,可以适当的增加一点。

xyarn_step_7_mapreduce_configuration

Step 7A: MapReduce 配置检查

基本上避免一些逻辑错误。 xyarn_step_7a_mapreduce_sanity_checking

在Cloudera Manager中配置你的群集属性。

当你完成群集配置评估以后可以根据表格中的属性在Cloudera Manager中进行配置。 配置方式请查看使用Cloudera Manager修改配置属性

在 CDH 5.5 及以上版本 mapreduce.map.java.opts, mapreduce.reduce.java.opts, yarn.app.mapreduce.am.command-opts 这几个属性会自动根据容器的大小进行配置

参考

linux系统swappiness参数在内存与交换分区间优化 Performance Management Spark On YARN内存分配 Spark配置参数 YARN的内存和CPU配置 YARN 设计理念与基本架构

0条评论
avatar