mapreduce任务提交后不报错,卡在Running Job不执行

本文探讨了YARN运行中可能遇到的问题,如磁盘容量过高、配置文件不完整及内存冲突等,并提供了详细的解决方案,包括硬盘扩容、调整配置参数及优化内存分配。

1.可能是磁盘容量占用过高

解决方法:

1.硬盘扩容,参考 

https://blog.youkuaiyun.com/u013431916/article/details/80548069

2.配置yarn-site.xml配置文件

<property>
    <name>yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage</name>
    <value>98</value>
</property>                 

2.可能是由于配置文件不完整

检查yarn-site.xml的配置项是否完整

我的配置项如下

<property>
 <name>yarn.resourcemanager.hostname</name>
 <value>bdai1</value>
</property>
<property>
 <name>yarn.nodemanager.aux-services</name>
 <value>mapreduce_shuffle</value>
</property>
<property>
<name>yarn.resourcemanager.webapp.address</name>
<value>0.0.0.0:8088</value>
</property>
<property>
<name>yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage</name>
<value>98</value>
</property>

3.有可能是分配的内存有冲突

检查yarn允许的总大小[必须大于两个container大小,因为AM占用一个container]

检查yarn允许的每个container大小(最大最小)

检查mapreduce创建的container大小[必须小于yarn设置的]

hive和tez对应的container相关大小配置均要小于yarn所设置的,否则所需资源不足

<think> 嗯,用户的问题是关于Map任务执行后Container是否会释放。从对话历史看,用户之前讨论过ApplicationMaster的资源申请机制,现在转向了任务执行细节,可能是想优化资源利用率或排查资源泄漏问题。 用户引用了多个关于容器的资料,但有些内容(如Vue组件报错、Java容器概念)与当前问题关联大,需要过滤核心需求。真正的焦点在YARN任务执行的生命周期管理。 根据Hadoop架构知识: 1. Map任务结束后的Container处理取决于任务类型和配置 2. 普通Map任务默认会立即释放Container(关键点) 3. Reduce任务复用场景需要特殊处理(补充说明) 4. 延迟释放机制的存在原因(用户可能遇到的困惑点) 需要强调两个技术细节: - 为什么Reduce阶段需要保留Map的Container?因为可能有Reduce任务需要获取Map输出 - 用户如何主动控制释放行为?通过配置参数mapreduce.job.reduce.slowstart.completedmaps 用户身份推测是大数据平台开发或运维,正在调优作业性能。深层需求可能是发现集群资源未及时释放,想确认是正常机制还是资源泄漏。 回答时需注意: 1. 避免Java容器概念混淆(用户引用的[2][5]是编程容器,非YARN容器) 2. 结合用户之前关注的AM资源申请机制(历史回答),保持知识连贯性 3. 给出可操作的验证方法(如日志查看、配置修改) 相关扩展问题可以引导用户了解资源监控和调优,比如如何查看Container生命周期日志,这能帮助用户自主排查问题。 </think> 在YARN架构中,**Map任务执行完毕后其Container是否会释放取决于任务阶段和配置**,具体机制如下: ### 1. **Map任务结束后的默认行为** ```mermaid graph TB A[Map任务完成] --> B{Reduce阶段是否启动?} B -->|否| C[Container立即释放] B -->|是| D[Container暂释放] ``` - **普通Map任务**:执行完成后立即释放Container资源(CPU/内存归还资源池)[^2] - **Reduce任务依赖**:若Reduce阶段已启动,Map任务的Container需保留至Reduce拉取完数据(默认保留期10分钟) ### 2. **核心控制参数** 在`mapred-site.xml`中配置: ```xml <!-- 控制Map输出保留时间 --> <property> <name>mapreduce.reduce.shuffle.keep-alive.secs</name> <value>600</value> <!-- 默认600秒(10分钟) --> </property> <!-- 强制释放机制 --> <property> <name>yarn.nodemanager.delete.debug-delay-sec</name> <value>0</value> <!-- 0表示任务结束立即删除Container --> </property> ``` ### 3. **特殊场景处理** | 场景类型 | Container释放时机 | 原理说明 | |-------------------------|---------------------------------------|--------------------------------------------------------------------------| | **Pipeline作业** | 下游Reduce拉取数据后立即释放 | Reduce通过HTTP直接拉取Map输出,无需保留Container[^2] | | **超时未拉取** | 超过`keep-alive.secs`后强制释放 | 防止资源浪费(日志可在NM的`container-launcher.log`查看) | | **开启Uber模式** | 所有Task完成后统一释放 | AM将Map和Reduce合并到同一个Container执行[^5] | | **Map输出压缩开启时** | 可能延迟释放(解压需要) | Reduce需解压数据期间Map Container保持存活 | ### 4. **资源释放验证方法** 通过YARN CLI检查Container状态: ```bash yarn application -status <Application_ID> | grep -A 10 "Running Containers" ``` - **已释放**:Container状态变为`COMPLETED` - **未释放**:状态仍为`RUNNING` 或 `LOCALIZING` ### 5. **最佳实践建议 1. **缩短保留期**(资源紧张集群) 调整参数加速释放: ```xml <property> <name>mapreduce.reduce.shuffle.keep-alive.secs</name> <value>120</value> <!-- 降至2分钟 --> </property> ``` 2. **监控资源滞留** 在ResourceManager UI观察: - `Resources used`曲线应随任务结束快速下降 - 滞留Container超过5分钟需告警 > **关键结论**:在标准配置下,Map任务结束后的Container**会立即释放**,需等待Reduce拉取数据或超时(默认10分钟)。若Reduce尚未启动,则立即释放[^2][^5]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值