临沂网站建设临沂,排名第一的玉米品种,免费素材视频网站哪个最好,怎么做网站的跳转图中资源相关参数含义及简单分析思路#xff1a;
基础资源抢占参数
Total Resource Preempted: memory:62112, vCores:6
含义#xff1a;应用总共被抢占的资源量#xff0c; memory:62112 表示累计被收回的内存#xff08;单位通常是MB #xff0c;结合Hadoop生态…
图中资源相关参数含义及简单分析思路
基础资源抢占参数
Total Resource Preempted: memory:62112, vCores:6
含义应用总共被抢占的资源量 memory:62112 表示累计被收回的内存单位通常是MB 结合Hadoop生态常见配置推测 vCores:6 是被收回的虚拟CPU核心数。
分析若频繁、大量出现资源抢占可能集群资源紧张或该应用资源申请/使用策略不合理挤占其他任务资源。Total Number of Non - AM Containers Preempted: 6
含义非应用管理器AMApplication Master 负责应用资源协调等容器被抢占的总数这里是6个。容器是YARN等资源调度框架中资源分配的基本单位。
Total Number of AM Containers Preempted: 0
含义应用管理器容器未被抢占说明负责应用整体管控的核心进程资源相对稳定。
分析非AM容器被抢占多可能是业务计算容器资源超量或集群整体资源不足优先保障了AM稳定。Resource Preempted from Current Attempt: memory:62112, vCores:6
含义当前应用尝试一次提交执行可理解为一次Attempt 中被抢占的资源量和总抢占资源一致说明本次执行就发生了这些资源回收。
Number of Non - AM Containers Preempted from Current Attempt: 6
含义当前尝试里被抢占的非AM容器数量与总数量一致即本次执行这6个业务容器资源被收走。
分析本次执行资源抢占集中需看是否应用资源申请过高或集群在该时段有更高优先级任务。
资源分配聚合参数
Aggregate Resource Allocation: 2612397662 MB - seconds, 27483 core - seconds
含义MB - seconds 内存资源使用的“时间积分”可理解为 内存量MB× 使用时长秒 总和反映内存资源的累计消耗规模 core - seconds CPU核心使用的“时间积分”即 CPU核心数 × 使用时长秒 总和体现CPU资源的累计消耗规模。
分析数值大说明应用整体资源消耗多。对比同类型、同逻辑任务若该数值异常高可能任务数据量突增、计算逻辑低效如冗余计算导致CPU/内存长时间占用。Aggregate Preempted Resource Allocation: 24922718 MB - seconds, 244 core - seconds
含义因抢占回收的资源对应的“资源 - 时间”积分即被收回资源若正常执行下去会产生的资源消耗。
分析结合前面抢占的容器数、资源量可算抢占资源占总分配资源的比例如这里内存抢占占比约 24922718/2612397662≈0.95% CPU同理 占比高说明资源浪费/不合理使用严重占比低可能是集群临时资源调剂。
整体分析思路
资源抢占影响若资源抢占后应用仍 SUCCEEDED 成功说明虽被回收资源但剩余资源或重试机制若有保障了执行若频繁因抢占失败 FAILED 得调整资源申请、优化任务逻辑或和集群管理员沟通资源配额。集群层面多任务出现类似高抢占需检查集群资源规划如队列资源分配、节点容量是否有资源倾斜某队列/用户占用过多 若仅个别任务聚焦任务自身资源配置、数据量、计算逻辑优化。结合业务若这是周期性ETL如每天跑的零售客户标签计算 exp_ctp_retail_cust_dms_labe_df 对比历史执行的资源参数看是否数据量增长导致资源需求变化或调度时段和其他大任务冲突挤资源 。
简单说这些参数反映应用在集群中资源“用了多少、被收走多少、怎么被收”用于排查资源冲突、优化任务资源配置和保障集群稳定运行 。
资源抢占Resource Preemption主要会从任务执行、集群稳定性、资源利用率等维度产生影响具体如下
对任务执行的直接影响
执行时间延长
若容器被抢占任务可能需要重新申请资源、启动容器增加额外的调度和初始化开销如YARN重新分配容器、TEZ/MapReduce任务重启导致整体耗时变长。
例前一张图中任务因资源抢占耗时25分钟而无抢占的任务耗时仅16分钟左右。任务失败风险
若抢占后剩余资源不足如内存/CPU被过度回收任务可能因“资源不足”如OOM、容器被强制Kill失败即使重试频繁抢占也会耗尽重试次数若配置有限。
对集群稳定性的影响
集群抖动Thrashing
大量任务同时被抢占、重启会导致集群资源“潮汐式”波动引发YARN调度队列过载、节点负载突增甚至影响其他无关任务的正常执行。低优先级任务“饿死”
若高优先级任务持续抢占资源低优先级任务可能长期无法获得足够容器导致业务延迟如非核心ETL任务被核心报表任务抢占。
对资源利用率的双向影响
正面倒逼资源合理分配
抢占机制迫使低优先级/超额申请的任务释放资源让高优先级/资源紧缺的任务获得保障提升集群整体资源利用率避免“大任务占坑不干活”。负面过度抢占导致资源浪费
若抢占策略激进如YARN的 yarn.scheduler.fair.preemption.timeout 设置过短任务可能频繁被中断资源在“抢占 - 重启”循环中内耗反而降低实际有效利用率。
对业务逻辑的潜在影响
有状态任务的数据一致性风险
若任务是有状态计算如流处理、迭代计算容器被抢占可能导致中间状态丢失需依赖Checkpoint机制恢复增加数据一致性保障的复杂度。
总结
资源抢占是一把“双刃剑”合理配置如基于优先级、资源使用阈值触发抢占可优化集群资源公平性与利用率配置不当或集群过载则会导致任务延迟、失败甚至引发集群级不稳定。实际中需结合业务优先级、任务类型如批处理/流处理和集群规模精细调整抢占策略如YARN的公平调度/容量调度参数。
要优化该Tez任务的参数配置需结合资源抢占、聚合资源消耗与Tez任务的内存/CPU参数逻辑分以下步骤调整
一、核心参数调整减少资源抢占匹配实际需求
从图中看任务被抢占的总内存为 62112 MB 约60GB、涉及6个非AM容器反推原单个容器内存请求约 10GB 62112 ÷ 6 ≈ 10352 MB 。但聚合资源分配的内存时间积分 2612397662 MB-seconds 远大于被抢占的资源积分 24922718 MB-seconds 说明容器内存申请过高实际使用不足需降低容器内存请求。
调整容器与AM内存
hive.tez.container.size 设置单个容器的总内存需与YARN的 yarn.scheduler.minimum-allocation-mb 匹配建议设为 4096 MB 或 6144 MB 即4G/6G降低被抢占概率。tez.am.resource.memory.mb Application MasterAM的内存需与 yarn.scheduler.minimum-allocation-mb 一致如设为 4096 MB 保证AM不被抢占。hive.tez.container.max.java.heap.size 容器内Java堆内存建议为 container.size 的80%如 container.size4096 MB 时设为 3276 MB 。
优化IO与内存缓冲减少内存浪费
Tez的IO缓冲内存若设置过大会导致容器内存“虚高”被YARN误判抢占。需按容器内存比例配置
tez.runtime.io.sort.mb 排序内存设为 container.size 的40%如 container.size4096 MB 时设为 1638 MB 不超过2GB。tez.runtime.unordered.output.buffer.size-mb 非排序输出缓冲设为 container.size 的10%如 409 MB 。hive.auto.convert.join.noconditionaltask.size Map Join内存设为 container.size 的1/3如 1365 MB 避免大Join时内存溢出。
二、辅助优化提升资源利用率
开启容器重用减少资源申请次数
设置 tez.am.container.reuse.enabledtrue 允许AM容器复用减少YARN调度 overhead尤其适合短任务场景。
控制并行度避免资源过载
若任务数据量未达TB级可降低并行度减少容器数
tez.grouping.split-count 输入分片数即并行任务数根据实际数据量调整如从100降到50左右减少总资源申请量。
匹配YARN集群配置
需确保任务参数与YARN全局配置一致
若YARN的 yarn.scheduler.minimum-allocation-mb4096 则 tez.am.resource.memory.mb 和 hive.tez.container.size 必须≥4096。若 yarn.nodemanager.vmem-pmem-ratio2.1 默认则容器虚拟内存上限为 物理内存×2.1 需避免Java堆外内存如NIO缓冲触发虚拟内存超限。
三、验证与监控
测试调整后效果重新运行任务观察 Resource Preempted 是否减少、 Elapsed 耗时是否稳定。长期监控通过YARN UI或日志跟踪容器内存实际使用量如 /proc//stat 解析逐步微调 container.size 和堆内存参数直到“实际使用≈申请内存”且无抢占。
示例参数配置供参考
set hive.tez.container.size4096; – 每个容器4G内存
set tez.am.resource.memory.mb4096; – AM内存与容器一致
set hive.tez.container.max.java.heap.size3276; – 堆内存为container的80%
set tez.runtime.io.sort.mb1638; – 排序内存40% of container
set tez.runtime.unordered.output.buffer.size-mb409; – 非排序缓冲10% of container
set hive.auto.convert.join.noconditionaltask.size1365; – Map Join内存1/3 of container
set tez.am.container.reuse.enabledtrue; – 开启容器重用
set tez.grouping.split-count50; – 调整并行度
通过“降低容器内存请求按比例分配子内存匹配YARN配置”可减少资源抢占同时保证任务稳定运行。
