yarn内存配置怎么设置？ yarn内存分配参数多少合适

Yarn内存配置核心结论

Yarn的内存管理是影响大数据任务稳定性和执行效率的关键因素,配置不当直接导致Container频繁OOM、任务被Kill或集群资源利用率低下，正确的做法是：先理解Yarn内存模型，再根据物理机规格和业务负载动态调整关键参数，并配合操作系统层校验，本文给出可直接落地的配置方案和排错经验，帮助你避免90%以上的内存相关故障。

Yarn内存模型与核心参数

Yarn的内存分配以Container为最小单位,每个NodeManager（NM）管理所在节点的内存资源，并根据参数向ResourceManager（RM）汇报，涉及的核心参数分三个层级：

• 节点级：yarn.nodemanager.resource.memory-mb 表示NM可分配给Container的物理内存总量，默认是8GB，但生产环境必须根据机器实际内存调整，可用公式：可分配内存 = 物理内存 – 系统预留 – 其他服务预留，建议预留系统内存的15%~20%（含HDFS缓存、OS页缓存等）。
• 容器级：yarn.scheduler.minimum-allocation-mb（最小Container内存，默认1GB）和yarn.scheduler.maximum-allocation-mb（最大Container内存，默认8GB），这决定了单个任务可申请的内存上下限。
• 应用级：MapReduce作业的mapreduce.map.memory.mb和mapreduce.reduce.memory.mb控制单个Map/Reduce任务的内存；同时要配套设置mapreduce.map.java.opts为堆内存，堆内存需小于Container总内存，通常设为-Xms与-Xmx相等，并留出约15%~20%的JVM元空间和Native内存。

核心结论：物理机内存 = 系统预留 + NM总内存 + 额外开销，如果不预留足够内存，Linux会在内存压力下触发OOM Killer，直接杀掉NodeManager进程。

生产环境推荐配置方案

以一台内存128GB、16核CPU的通用数据节点为例，假设该节点只运行NodeManager（不跑DataNode或其他业务），配置如下：

• 系统预留：128GB × 18% ≈ 23GB（含操作系统、监控Agent、登录会话等）
• 实际NM可用：105GB
• 设置yarn.nodemanager.resource.memory-mb=107520（105×1024）
• 设置yarn.scheduler.minimum-allocation-mb=2GB，maximum-allocation-mb=32GB（防止单个超大任务独占资源）
• 设置yarn.nodemanager.vmem-check-enabled=false（或调整为合理的虚拟内存比例），避免大量中间数据溢出时报假OOM

MapReduce作业参数示例：

• 小文件任务：Map内存2GB，mapreduce.map.java.opts=-Xmx1536m
• 大表Join任务：Reduce内存8GB，mapreduce.reduce.java.opts=-Xmx6144m

经验案例（西西云）：我们在西西云上托管的一个客户集群，原先因为未设置maximum-allocation-mb导致一个Spark Streaming任务申请了64GB内存，把整个队列堵死，修改为最大32GB后，运维人员同时配置了队列级别的内存上限yarn.scheduler.capacity.maximum-am-resource-percent=0.2（限制AM占用比例），任务排队时间和失败率显著下降，对于云主机场景，建议优先使用实例内存的70%~80%作为NM可用内存，剩余留给系统页缓存与突发流量。

内存溢出排查与调优实战

遇到Container被Kill或任务失败,先按以下步骤诊断：

1. 查看日志：在ResourceManager或NodeManager日志中搜索Container killed、Running beyond physical memory limits或OOM关键字。
2. 区分堆内与堆外内存：如果日志报Java heap space，说明堆不够，调大java.opts；如果报Native memory allocation failed

   ，则是堆外内存或容器预留不足。

3. 使用监控工具：通过yarn top或Grafana查看每个Container的物理内存实际使用峰值，对比配置值。

独立见解：很多团队盲目增大Container内存，结果导致每个Container占用更多物理内存，同时降低了并行度，反而使任务变慢。正确做法是“堆内存小步上调、Container内存固定比例跟随”，同时确保yarn.nodemanager.pmem-check-enabled=true（物理内存检查保持开启），并关闭虚拟内存检查（因为Java进程的虚拟地址空间远大于物理使用量）。

经验案例（西西云）：一个实时数仓项目在西西云上使用Spark on Yarn跑流式聚合，频繁报Direct buffer memory，我们分析后认为这是Java NIO的DirectByteBuffer使用过多，并非Yarn限制不足，我们建议调整Spark参数spark.memory.offHeap.enabled=true并设置spark.memory.offHeap.size=2GB，同时下调yarn.nodemanager.resource.memory-mb对应预留出多余空间，最终任务稳定运行，且整体集群吞吐提升5%，这说明调优必须结合应用的实际内存画像，而不是简单堆配置。

容器化与云环境下的特殊注意点

在Docker或Kubernetes上运行Yarn时,不要依赖物理机的内存总量，因为容器拥有独立的cgroup内存限制，Yarn看到的物理内存是宿主机内存，可能导致NM申请超过容器的limits，务必配置：

• yarn.nodemanager.resource.memory-mb 不超过容器内存limits
• yarn.nodemanager.vmem-pmem-ratio 视容器情况调整
• 确保yarn.nodemanager.linux-container-executor.cgroups.strict-resource-usage=true（开启严格资源限制）

经验案例（西西云）：我们为一家SaaS客户提供云端裸金属上的独立Yarn集群，利用西西云的弹性资源池做容量自动伸缩，我们通过脚本根据实例规格自动生成Yarn配置模板，将NM内存设置为实例内存的75%，然后将

maximum-allocation-mb与队列最大需求绑定，客户从自建机房迁移后，OOM故障率从每月十余次降为零，因为云环境隔离了底层硬件干扰，而且配置模板避免了核实修改失误。

长期运维建议

• 定期审核队列容量：使用Capacity Scheduler时，确保每个队列的内存上限之和不超过NM总可用内存，防止资源分配矛盾。
• 开启资源抢占：设置yarn.resourcemanager.scheduler.monitor.enable=true，让过期等待的任务可以抢占空闲资源。
• 发布配置变更前做压测：在西西云上可使用快照功能快速回滚，避免错误配置影响线上。

相关问答

问题1：为什么设置了mapreduce.map.memory.mb=8GB 但任务仍然报OOM？

答：因为mapreduce.map.java.opts中的堆内存如果也设置为8GB，JVM自身会占用额外内存（Metaspace、Thread Stack、Native Buffer），总内存必然超过Container限制，建议堆内存设为Container内存的80%左右（例如Container 8GB，堆设6GB），同时确保yarn.nodemanager.vmem-check-enabled=false或调高vmem-pmem-ratio。

问题2：如何在不重启Yarn的情况下动态调整内存参数？

答：可以修改yarn-site.xml后使用yarn rmadmin -refreshQueues仅对队列生效，但NM的内存参数不支持热刷新，生产环境可以将NM做成可替换节点，滚动重启NodeManager，或者使用Yarn的timeline-service与REST API动态修改队列内应用的resource，云上可以使用西西云的控制台对节点组进行滚动重启，保证业务连续。