★ FEATURED ARTICLE 有没有发现Hadoop集群上了生产之后跑得慢已经不是新鲜事最怕的是偶尔快、偶尔慢、甚至直接挂。做Hadoop生产调优和做应用性能优化完全是两个思路。应用调优可以靠单点压测反复试集群调优面对的是几十上百台机器的资源博弈一个参数动错可能把整个NameNode拖进Full GC。这篇文章把我这些年做生产集群调优沉淀下来的思路、参数、计算公式和排障经验整理出来适合正在维护线上集群的同学也适合刚接触Hadoop生态、想理解“调优到底在调什么”的人。先给结论调优不是把数字调大而是先给系统找平衡点。1. 生产调优的核心思路别上来就动参数1.1 调优前先回答三个问题我见过不少同学一接手集群第一件事就是打开配置文件把dfs.blocksize改成256MB把mapreduce.map.memory.mb从1GB调到4GB然后满怀期待地跑任务结果更慢了或者Container被频繁kill。这种做法的根源是跳过了“问题定义”。调优之前至少要回答三个问题第一当前瓶颈到底在哪个环节。可以用命令或监控先看top看CPUfree -h看内存iostat -x 1看磁盘IOsar -n DEV 1看网络。如果一台DataNode的磁盘util长期接近100%你却在调NameNode的RPC线程数那方向就错了。第二业务侧的核心诉求是什么。是夜间批量作业必须在两个小时内完成还是交互式查询要求P99延迟可控还是数仓任务对稳定性要求远高于吞吐不同的诉求对应的调优策略完全不同。批量作业可以追求高并发和大块文件交互式任务则要控制调度延迟队列里不能堆太多作业。第三当前集群是否已经到了必须调整配置的程度。很多集群只是偶发性慢把某个节点的坏盘换掉就恢复了。盲目调参不仅掩盖了真实问题还会给后续故障排查制造噪音。调优前的这三问本质上是把“感觉慢”翻译成“慢在哪、为什么慢、要调到什么程度”。没有这个前提后面所有参数都是盲调。1.2 建立性能基线和可量化的目标调优必须有一个“调之前”的数据作为对照。我不止一次遇到这样的情况调完一组参数后凭感觉觉得“好像快了”但没法回答快了10%还是30%。所以基线一定要先打。Hadoop自带的测试工具就够用。HDFS层可以用TestDFSIO测纯读写吞吐MapReduce层可以用TeraSort或TeraGen压全链路。跑之前记录三组指标作业整体耗时、集群CPU平均利用率、内存和磁盘IO的峰值。然后把这组数据当成基线存档。之后每次调参只改变一个变量重新跑同一组作业。建议对比以下维度作业总耗时和分阶段耗时Map阶段、Shuffle阶段、Reduce阶段单个Container的资源利用率NameNode和DataNode的RPC处理延迟磁盘吞吐和网络吞吐任务失败率与容器重试情况我习惯把基线记录在一个固定表格里包含集群规模、文件大小分布、并发数、参数变更、耗时、资源利用率。这样调优不是做感觉而是做实验。1.3 调优的层次和顺序Hadoop生产调优是有层次的顺序比具体参数更重要。我一般按下面这个顺序执行操作系统和JVM层优先。文件句柄、虚拟内存策略、HugePage、JVM堆大小这些是最底层的地基。地基不稳上层参数再花哨也白搭。其次是HDFS层。存储是骨架块大小、副本数、DataNode并发、NameNode内存直接影响所有作业的IO模型。再次是YARN层。资源调度决定一台机器能跑多少任务是并发与稳定性的博弈场。最后才是MapReduce作业层。到了这一层更多是业务和SQL层面的优化比如数据倾斜、小文件合并、压缩算法选择。这个顺序背后是一条原则系统层的改动影响面大作业层的改动影响面小。如果一上来就大改作业参数万一出问题很难定位是作业配置还是底层环境不稳定。而先把底层地基打牢作业层的问题就会暴露得更彻底。2. 操作系统层与JVM层Hadoop生产调优的地基2.1 内核参数不能只调Hadoop自己Hadoop虽然是Java进程但底层离不开文件系统和网络。一个集群是否稳定首先看Linux内核参数是否合理。我见过不少服务器默认的file-max和进程可打开文件数不够一旦并发读写任务增多DataNode就会报Too many open files。生产环境至少要把软硬限制调到一百万以上# /etc/security/limits.conf * soft nofile 1048576 * hard nofile 1048576另一个容易被忽略的是vm.swappiness。默认值通常是60意味着系统在有压力时会积极地把文件页换到swap。对Hadoop这种靠内存缓存和JVM堆做大量状态管理的系统来说换页就是灾难。我会把实时调优时设成1到10之间并在/etc/sysctl.conf里固定vm.swappiness5 vm.max_map_count262144 net.core.somaxconn1024 net.ipv4.ip_local_port_range1024 65535 net.ipv4.tcp_tw_reuse1这里重点说下vm.max_map_count。Java进程尤其是JVM堆比较大时会创建大量内存映射区域。如果这个值按默认的65530走进程可能莫名其妙崩掉错误日志里只看到java.lang.OutOfMemoryError: Map failed实际不是堆内存不够而是系统限制了映射数量。透明大页THP也建议关掉。Hadoop运行期会产生大量短生命周期的对象THP会增加内存分配和释放的延迟尤其在NameNode这种对GC敏感的服务上影响明显。可以这样临时关闭echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag不过重启后会恢复。为了保证持久化需要在启动项或内核引导参数里设置不同发行版方式不一样原则是让集群所有节点保持一致的配置。网络参数上重点调整本地端口范围和连接复用避免高并发下端口不够用、TIME_WAIT过多。这些参数确认完后再去看Hadoop自身的配置才有意义。2.2 NameNode和DataNode的JVM堆怎么给很多人把HADOOP_HEAPSIZE设成“看起来很大”的值这是不对的。NameNode堆大小主要由元数据规模决定不取决于物理内存有多大。一个粗略的经验是每一百万个文件或块对象大约需要1GB左右的堆内存但堆里除了元数据还要给JVM自身、GC留余量所以实际规划要在此基础上再加30%到50%。比如一个集群有3000万个BlockNameNode堆至少给48GB到64GB才稳。而如果文件数很少只有几十万给NameNode堆32GB纯粹是浪费反而会因为GC停顿变长拖慢整个集群。DataNode的堆没有NameNode那么敏感。DataNode主要是流式读写和块复制任务不重时默认4GB左右就够。真正吃内存的是YARN上的MapReduce任务所以DataNode进程的堆不要调得太大要把内存留给计算容器。JVM参数上我强烈建议在hadoop-env.sh里把GC日志打开并设置统一路径。生产排查时没有GC日志几乎是闭着眼睛找故障。启动参数类似这样export HADOOP_NAMENODE_OPTS-Xms32g -Xmx32g -XX:UseG1GC -XX:MaxGCPauseMillis200 -Xloggc:/var/log/hadoop/gc-namenode.log堆大小最好Xms和Xmx设置成同一个值避免运行期堆扩容导致的内存抖动和停顿。2.3 GC与JVM调优的日常检查JVM层调优不只是启动参数还要建立日常检查习惯。我在线上集群排障时最常用的命令是jstatjstat -gcutil pid 1000 10如果Old区使用率持续攀升并且回收后下降不明显说明堆里积累了长期存活对象NameNode很可能是元数据膨胀。如果Full GC频繁先别急着调GC参数先用jmap -heap看堆各区域比例再通过jstack抓线程大部分时候都能看到大量RPC线程在等待某种锁或队列根源往往是小文件太多或者客户端并发不合理。很多调优文档会直接建议大堆上G1。但我个人的经验是如果集群用的还是JDK8NameNode这类延迟敏感进程用G1时要非常小心配置不好会产生比较高的CPU开销如果物理内存和CPU允许先把G1的MaxGCPauseMillis调合理再观察Full GC频率。GC调优永远要配合监控数据不要单独为了调GC而调GC。3. HDFS层面存储系统的核心参数3.1 块大小、副本和数据目录HDFS的块大小直接影响文件读取的并行度。默认128MB对大多数生产场景是平衡点但如果集群的上游数据文件本身就是几百MB甚至GB级把dfs.blocksize调整到256MB可以减少Block数量降低NameNode内存压力同时一次读写的吞吐量更稳定。副本数默认是3没有特别强的理由不要降到2。降低副本数虽然省了磁盘但是当某个机架整体宕机或数据恢复期间出现二次故障时数据丢失的风险会显著增大。尤其是在生产集群磁盘坏盘是常态副本数是最后的防线。数据目录层面每个DataNode节点上应该挂多块磁盘并在dfs.datanode.data.dir中配置多个目录。这里有一个常见误区目录数量多并不意味着性能自动提升还需要配合开启磁盘均衡能力避免所有新写入都打到同一块盘。生产环境我会开启dfs.disk.balancer.enabledtrue并定期做数据目录的均衡。多磁盘还有一个好处是单一坏盘不会拖垮整个DataNode——只要把坏盘对应的目录从配置中剔除或做热插拔替换该节点还可以继续服务。这个设计在长周期运行中非常关键。3.2 NameNode RPC与DataNode传输并发NameNode是HDFS的“大脑”RPC处理能力直接决定整个集群的响应速度。默认dfs.namenode.handler.count只有10放在单并发小集群够用一旦到了生产环境几十台客户端同时提交读写请求10个线程很快会积压住。我一般会把NameNode的handler数增大到64到128之间具体取决于机器的核数。一个可以参考的思路是按并发客户端的规模和请求频率来估同时观察RPC队列是否经常非零。设置过高反而会创建大量线程消耗内存所以不要贪大。对应的DataNode端也有dfs.datanode.handler.count负责处理来自块池和客户端的数据服务请求高并发场景下从默认值调整到30到50更常见。另一个和生产并发强相关的参数是dfs.datanode.max.transfer.threads默认值是4096。这个参数控制DataNode同时间内允许的并发数据传输数量。短作业特别多的时候默认值很容易被打满新来的读写请求只能排队等待现象是整个集群吞吐不低但单个作业却慢得离谱。生产环境我习惯调到8192到16384但要看一下每台机器网卡和磁盘是否能扛住避免线程数加了之后反而把IO打满。3.3 小文件治理和目录规模控制HDFS的元数据是按文件、Block、目录一层一层在NameNode堆里管理的。一个文件无论多小都要占用一份文件对象和一份Block列表。大量几十KB的小文件会迅速把NameNode堆吃满引发Full GCRPC超时最终整个集群响应变慢甚至拒绝服务。小文件问题不只是调参能解决的。调参数只是把阈值提高比如dfs.namenode.fs-limits.max-directory-items默认是1048576可以调大但根本解法是在数据进入HDFS前就把小文件合并成大文件。生产上我见过比较有效的手段有两类一类是在离源头最近的采集层做合并比如每隔一段时间把小日志按业务维度拼成128MB以上的文件再写入HDFS另一类是对已经存在的小文件做离线合并将目录下的小文件重写为大文件。如果同时使用列式存储格式如ORC或Parquet还能获得压缩和谓词下推的好处查询侧的收益更大。特别提醒一点HDFS上的目录层级也别做得太深太散。每多一层目录NameNode在目录遍历上的成本就高一分。设计数仓路径时尽量把目录控制在固定层级每层下子目录数量有序增长。这不是玄学而是和NameNode堆内存高度相关。4. YARN层的资源调度与并发模型4.1 把物理机算成YARN资源YARN调度器看到的是NodeManager上报的内存和虚拟核数不是物理机的实际配置。所以调优的第一步是把每台物理机的资源合理划分给YARN。假设一台机器有128GB物理内存、24物理核同时这台机器上还跑着DataNode和NodeManager两个进程。系统内核和其他系统服务需要预留内存一般要留出20%到30%也就是说NodeManager可用的内存大致在96GB左右。这不是随便扣的因为内存被大页、页缓存、其他进程占用后强行把yarn.nodemanager.resource.memory-mb配到110GB很容易触发操作系统级别的OOM。CPU资源类似。24个物理核如果开了超线程对YARN来说是48个逻辑核但我不建议全部交给计算容器因为操作系统调度本身有成本DataNode和监控进程也需要CPU。生产上我会把可用vcore控制在物理核的1.5倍到2倍之间也就是36到48。配置如下property nameyarn.nodemanager.resource.memory-mb/name value98304/value /property property nameyarn.nodemanager.resource.cpu-vcores/name value40/value /property property nameyarn.scheduler.minimum-allocation-mb/name value2048/value /property property nameyarn.scheduler.maximum-allocation-mb/name value8192/value /property最小分配和最大分配也是关键。yarn.scheduler.minimum-allocation-mb不能设得过大否则一些小任务会白白占很多内存调度起来不灵活也不能设得太小否则调度器计算容器数时开销变大。2048MB一般是一个比较实用的下限。最大分配限制了单个Container的内存上限这个值会直接影响Map和Reduce的内存配置。如果业务上确实有需要超大内存的Reduce阶段可以把最大值放宽到12GB或16GB但同时要评估风险避免一个任务把整个节点资源吃掉。4.2 队列容量规划生产集群不要用FIFO调度器也不建议把所有业务塞在一个default队列里。我更推荐Capacity Scheduler它允许按业务线划分队列并设置队列权重、最大容量和用户限制。一个常见的规划是分三条队列离线批处理、实时或准实时任务、临时试验任务。离线批处理队列占大头临时试验队列容量小但灵活。配置示例property nameyarn.scheduler.capacity.root.default.capacity/name value50/value /property property nameyarn.scheduler.capacity.root.etl.capacity/name value30/value /property property nameyarn.scheduler.capacity.root.adhoc.capacity/name value20/value /property property nameyarn.scheduler.capacity.root.adhoc.maximum-capacity/name value30/value /property这个设计的好处是离线大任务不会把临时查询完全饿死临时任务超时占资源时也有天花板限制。如果多个业务共享同一集群还要配合user-limit-factor控制单个用户能占用的最大队列比例防止某个用户的异常任务拖垮整条队列。队列配置改完后记得刷新调度器而不是重启YARN。执行yarn rmadmin -refreshQueues后新配置立即生效是生产环境最友好的做法。4.3 与作业配合的资源参数YARN把资源给到Container后MapReduce还需要在自己这一层告诉TaskTracker“我要用多少内存”。这里有一个很容易踩的坑Container内存和JVM堆内存是两回事。我在实践中经常看到这样的配置mapreduce.map.memory.mb设了4096MB但mapreduce.map.java.opts也继承了4GB堆结果JVM自身需要堆外内存、MetaSpace、栈空间加起来已经超过Container上限YARN会直接杀掉Container。正确做法是JVM堆大小要比Container内存小20%到30%。例如Map容器给4GB那Java堆应该控制在3GB左右property namemapreduce.map.memory.mb/name value4096/value /property property namemapreduce.map.java.opts/name value-Xmx3072m/value /property property namemapreduce.reduce.memory.mb/name value8192/value /property property namemapreduce.reduce.java.opts/name value-Xmx6144m/value /propertyReduce阶段处理的数据量通常更大需要更多的内存做重组和聚合所以Reduce容器普遍比Map容器大一档。另外ApplicationMaster本身也要占资源通过yarn.app.mapreduce.am.resource.mb单独指定不能省略。5. MapReduce作业层的调优实战5.1 Map端排序缓冲、溢写与Map端压缩Map端最核心的是排序缓冲区和Spill策略。每次Map输出数据到磁盘前都会先在内存缓冲区里做一次内排序缓冲区占满了以后再溢写到本地磁盘。mapreduce.task.io.sort.mb默认只有100MB对生产集群来说偏小尤其是单Map处理的数据量很大时会频繁触发Spill产生大量中间文件拖慢整个任务。我通常会把mapreduce.task.io.sort.mb调到256MB到512MB链路长的作业甚至可以到1GB。同时注意mapreduce.map.sort.spill.percent默认是0.80也就是缓冲区使用率达到80%就开始溢写。这个值不建议改得太高接近100%时容易在排序过程中因为内存不足而卡死。Map端输出的中间数据压缩压力不大但收益很高。默认mapreduce.map.output.compressfalse意味着Mapper输出数据是不压缩的。数据量大时Shuffle阶段要传的数据量会翻几倍网络和Reduce端拉取都会很慢。开启压缩是成本最低的优化之一property namemapreduce.map.output.compress/name valuetrue/value /property property namemapreduce.map.output.compress.codec/name valueorg.apache.hadoop.io.compress.SnappyCodec/value /propertySnappy在压缩比和CPU开销之间比较均衡适合作为中间数据压缩格式。如果集群已经用了某种列式文件格式且上游就支持LZO也可以按实际情况选择。Map端压缩的核心目标是减少Shuffle数据量不是为了最终存储省空间。5.2 Reduce端拉取、归并与输出压缩Reduce端在正式跑Reduce函数之前要先从各个Map任务把属于自己的数据拉过来这个过程叫Shuffle。默认mapreduce.reduce.shuffle.parallelcopies只有5意味着同时只能从5个Map节点拉数据。如果Map Task数量很多这个并发会严重拖慢Reduce的启动等待时间。生产环境我会把这个参数调到10到20之间具体取决于网卡能力和Map Task总量。调得太大网卡和NameNode的块报告压力会明显上升调得太小Reduce等待拉数据的时间就会变大。还要注意Reduce任务的启动时机。mapreduce.job.reduce.slowstart.completedmaps默认是0.05意味着Map完成了5%后Reduce就可以开始拉数据了。对大部分作业这个值偏低Reduce启动得太早既占着资源又在空等。把它调整到0.5左右让Reduce在Map完成一半以后再启动可以显著减少Container空闲时间。输出压缩和中间压缩同样重要。如果最终结果要长期保存开启输出压缩能省大量磁盘但要注意选择合适的Codec。Gzip压缩比高但CPU开销大Snappy压缩速度快但压缩比一般。长时间保留的历史数据可以选Gzip频繁读取的中间结果更适合Snappy。5.3 数据倾斜现象、原因和三种解法数据倾斜是MapReduce最经典的性能杀手。症状上一看就是“同一个Reduce跑几个小时其他Reduce早已跑完”。原因也很典型某个Key的数量远远多于其他Key比如统计热点商品、某个超级城市的数据或者大量脏数据都落到空值上。第一种解法是在业务逻辑允许的情况下加Combiner。Combiner相当于Map端的“预Reduce”能在Shuffle之前把同一个Map任务内的局部聚合算掉减少传输到Reduce的数据量。只要Reduce的处理逻辑满足交换律和结合律比如sum、max、count就可以放心用。第二种解法是加盐做两阶段聚合。核心思路是给热点Key加一个随机前缀让数据先分散到多个Reduce节点做第一次聚合然后去掉前缀再做第二次全局聚合。代价是作业多一轮Reduce但对极端倾斜的场景收益非常大。需要注意两阶段的聚合逻辑必须和原始业务逻辑等价不能为了性能丢掉正确性。第三种解法是自定义Partitioner。默认的HashPartitioner按照Key的哈希值分配Reduce数据量不均时很容易倾斜。可以统计各Key的分布情况为热点Key单独指定Reduce编号或路由到额外分区让非热点Key保持默认哈希分布。这种方案适合能事前预估Key分布的场景缺点是定制成本高需要验证各种情况。现实中我会优先考虑Combiner因为它改动最少。如果问题还是严重再上两阶段聚合。自定义Partitioner一般用在做离线数据治理时需要严格控制分区的场景。6. 高频问题排查与避坑清单6.1 NameNode Full GC导致RPC超时NameNode出现Full GC现象通常是客户端操作HDFS时超时批量作业大面积报错同时监控面板上NameNode进程的CPU飙高、GC时间占很高比例。遇到这种情况不要马上重启NameNode先把GC日志拉出来。使用jstat -gcutil pid 1000持续观察。如果Old区在Full GC前后内存没有明显回落大概率是堆里有大量无法回收的元数据对象说明文件数和Block数逼近堆容量上限。此时需要清理无用数据、开启小文件合并并考虑扩容NameNode堆。还有一种情况是RPC线程队列积压导致处理延迟反映到GC上未必是Full GC而是CPU忙。用jstack看线程栈如果大量线程阻塞在RPC请求处理上多半是dfs.namenode.handler.count不足或客户端请求频率异常。先做限流和客户端重试退避再决定是否提高Handler数。6.2 YARN任务持续Pending或Container反复被killYARN队列里作业一直Accepted或者Processing但MapTask迟迟起不来基本可以判定为资源不足。先看yarn node -list -show-details确认每个节点的可用资源是否接近0。如果整个集群资源满负荷业务上又确实需要马上出结果只能临时调低部分作业的Container规格或者把低优先级队列的配置临时下调。Container反复被kill最常见的报错是“Container killed on request. Exit code is 143”或者“container beyond physical memory limit”。第一个通常是任务被外部或调度器回收第二个则是Container实际内存超过了声明值。后者往往就是我在前面强调的JVM堆和Container内存不匹配造成的。按Container内存的70%到80%去设置JVM堆基本能避免。排查时一定要养成看日志的习惯。用yarn logs -applicationId app_id可以把所有Container日志拉到本地不要只看ApplicationMaster上面的几百行。最容易被忽略的是节点本地日志目录很多被OOMKilled的Container只在NodeManager的日志里留下了原因。6.3 磁盘、坏盘与数据目录不均生产集群跑了一年之后最容易出现的是磁盘写满。HDFS的存储均衡不是天然的频繁写入的目录会集中在某几块盘上。我见过一台DataNode挂了4块盘其中一块使用率98%另外三块还有大量空间但集群节点网络、CPU、内存全都正常就是写入性能下降。处理方式分两步。第一步是通过hdfs diskbalancer -plan生成均衡计划再hdfs diskbalancer -execute执行。第二步是在日常运维中监控每块盘的容量使用率而不仅仅是节点总使用率。如果某块盘出现大量坏道DataNode日志里会出现读写异常这时候尽早把对应目录从dfs.datanode.data.dir中剔除不要拖着否则会影响整个节点的块上报状态。临时应急时可以手动重新挂载或复制数据但长期方案还是要让每块盘都有独立目录、独立卷并且给HDFS预留安全阈值一般保留15%到20%的剩余容量。6.4 生产调优参数速查表我把生产环境最常动的一些参数整理成了一张表方便遇到问题时快速对照。参数值不一定是绝对标准但方向基本一致。参数项默认值生产建议适用场景dfs.blocksize128MB128MB~256MB大文件场景调大小文件场景合并dfs.namenode.handler.count1064~128客户端并发较多时dfs.datanode.max.transfer.threads40968192~16384短作业并发较多时yarn.nodemanager.resource.memory-mb按物理内存自动物理内存70%~80%根据系统预留计算yarn.scheduler.minimum-allocation-mb10242048减少调度开销yarn.scheduler.maximum-allocation-mb81928192~16384按单容器最大需求设置mapreduce.map.memory.mb10244096Map处理数据量大时mapreduce.reduce.memory.mb10248192Reduce聚合数据量大时mapreduce.task.io.sort.mb100MB256MB~512MB排序压力大时mapreduce.reduce.shuffle.parallelcopies510~20Map Task较多时mapreduce.map.output.compressfalsetrue中间数据量大时mapreduce.job.reduce.slowstart.completedmaps0.050.5左右避免Reduce空等这张表不是一次调完就完了。每次动其中的任何一项都要重新观察集群的负载曲线和任务耗时确认收益后再固化到配置管理里。7. 调优不是结束一个保留到现在的复盘习惯最后说一个我坚持了很多年的习惯每次集群调优都保留一份“变更记录”。内容包括当时观察到的瓶颈指标、要调整的参数、调整前后的对比截图、以及为什么选用这个值。这个习惯救过我一次。有一回集群慢得异常所有人都在怀疑某个队列资源不够后来翻看变更记录才发现几天前为提高吞吐把mapreduce.map.output.compress关掉了。中间数据不压缩网络和磁盘压力瞬间增大问题根本不是队列资源。回滚这次变更后集群一个小时内恢复正常。所以我始终觉得好的调优不是追新参数而是把每个默认参数背后的逻辑吃透然后让环境和业务来适应这份逻辑。生产集群的稳定来自每一次小变更都被记录、被验证、被理解。前期多花一点时间搭好基线后面处理故障时的效率会成倍提升。
阅读完成 · 觉得有帮助？
