hadoop 集群优化
1.系统参数调整
| 中文名称 | 英文名称 | 默认值 | 推荐值或推荐策略 | 修改命令 | 作用 | 备注 |
| socket的监听队列最大值 | net.core.somaxconn | 128 | 1024或更大 | echo 1024 >/proc/sys/net/core/somaxconn | 增大打开文件数据和网络连接上限，调整内核参数net.core.somaxconn，提高读写速度和网络带宽使用率 | 如果是hadoop使用，需重启hadoop才能有效，并且要配合hadoop集群参数ipc.server.listen.queue.size使用才有效 |
| 读取不更新文件atime属性 | noatime | noatime | vi /etc/fstab #/dev/data1 / ext4 defaults,noatime 0 0 mount -o remount /dev/data1 |
当以noatime选项加载（mount）文件系统时，对文件的读取不会更新文件属性中的atime信息。设置noatime的重要性是消除了文件系统对文件的写操作，文件只是简单地被系统读取。 | ||
| 磁盘预读缓存区大小 | blockdev --getra /dev/sda | 256 | 2048或更大 | blockdev --setra 2048 /dev/sda | 预读可以减少磁盘寻道次数和I/O等待时间 | 执行命令只对一块磁盘有效，需执行多次，且重启系统后失效 |
| 系统IO调度器 | IO Scheduler | cfq | deadline | echo deadline > /sys/block/sda/queue/scheduler | DEADLINE在CFQ的基础上，解决了IO请求饿死的极端情况。除了CFQ本身具有的IO排序队列之外，DEADLINE额外分别为读IO和写IO提供了FIFO队列。读FIFO队列的最大等待时间为500ms，写FIFO队列的最大等待时间为5s。FIFO队列内的IO请求优先级要比CFQ队列中的高，，而读FIFO队列的优先级又比写FIFO队列的优先级高。优先级可以表示如下： FIFO(Read) > FIFO(Write) > CFQ |
查看命令： cat /sys/block/sda/queue/scheduler |
| epoll文件描述符上限 | fs.epoll.max_user_watches | 27054714 | 270547140 | echo /proc/sys/fs/epoll/max_user_watches | 单个用户使用epoll进行watch的文件描述符上限。 note(dirlt)：对于服务器应该特别有用，可以限制内存使用量 | 查看命令： sysctl -a |grep epoll |
| 设置openfile | ulimit -a |grep 'open files' | 1024 | 65535或更大 | 即时生效： ulimit -n 65535 永久生效： 在/ect/security/limits.conf中添加 * - nofile 65535 * - nproc 65535 |
打开文件描述上限太小，会出现打不开文件的问题 | |
| 系统交换分区 | swap | 开启 | 关闭 | swapoff -a | 如果进程内存不足，系统会将内存中的部分数据暂时写入磁盘，当需要时再将磁盘上的数据动态换置到内存中，这样会降低进程执行效率 | 重新挂载swap分区： swapon -a |
2.hdfs的参数
| 数据块的副本数 | dfs.replication | 3 | 2 | 页面修改 | 减少副本块可以节约存储空间 | |
| SequenceFile I/O 缓存区大小 | io.file.buffer.size | 131072（可以更大） | core-site.xml 的群集范围高级配置代码段（安全阀） | hadoop访问文件的IO操作都需要通过代码库，在很多情况下io.file.buffer.size都被用来设置缓存的大小。不论是对硬盘或者是网络操作来讲，较大的缓存都可以提供更高的数据传输，但这也就意味着更大的内存消耗和延迟。这个参数要设置为系统页面大小的倍数，以byte为单位。 | ||
| .Trash目录下文件被永久删除前保留的时间 | fs.trash.interval | 1440（24小时） | core-site.xml 的群集范围高级配置代码段（安全阀） | |||
| 垃圾回收的检查间隔 | fs.trash.checkpoint.interval | 1440 | core-site.xml 的群集范围高级配置代码段（安全阀） | |||
| 是否启动Hadoop的本地库 | io.native.lib.available | true | core-site.xml 的群集范围高级配置代码段（安全阀） | 本地库可以加快基本操作，例如IO，压缩等。 | ||
| NameNode 处理程序计数 | dfs.namenode.handler.count | 40 | 60 | 页面修改 | 设定 namenode server threads 的数量，这些 threads 會用 RPC 跟其他的 datanodes 沟通。当 datanodes 数量太多时会发現很容易出現 RPC timeout，解決方法是提升网络速度或提高这个值，但要注意的是 thread 数量多也表示 namenode 消耗的内存也随着增加。 | 扩展性相关参数 |
| NameNode 服务处理程序计数 | dfs.namenode.service.handler.count | 100 | 页面修改 | |||
| NameNode的java堆栈大小 | NameNode Java heap size | 90G | 页面修改 | |||
| DataNode的java堆栈大小 | DataNode maximum Java heap size | 16G | 页面修改 | |||
| DataNode 处理程序计数 | dfs.datanode.handler.count | 3 | 50 | |||
| 提前读取的字节数 | dfs.datanode.readahead.bytes | 4M | 64M | 页面修改 | 读取块文件时，DataNode 可以使用 posix_fadvise 系统呼叫将数据显式放入操作系统缓冲区缓存中当前读取器位置之前。这样可以提高性能，尤其是在磁盘高度占用的情况下。该配置指定 DataNode 尝试提前读取的位置比当前读取位置提前的字节数。 | |
| ipc服务监听队列长度 | ipc.server.listen.queue.size | 1024 | 与系统参数net.core.somaxconn保持一致 | core-site.xml 的群集范围高级配置代码段（安全阀） | 增大打开文件数据和网络连接上限，提高hadoop集群读写速度和网络带宽使用率 | |
| 最大传输线程数 | dfs.datanode.max.xcievers | 4096 | 8192 | 页面修改 |
3.yarn的参数
| 日志聚合保留期 | yarn.log-aggregation.retain-seconds | 7 | 2 | 页面修改 | 删除聚合日志前要保留它们多久 | |
| Mapreduce 提交复制 | mapreduce.client.submit.file.replication | 10 | 1 | 页面修改 | mapreduce任务数据的副本数，默认是10，比普通HDFS文件的默认幅本数大很多，可能也是考虑到把输入数据放到更多的DN上，尽可能实现本地数据计算，但会增大数据量，更改为1个副本 | |
| MapReduce产生的中间数据存放目录 | mapred.local.dir | /data/cache1/dfs/mapred/local,/data/cache2/dfs/mapred/local,/data/cache3/dfs/mapred/local,/data/cache4/dfs/mapred/local | 页面修改 | |||
| Map 任务 Java 选项库 | mapreduce.map.java.opts | -Xmx1024M | 页面修改 | jvm启动时的参数，只对java，scala程序有效（相比mapreduce.map.memory.mb要小一点是因为java程序占用内存较少） | ||
| Map 任务内存 | mapreduce.map.memory.mb | 1.5G | 页面修改 | map任务申请的内存 | ||
| Reduce 任务 Java 选项库 | mapreduce.reduce.java.opts | -Xmx2560M | 页面修改 | 同map | ||
| Reduce 任务内存 | mapreduce.reduce.memory.mb | 3G | 页面修改 | 同map | ||
| I/O 排序因子 | mapreduce.task.io.sort.factor | 10 | 100 | 页面修改 | 排序文件时要合并的流的数量。也就是说，在 reducer 端合并排序期间要使用的排序头数量。此设置决定打开文件句柄数。并行合并更多文件可减少合并排序迭代次数并通过消除磁盘 I/O 提高运行时间。注意：并行合并更多文件会使用更多的内存。如 'io.sort.factor' 设置太高或最大 JVM 堆栈设置太低，会产生过多地垃圾回收。Hadoop 默认值为 10，建议使用更高值。 | |
| I/O 排序内存缓冲 (MiB) | mapreduce.task.io.sort.mb | 512M | 页面修改 | 当排序文件时要使用的内存缓冲总量。注意：此内存由 JVM 堆栈大小产生（也就是：总用户 JVM 堆栈 - 这些内存 = 总用户可用堆栈空间）。注意：Cloudera 的默认值不同于 Hadoop 的默认值；默认情况下，Cloudera 使用更大的缓冲，因为现代机器通常有更多的 RAM。 | ||
| 洗牌期间并行传输的默认数量 | mapreduce.reduce.shuffle.parallelcopies | 10 | 50 | 页面修改 | 复制（洗牌）阶段期间 reduce 运行的并行传输的默认数量。此数量应在（节点数 * 每节点 map 时隙数）的平方根与节点数 * 每节点 map 时隙数/2 之间 | |
| JobHistory Server 的 Java 堆栈大小（字节） | 10G | 页面修改 | ||||
| ResourceManager 的 Java 堆栈大小（字节） | 10G | 页面修改 | ||||
| 容器内存 | yarn.nodemanager.resource.memory-mb | 20G | 页面修改 | 每个节点分配给yarn跑任务的内存 | ||
| 容器虚拟 CPU 内核 | yarn.nodemanager.resource.cpu-vcores | 12 | 页面修改 | 每个节点分配给yarn跑任务的cpu | ||
| root队列的所有子队列 | yarn.scheduler.capacity.root.queues | default | 容量调度程序配置高级配置代码段（安全阀） | 目前只配置了default，同时跑的任务多了可以配置不同队列，每个队列占用的的资源可以在这里调控 | ||
| 队列的资源容量占比(百分比)。 | yarn.scheduler.capacity.root.capacity | 100 | 容量调度程序配置高级配置代码段（安全阀） | 系统繁忙时，每个队列都应该得到设置的量的资源；当系统空闲时，该队列的资源则可以被其他的队列使用。同一层的所有队列加起来必须是100%。 | 参考http://www.360doc.com/content/14/0117/15/834950_345972005.shtml，配置集群同时运行的任务数量 | |
| yarn.nodemanager.aux-services | mapreduce_shuffle | yarn-site.xml 的 YARN 服务高级配置代码段（安全阀） | 跑mapreduce的必要参数 | |||
| yarn.nodemanager.aux-services.mapreduce_shuffle.class | org.apache.hadoop.mapred.ShuffleHandler | yarn-site.xml 的 YARN 服务高级配置代码段（安全阀） | 跑mapreduce的必要参数 | |||
| yarn.log-aggregation.retain-check-interval-seconds | 86400 | yarn-site.xml 的 YARN 服务高级配置代码段（安全阀） | 多长时间检查一次日志，并将满足条件的删除（yarn程序的日志可以保存到hdfs，设置存储期限） | |||
| yarn.nodemanager.remote-app-log-dir | /data/logs/hadoop-yarn/apps | yarn-site.xml 的 YARN 服务高级配置代码段（安全阀） | yarn执行程序的日志存放目录 | |||
| JobTracker可以启动的线程数 | mapreduce.jobtracker.handler.count | 10 | 100 | 页面修改 | JobTracker可以启动的线程数 | 暂时不考虑增大，任务增多的时候需要调整此参数 |
| 压缩 Map 输出 | mapreduce.map.output.compress | FALSE | TRUE | 页面修改 | 如已启用，将在将 map 输出发送到网络前对其进行压缩。将是生成的客户端配置的一部分。 | |
| MapReduce Map 输出的压缩编码解码器 | mapreduce.map.output.compress.codec | org.apache.hadoop.io.compress.DefaultCodec | org.apache.hadoop.io.compress.SnappyCodec | 页面修改 | 采用snappy压缩 | |
| 默认启动的reduce数 | mapreduce.job.reduces | 10 | 0.95 or 1.75 multiplied by ( 本次测试使用25 |
页面修改 | 提升reduce并发度 | reduce数量最好自己设置 |
| 单个shuffle可以占用Java 堆栈的百分比上限 | mapreduce.reduce.shuffle.memory.limit.percent | 0.25 | 0.4 | yarn-site.xml 的 YARN 服务高级配置代码段（安全阀） | 每个fetch取到的输出的大小能够占的内存比的大小 | |
| 触发merge的内存百分比 | mapreduce.reduce.shuffle.merge.percent | 0.66 | 0.8 | yarn-site.xml 的 YARN 服务高级配置代码段（安全阀） | 在shuffle阶段期间用于触发merge的Java堆栈百分比 | 暂时不修改 |
| 传输的并行线程数 | mapreduce.tasktracker.http.threads | 40 | 100 | yarn-site.xml 的 YARN 服务高级配置代码段（安全阀） | map和reduce是通过http进行数据传输的，这个是设置传输的并行线程数 | |
| JobTracker MetaInfo Maxsize | mapreduce.job.split.metainfo.maxsize | 10000000 | -1 | 页面修改 | 分割 metainfo 文件的大小上限。JobTracker 将不会尝试读取大于已配置值的分割 metainfo 文件。 | 大量小文件时有效 |
| 最大shuffle连接 | mapreduce.shuffle.max.connections | 0 | 暂不调整 | 页面修改 | 0表示无限子 | |
| 客户端线程计数 | yarn.resourcemanager.client.thread-count | 50 | 100 | 页面修改 | 用于处理应用程序管理请求的线程数量。 | 优先级低 扩展性相关参数 |
| 调度程序线程计数 | yarn.resourcemanager.scheduler.client.thread-count | 50 | 100 | 页面修改 | 用于通过调度器接口处理请求的线程数量。 | 优先级低 扩展性相关参数 |
| 管理客户端线程计数 | yarn.resourcemanager.admin.client.thread-count | 1 | 10 | 页面修改 | 用于处理 ResourceManager 管理接口的线程数量。 | 优先级低 扩展性相关参数 |
| 容器管理器线程计数 | yarn.nodemanager.container-manager.thread-count | 20 | 建议调整为（no. of maximum containers per node）的整数倍 本次不调整 |
页面修改 | 容器管理器使用的线程数，主要用于AM与NM通信。 | 优先级低 |
| 清理线程计数 | yarn.nodemanager.delete.thread-count | 4 | 8 | 页面修改 | 用于清理临时结果的线程数。 | 优先级低 |
1.hbase-env.sh文件
export HBASE_HEAPSIZE=90G（分配给hbase的内存）
export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE -Xmx20g -Xms20g -Xmn8g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70"
export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE -Xmx90g -Xms90g -Xmn30g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70"
(hbase master负责管理工作，不负责具体数据查询，对内存消耗不是特别明显，可以少分配。-XX:+UseConcMarkSweepGC 表示年老代并发收集； -XX:+CMSInitiatingOccupancyFraction表示年老代内存占用超过此比例即开始做CMS，这个参数很重要在JDK 5.0以后此值默认是90 也就是当年老代对内存占用90%以上时，才开始做内存收集，而此时剩余的10%依然接受从年轻代迁移过来的对象，迁移过快，导致年老代heap 100%时，Full GC 即开始，才是会暂停所有的任务，直至Full GC 完成，此时是造成RegionServer 意外退出的元凶，那为了安全起见，在调大堆内存的情况下，将此值降低到一个较低的阀值，减少Full GC的产生，建议此值设70%)
由于cms垃圾回收效果不是很理想，考虑使用g1垃圾回收，在 HBase RegionServer 的 Java 配置选项 中修改（需要删除之前的cms垃圾回收配置）
-XX:+UseG1GC -XX:+UnlockExperimentalVMOptions
-XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=50 -XX:ParallelGCThreads=18 -XX:-OmitStackTraceInFastThrow -XX:+ParallelRefProcEnabled -XX:+PerfDisableSharedMem -XX:-ResizePLAB
-XX:ConcGCThreads=8 -XX:MaxTenuringThreshold=1 -XX:G1HeapRegionSize=32 -XX:G1HeapWastePercent=10
-XX:ConcGCThreads=8 -XX:MaxTenuringThreshold=1 -XX:G1HeapRegionSize=32 -XX:G1HeapWastePercent=10
-XX:G1MixedGCCountTarget=16 参考http://blog.csdn.net/qq_19917081/article/details/54585099，测试的时候可以打印gc日志，观察效果，稳定后不需要打印日志，打印日志配置（
- -Xloggc:$GC_LOG_PATH
- -verbosegc
- -XX:+PrintGC
- -XX:+PrintGCDateStamps
- -XX:+PrintAdaptiveSizePolicy
- -XX:+PrintGCDetails
- -XX:+PrintGCApplicationStoppedTime
- -XX:+PrintTenuringDistribution
- Also recommended is some kind of GC log rotation, e.g.:
- -XX:+UseGCLogFileRotation
- -XX:NumberOfGCLogFiles=5
- -XX:GCLogFileSize=20M
）
2.hbase-site.xml文件
hbase.regionserver.global.memstore.upperLimit：默认值0.4 ，RS所有memstore占用内存在总内存中的upper比例，当达到该值，则会从整个RS中找出最需要flush的region进行flush，直到总内存比例降至该数限制以下，并且在降至限制比例以下前将阻塞所有的写memstore的操作，在以写为主的集群中，可以调大该配置项，不建议太大，因为block cache和memstore cache的总大小不会超过0.8，而且不建议这两个cache的大小总和达到或者接近0.8，避免OOM，在偏向写的业务时，可配置为0.45，memstore.lowerLimit保持0.35不变，在偏向读的业务中，可调低为0.35，同时hbase.regionserver.global.memstore.lowerLimit调低为0.3，或者再向下0.05个点，不能太低，除非只有很小的写入操作，如果是兼顾读写，则采用默认值即可
file.block.cache.size：RS的block cache的内存大小限制，默认值0.25，在偏向读的业务中，可以适当调大该值，具体配置时需试hbase集群服务的业务特征，结合memstore的内存占比进行综合考虑。
hbase.hregion.max.filesize 拆分大小，建议设置大些 10g或者更大
hbase.hregion.majorcompaction：（建议设置为0，写脚本每天凌晨合并，因为major时会触发阻塞，严重影响写入查询）配置major合并的间隔时间，默认为1天，可设置为0，禁止自动的major合并，可手动或者通过脚本定期进行major合并，有两种compact：minor和major，minor通常会把数个小的相邻的storeFile合并成一个大的storeFile，minor不会删除标示为删除的数据和过期的数据，major会删除需删除的数据，major合并之后，一个store只有一个storeFile文件，会对store的所有数据进行重写，有较大的性能消耗。
hbase.master.handler.count：80 master处理线程
hbase.regionserver.handler.count：150 regionserver 处理线程
hbase.hstore.blockingStoreFiles：20 定义storefile数量达到多少时block住update操作。设置过小会使影响系统吞吐率（使吞吐率不高）。建议将该值调大一些，（但也不应过大，经验值是20左右吧。太大的话会在系统压力很大时使storefile过多，compact一直无法完成，扫库或者数据读取的性能会受到影响）
hbase.hstore.compactionThreshold ：5 启动compaction的文件数
hbase.regionserver.thread.compaction.small：2 增加执行compaction的线程数
3.机器层面
echo "deadline" > /sys/block/sdb/queue/scheduler
禁用交换分区