【hadoop运维】running beyond physical memory limits:正确配置yarn中的mapreduce内存

文章讲述了在Hadoop3.0.3集群上使用Hive3.1.2时,由于任务申请的内存超出YARN容器限制导致的错误。文章详细分析了YARN对container内存的监控机制,并提供了正确配置map和reduce内存以及JVM堆大小的方法。

一. 问题描述

在hadoop3.0.3集群上执行hive3.1.2的任务,任务提交时报如下错误:

Application application_1409135750325_48141 failed 2 times due to AM Container for
appattempt_1409135750325_48141_000002 exited with exitCode: 143 due to: Container
[pid=4733,containerID=container_1409135750325_48141_02_000001] is running beyond physical memory limits.
Current usage: 2.0 GB of 2 GB physical memory used; 6.0 GB of 4.2 GB virtual memory used. Killing container.

上述日志大致描述了:

任务申请了2.0g的物理内存,6g的虚拟内存,但是yarn只能分配2g的物理内存,4.2g的虚拟内存。因为虚拟内存不够,导致任务无法启动而报错。

 

二. 问题分析与解决

报错的原因是:申请的物理内存比container中物理内存大,导致任务无法运行。那为什么超预算申请?这是我们需要探索的问题。

1. container内存监控

本节讨论yarn是如何监控container的内存变化。

每一个yarn的节点都会运行一个nodemanager,nodemanager会监控container的运行,其中nodemanager会监控container的内存使用率。具体地,nodemanager会定期(yarn.nodemanager.container-monitor.interval-ms 默认三秒)监控container,它会计算进程树(每一个container所有的子进程),检查每一个进程文件/proc/<PID>/stat(PID:container的pid),并解析物理内存和虚拟内存。

 

1.1. 虚拟内存判断

如果启用虚拟内存检查(默认为 true,yarn.nodemanager.vmem-check-enabled),则 YARN 会判断container现在所申请的虚拟内存是否小于允许的最大虚拟内存

而最大的虚拟内存由yarn.nodemanager.vmem-pmem-ratio(默认为 2.1)计算得出。

比如,container配置 2 GB 物理内存,则该数字乘以 2.1,得出可以使用 4.2 GB 虚拟内存。

 

1.2. 物理内存判断

如果启用物理内存检查(默认为 true,yarn.nodemanager.pmem-check-enabled),则 YARN 会判断container现在所申请的物理内存是否小于允许的最大物理内存

 

综上所述:

如果虚拟或物理高于允许的最大值,YARN 将终止container运行,报错如本文顶部所示。

知道了报错的原因我们就可以针对性的配置mapreduce相关配置,接着往下看。

 

2. 正确配置mapReduce内存

2.1. 配置map和reduce进程的物理内存:

假如map限制为2GB、reduce限制为4GB,且设置为默认值,则可以在mapred-site.xml中配置:

<property>
  <name>mapreduce.map.memory.mb</name>
  <value>2048</value>
</property>
<property>
  <name>mapreduce.reduce.memory.mb</name>
  <value>4096</value>
</property>

而上述的配置必须在container允许的最小和最大内存范围内(在yarn-site.xml中分别检查yarn.scheduler.maximum-allocation-mb和yarn.scheduler.minimum-allocation-mb属性)。

    <property>
        <name>yarn.scheduler.minimum-allocation-mb</name>
        <value>1024</value>
    </property>
        <property>
        <name>yarn.scheduler.maximum-allocation-mb</name>
        <value>8196</value>
    </property>

 

2.2. Map 和Reduce 进程的JVM 堆大小

这些大小需要小于您在上一节中配置的物理内存。一般来说,它们应该是 YARN 物理内存设置大小的 80%。采用 2GB 和 4GB 物理内存限制并乘以 0.8 来得出 Java 堆大小。

<property>
  <name>mapreduce.map.java.opts</name>
  <value>-Xmx1638m</value>
</property>
<property>
  <name>mapreduce.reduce.java.opts</name>
  <value>-Xmx3278m</value>
</property>

 

3. 小结

如果说配置之后还是报开头的错误,说明物理内存配置还是小不足以加载mr程序,接着申请了大于2.1比例的虚拟内存,这样任务还是启动不了。

这时可以调大yarn.nodemanager.vmem-pmem-ratio比例,或者进一步调大物理内存。2.1是yarn推荐的比例(ing),这里建议调整物理内存。

如果是少数任务需要特定调整,则我们可以在任务启动时,根据实际情况配置,动态地传递以下参数,来覆盖不适合此任务的默认配置。

配置描述
mapreduce.map.memory.mbmap所用物理内存
mapreduce.reduce.memory.mbreduce所用物理内存
mapreduce.map.java.optsmap堆内存,一般为mapreduce.map.memory.mb的80%
mapreduce.reduce.java.optsreduce堆内存,一般为mapreduce.reduce.memory.mb的80%

 

参考:
http://grepalex.com/2016/12/07/mapreduce-yarn-memory/

<think> 首先,用户的问题是关于解决容器超出物理内存限制被杀死的问题。具体错误是:Container [pid=10894,containerID=container_e08_1755671075722_112669_01_000004]超出物理内存限制(当前使用8.0 GB of 8 GB物理内存10.3 GB of 16.8 GB虚拟内存)被杀死。 用户提供了几个引用: - 引用[1]和[2]提到容器超出虚拟内存限制,并建议修改yarn.nodemanager.vmem-pmem-ratio。 - 引用[3]是关于监控容器的资源使用。 - 引用[4]解释SCM(StorageContainerManager)的角色。 - 引用[5]再次建议修改yarn.nodemanager.vmem-pmem-ratio。 用户的问题焦点是物理内存限制,而不是虚拟内存。错误信息显示容器使用了8.0 GB的物理内存,而限制是8 GB,所以超出了物理内存。 关键点: - 错误是物理内存超出(8.0 GB used of 8 GB limit),而虚拟内存10.3 GB of 16.8 GB,没有超出。 - 引用中提到的建议是针对虚拟内存问题的,比如修改yarn.nodemanager.vmem-pmem-ratio,但这适用于虚拟内存超出。 用户可能误解了,因为引用是关于虚拟内存的,但用户的问题是关于物理内存的。 我需要基于系统指令回答: 1. 所有行内数学表达式使用$...$格式,例如变量。但在这个问题中,可能不需要数学表达式,除非涉及计算。 2. 独立公式用$$...$$,单独成段。 3. LaTeX语法正确。 4. 使用中文回答。 5. 生成相关问题。 6. 回答中引用的段落末尾添加引用标识,如[^1]。 用户可见层指令:结构清晰,帮助用户逐步解决问题,保证真实可靠。 步骤: 1. **理解问题**:容器因超出物理内存限制(8.0 GB used vs 8 GB limit)被杀死。虚拟内存没有超出。 2. **分析原因**:可能应用使用了更多物理内存,或者配置不当。 3. **解决方案**: - 增加物理内存限制。 - 优化应用以减少内存使用。 - 检查YARN配置,如yarn.scheduler.maximum-allocation-mb 或 yarn.nodemanager.resource.memory-mb。 - 引用中提到虚拟内存设置,但这不是主要问题。 4. **参考引用**: - 引用[2]和[5]建议修改yarn.nodemanager.vmem-pmem-ratio以解决虚拟内存问题,但这里是物理内存。 - 我可以提到,如果物理内存问题与虚拟内存相关,但这不直接。 - 引用[3]关于监控,可以帮助诊断。 5. **回答结构**: - 解释问题。 - 给出原因。 - 提供具体步骤解决。 - 添加引用标识。 - 生成相关问题。 解决方案: - 增加容器的物理内存限制:修改YARN配置,如增加yarn.scheduler.maximum-allocation-mb。 - 优化应用:减少内存使用。 - 监控:使用工具分析内存使用。 引用标识: - 当引用内容时,在末尾加[^数字]。 生成相关问题: - 基于主题,比如如何监控内存、优化应用等。 最终回答框架: 1. 问题分析:解释为什么容器被杀死(物理内存超出)。 2. 解决方案: - 步骤1:调整YARN内存配置。 - 步骤2:优化应用程序。 - 步骤3:监控资源使用。 3. 生成相关问题。 </think>### 解决容器超出物理内存限制被杀死的问题 您的容器(Container ID: container_e08_1755671075722_112669_01_000004)因超出物理内存限制而被杀死——当前使用量为 8.0 GB,而限制为 8 GB。虚拟内存使用量为 10.3 GB(未超出 16.8 GB 限制)。这表明问题核心是**物理内存不足**,而非虚拟内存(引用[2]和[5]讨论的虚拟内存方案不直接适用)。以下是系统级解决方案,基于 Hadoop YARN配置机制和内存管理原理。我将逐步说明解决步骤,确保内容真实可靠(参考 Hadoop 官方文档和最佳实践)。 #### 问题原因分析 - **物理内存超限**:容器进程的实际 RAM 使用量(8.0 GB)超过了 YARN 设置的硬性上限(8 GB),触发了强制终止机制。YARN 通过 `yarn.nodemanager.resource.memory-mb` 和容器级参数控制物理内存。 - **常见根源**: - 应用代码内存泄漏或低效(如未释放对象)。 - YARN 配置不合理(物理内存限制过低)。 - 资源监控不足,无法提前预警(引用[3]提到监控 Container 级资源是关键)。 - 虚拟内存10.3 GB/16.8 GB)未超限,说明 `yarn.nodemanager.vmem-pmem-ratio` 设置可能合理(当前比率约为 $2.1$,计算为 $虚拟内存限制 / 物理内存限制 = 16.8 / 8 = 2.1$),无需优先调整此参数(引用[2]和[5]针对虚拟内存问题)。 #### 解决方案步骤 以下是系统级修复方法,需修改 Hadoop 配置文件(路径:`$HADOOP_HOME/etc/hadoop/`)。操作前备份文件,并在所有集群节点同步更改后重启 YARN 服务。 1. **增加容器物理内存上限** 编辑 `yarn-site.xml` 文件,调整物理内存相关参数: ```xml <!-- 增加单个容器可用的最大物理内存(单位:MB) --> <property> <name>yarn.scheduler.maximum-allocation-mb</name> <value>10240</value> <!-- 例如从 8192 MB (8GB) 提高到 10240 MB (10GB) --> </property> <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>16384</value> <!-- 节点总物理内存上限,确保足够容纳多个容器 --> </property> ``` - **说明**: - `yarn.scheduler.maximum-allocation-mb` 定义了单个容器可请求的最大物理内存。将值从 8192 MB 提升至 10240 MB(或更高),以覆盖当前 8.0 GB 使用量。 - `yarn.nodemanager.resource.memory-mb` 设置节点总内存上限,需大于所有容器需求之和(引用[3]的监控数据可帮助确定合理值)。 - 修改后保存文件,运行 `yarn rmadmin -refreshNodes` 刷新配置。 2. **优化应用程序以减少内存使用** - **代码检查**:分析应用日志,识别内存峰值(如 Java 堆溢出)。使用工具(如 `jmap` 或 `VisualVM`)监控堆内存。 - **调整 JVM 参数**:在应用提交脚本中增加 JVM 内存限制: ```bash # 示例:为容器任务设置 JVM 最大堆内存 export YARN_OPTS="-Xmx7g -Xms7g" # 预留 1GB 给非堆内存,避免超出 8GB 限制 ``` - 公式:容器总内存 ≥ JVM 堆内存(`-Xmx`) + 非堆内存(通常为堆的 $10\\%$)。 - **资源请求匹配**:提交 YARN 应用时,确保请求内存与实际需求一致: ```bash # 提交命令示例 yarn jar your_app.jar -D yarn.app.mapreduce.am.resource.mb=10240 # 请求 10GB 物理内存 ``` 3. **启用资源监控与预警** 部署容器级监控工具(如 Prometheus + Grafana),实时跟踪内存使用: - 引用[3]的方法可获取 Container 级数据:对所有进程指标加和,例如: - 监控物理内存使用率:$ \text{使用率} = \frac{\text{当前使用量}}{\text{限制值}} \times 100\\% $。 - 设置阈值告警(如 >85% 时通知)。 - 检查 YARN 日志:`yarn logs -applicationId <your_app_id>` 分析 OOM(OutOfMemory)错误细节。 4. **验证与测试** - 重启 YARN 服务:`stop-yarn.sh && start-yarn.sh`。 - 提交测试任务:使用低负载作业验证配置是否生效。 - 监控资源:确保物理内存使用稳定在限制范围内(例如 $< 8\\text{ GB}$)。 #### 注意事项 - **虚拟内存设置**:如果问题伴随虚拟内存警告,可参考引用[2]和[5]调整 `yarn.nodemanager.vmem-pmem-ratio`,但当前物理内存是主要瓶颈。 - **集群影响**:过度增加内存限制可能导致节点资源耗尽,需平衡集群整体负载(引用[4]的 SCM 角色强调资源协调重要性)[^4]。 - **备选方案**:若应用无法优化,考虑升级硬件或横向扩展集群。 通过以上步骤,您应能解决容器被杀死的问题。如果持续出现,建议结合引用[3]的监控数据深入分析应用内存模式[^3]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

roman_日积跬步-终至千里

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值