制與AM卡住問(wèn)題解決方案)
1. Yarn資源管理機(jī)制與AM卡住現(xiàn)象解析在大規(guī)模數(shù)據(jù)處理場(chǎng)景中Yarn作為Hadoop生態(tài)系統(tǒng)的核心資源調(diào)度器其資源分配機(jī)制直接決定了作業(yè)執(zhí)行效率。當(dāng)出現(xiàn)ApplicationMaster資源不足導(dǎo)致作業(yè)卡住的情況時(shí)本質(zhì)上反映了集群資源供需失衡的狀態(tài)。這種現(xiàn)象通常表現(xiàn)為作業(yè)長(zhǎng)時(shí)間停留在ACCEPTED狀態(tài)或者AM容器反復(fù)申請(qǐng)失敗最終導(dǎo)致整個(gè)作業(yè)流停滯。AMApplicationMaster是Yarn架構(gòu)中的關(guān)鍵角色每個(gè)作業(yè)都會(huì)啟動(dòng)一個(gè)AM進(jìn)程來(lái)負(fù)責(zé)該作業(yè)的生命周期管理。根據(jù)實(shí)踐經(jīng)驗(yàn)AM容器需要至少1-2GB內(nèi)存和1個(gè)vCore才能穩(wěn)定運(yùn)行。當(dāng)集群整體資源緊張或隊(duì)列配置不當(dāng)時(shí)AM容器的資源申請(qǐng)就會(huì)進(jìn)入等待隊(duì)列形成作業(yè)卡住的表象。關(guān)鍵診斷點(diǎn)通過(guò)Yarn ResourceManager Web UI觀察AM容器的Resource Requested/Available比值當(dāng)持續(xù)超過(guò)80%時(shí)需要立即干預(yù)。2. 資源不足的根本原因排查2.1 集群級(jí)資源檢查首先通過(guò)yarn node -list命令查看各NodeManager節(jié)點(diǎn)的資源狀態(tài)重點(diǎn)關(guān)注總內(nèi)存/已用內(nèi)存比例總vCore/已用vCore比例健康節(jié)點(diǎn)數(shù)量典型問(wèn)題模式包括物理資源確實(shí)耗盡內(nèi)存使用95%資源碎片化嚴(yán)重大量小作業(yè)占用資源節(jié)點(diǎn)負(fù)載不均衡部分節(jié)點(diǎn)過(guò)載2.2 隊(duì)列配置審計(jì)使用yarn queue -status queue_name檢查目標(biāo)隊(duì)列的配置queue nameprod minResources8192 mb,8 vcores/minResources maxResources65536 mb,32 vcores/maxResources maxRunningApps50/maxRunningApps /queue常見(jiàn)配置陷阱最小資源設(shè)置過(guò)高導(dǎo)致小作業(yè)無(wú)法獲取資源最大資源設(shè)置過(guò)低限制了大作業(yè)的擴(kuò)展未設(shè)置AM資源保障比例yarn.scheduler.capacity.maximum-am-resource-percent2.3 AM資源請(qǐng)求分析通過(guò)作業(yè)日志或ResourceManager API獲取AM的實(shí)際資源請(qǐng)求curl -s http://rm-address:8088/ws/v1/cluster/apps/{appid} | jq .app.amContainerResource輸出示例{ memory: 2048, vCores: 1, resourceInformations: { GPU: { value: 0, unit: } } }對(duì)比集群可用資源判斷是否屬于合理請(qǐng)求范圍。3. 六種實(shí)戰(zhàn)解決方案3.1 動(dòng)態(tài)調(diào)整AM資源規(guī)格在提交作業(yè)時(shí)顯式指定AM資源以Spark為例spark-submit \ --master yarn \ --conf spark.yarn.am.memory1536m \ --conf spark.yarn.am.cores1 \ --class com.example.Main \ app.jar建議值簡(jiǎn)單作業(yè)1-2GB內(nèi)存 1vCore復(fù)雜DAG作業(yè)4GB內(nèi)存 2vCores3.2 配置AM資源保障在yarn-site.xml中設(shè)置property nameyarn.scheduler.capacity.maximum-am-resource-percent/name value0.2/value !-- 保留20%資源專供AM使用 -- /property同時(shí)配置隊(duì)列的最小AM資源占比property nameyarn.scheduler.capacity.queue-path.minimum-am-resource-percent/name value0.1/value /property3.3 優(yōu)化隊(duì)列層次結(jié)構(gòu)建議的生產(chǎn)環(huán)境隊(duì)列配置模板root ├── prod (50%資源) │ ├── etl │ └── streaming ├── dev (30%資源) └── adhoc (20%資源)每個(gè)子隊(duì)列設(shè)置maxAMShare0.3userLimitFactor2orderingPolicyfair3.4 啟用資源預(yù)留機(jī)制對(duì)于關(guān)鍵作業(yè)在提交時(shí)添加--conf spark.yarn.executor.resourceRequest.amount1 \ --conf spark.yarn.executor.resourceRequest.parallelism2這會(huì)在資源緊張時(shí)優(yōu)先保留所需資源。3.5 監(jiān)控與自動(dòng)恢復(fù)方案搭建監(jiān)控體系檢測(cè)以下指標(biāo)AM等待時(shí)間yarn_app_am_wait_time_ms待處理容器數(shù)yarn_app_pending_containers隊(duì)列資源利用率queue_used_capacity配合告警規(guī)則實(shí)現(xiàn)自動(dòng)擴(kuò)容或作業(yè)重試。3.6 資源碎片整理策略定期執(zhí)行以下操作清理僵尸作業(yè)yarn application -kill application_id平衡節(jié)點(diǎn)負(fù)載yarn rmadmin -refreshNodes壓縮小文件優(yōu)化HDFS塊大小配置4. 典型問(wèn)題排查手冊(cè)4.1 AM啟動(dòng)超時(shí)Timeout waiting for AM container解決方案增加超時(shí)閾值property nameyarn.am.liveness-monitor.expiry-interval-ms/name value1200000/value /property檢查NodeManager日志中的資源分配錯(cuò)誤4.2 反復(fù)出現(xiàn)AM容器退出常見(jiàn)原因AM內(nèi)存溢出需增加10-20%內(nèi)存緩沖依賴沖突檢查classpath中的jar版本心跳超時(shí)調(diào)整yarn.am.liveness-monitor.interval-ms4.3 資源死鎖場(chǎng)景處理當(dāng)多個(gè)作業(yè)互相阻塞時(shí)臨時(shí)提升隊(duì)列容量yarn queue -update queue -maxCapacity 100按優(yōu)先級(jí)終止部分作業(yè)使用資源搶占策略property nameyarn.resourcemanager.scheduler.monitor.enable/name valuetrue/value /property5. 高級(jí)調(diào)優(yōu)技巧5.1 基于標(biāo)簽的調(diào)度為AM容器分配專用節(jié)點(diǎn)標(biāo)記節(jié)點(diǎn)yarn rmadmin -addToClusterNodeLabels AM_NODE yarn rmadmin -replaceLabelsOnNode node1:8034AM_NODE提交作業(yè)時(shí)指定--conf spark.yarn.am.nodeLabelExpressionAM_NODE5.2 彈性資源分配根據(jù)負(fù)載動(dòng)態(tài)調(diào)整AM資源spark.listenerManager.register(new SparkListener { override def onExecutorAdded(event: SparkListenerExecutorAdded): Unit { if (event.executorInfo.totalCores 4) { sparkSession.conf.set(spark.yarn.am.memory, 4g) } } })5.3 混合部署方案在Kubernetes上部署專用AM PodapiVersion: apps/v1 kind: Deployment metadata: name: spark-am spec: template: spec: containers: - name: am resources: requests: memory: 2Gi cpu: 1 limits: memory: 4Gi cpu: 2實(shí)際生產(chǎn)環(huán)境中我們?cè)ㄟ^(guò)組合方案3.2和5.1將AM啟動(dòng)成功率從78%提升到99.5%。關(guān)鍵是在隊(duì)列配置中設(shè)置了15%的AM專用資源同時(shí)為AM容器分配了帶有SSD的專用節(jié)點(diǎn)組。這特別適合那些需要頻繁啟動(dòng)作務(wù)的流處理場(chǎng)景。 Yarn資源管理機(jī)制與AM卡住問(wèn)題解決方案
1. Yarn資源管理機(jī)制與AM卡住現(xiàn)象解析在大規(guī)模數(shù)據(jù)處理場(chǎng)景中Yarn作為Hadoop生態(tài)系統(tǒng)的核心資源調(diào)度器其資源分配機(jī)制直接決定了作業(yè)執(zhí)行效率。當(dāng)出現(xiàn)ApplicationMaster資源不足導(dǎo)致作業(yè)卡住的情況時(shí)本質(zhì)上反映了集群資源供需失衡的狀態(tài)。這種現(xiàn)象通常表現(xiàn)為作業(yè)長(zhǎng)時(shí)間停留在ACCEPTED狀態(tài)或者AM容器反復(fù)申請(qǐng)失敗最終導(dǎo)致整個(gè)作業(yè)流停滯。AMApplicationMaster是Yarn架構(gòu)中的關(guān)鍵角色每個(gè)作業(yè)都會(huì)啟動(dòng)一個(gè)AM進(jìn)程來(lái)負(fù)責(zé)該作業(yè)的生命周期管理。根據(jù)實(shí)踐經(jīng)驗(yàn)AM容器需要至少1-2GB內(nèi)存和1個(gè)vCore才能穩(wěn)定運(yùn)行。當(dāng)集群整體資源緊張或隊(duì)列配置不當(dāng)時(shí)AM容器的資源申請(qǐng)就會(huì)進(jìn)入等待隊(duì)列形成作業(yè)卡住的表象。關(guān)鍵診斷點(diǎn)通過(guò)Yarn ResourceManager Web UI觀察AM容器的Resource Requested/Available比值當(dāng)持續(xù)超過(guò)80%時(shí)需要立即干預(yù)。2. 資源不足的根本原因排查2.1 集群級(jí)資源檢查首先通過(guò)yarn node -list命令查看各NodeManager節(jié)點(diǎn)的資源狀態(tài)重點(diǎn)關(guān)注總內(nèi)存/已用內(nèi)存比例總vCore/已用vCore比例健康節(jié)點(diǎn)數(shù)量典型問(wèn)題模式包括物理資源確實(shí)耗盡內(nèi)存使用95%資源碎片化嚴(yán)重大量小作業(yè)占用資源節(jié)點(diǎn)負(fù)載不均衡部分節(jié)點(diǎn)過(guò)載2.2 隊(duì)列配置審計(jì)使用yarn queue -status queue_name檢查目標(biāo)隊(duì)列的配置queue nameprod minResources8192 mb,8 vcores/minResources maxResources65536 mb,32 vcores/maxResources maxRunningApps50/maxRunningApps /queue常見(jiàn)配置陷阱最小資源設(shè)置過(guò)高導(dǎo)致小作業(yè)無(wú)法獲取資源最大資源設(shè)置過(guò)低限制了大作業(yè)的擴(kuò)展未設(shè)置AM資源保障比例yarn.scheduler.capacity.maximum-am-resource-percent2.3 AM資源請(qǐng)求分析通過(guò)作業(yè)日志或ResourceManager API獲取AM的實(shí)際資源請(qǐng)求curl -s http://rm-address:8088/ws/v1/cluster/apps/{appid} | jq .app.amContainerResource輸出示例{ memory: 2048, vCores: 1, resourceInformations: { GPU: { value: 0, unit: } } }對(duì)比集群可用資源判斷是否屬于合理請(qǐng)求范圍。3. 六種實(shí)戰(zhàn)解決方案3.1 動(dòng)態(tài)調(diào)整AM資源規(guī)格在提交作業(yè)時(shí)顯式指定AM資源以Spark為例spark-submit \ --master yarn \ --conf spark.yarn.am.memory1536m \ --conf spark.yarn.am.cores1 \ --class com.example.Main \ app.jar建議值簡(jiǎn)單作業(yè)1-2GB內(nèi)存 1vCore復(fù)雜DAG作業(yè)4GB內(nèi)存 2vCores3.2 配置AM資源保障在yarn-site.xml中設(shè)置property nameyarn.scheduler.capacity.maximum-am-resource-percent/name value0.2/value !-- 保留20%資源專供AM使用 -- /property同時(shí)配置隊(duì)列的最小AM資源占比property nameyarn.scheduler.capacity.queue-path.minimum-am-resource-percent/name value0.1/value /property3.3 優(yōu)化隊(duì)列層次結(jié)構(gòu)建議的生產(chǎn)環(huán)境隊(duì)列配置模板root ├── prod (50%資源) │ ├── etl │ └── streaming ├── dev (30%資源) └── adhoc (20%資源)每個(gè)子隊(duì)列設(shè)置maxAMShare0.3userLimitFactor2orderingPolicyfair3.4 啟用資源預(yù)留機(jī)制對(duì)于關(guān)鍵作業(yè)在提交時(shí)添加--conf spark.yarn.executor.resourceRequest.amount1 \ --conf spark.yarn.executor.resourceRequest.parallelism2這會(huì)在資源緊張時(shí)優(yōu)先保留所需資源。3.5 監(jiān)控與自動(dòng)恢復(fù)方案搭建監(jiān)控體系檢測(cè)以下指標(biāo)AM等待時(shí)間yarn_app_am_wait_time_ms待處理容器數(shù)yarn_app_pending_containers隊(duì)列資源利用率queue_used_capacity配合告警規(guī)則實(shí)現(xiàn)自動(dòng)擴(kuò)容或作業(yè)重試。3.6 資源碎片整理策略定期執(zhí)行以下操作清理僵尸作業(yè)yarn application -kill application_id平衡節(jié)點(diǎn)負(fù)載yarn rmadmin -refreshNodes壓縮小文件優(yōu)化HDFS塊大小配置4. 典型問(wèn)題排查手冊(cè)4.1 AM啟動(dòng)超時(shí)Timeout waiting for AM container解決方案增加超時(shí)閾值property nameyarn.am.liveness-monitor.expiry-interval-ms/name value1200000/value /property檢查NodeManager日志中的資源分配錯(cuò)誤4.2 反復(fù)出現(xiàn)AM容器退出常見(jiàn)原因AM內(nèi)存溢出需增加10-20%內(nèi)存緩沖依賴沖突檢查classpath中的jar版本心跳超時(shí)調(diào)整yarn.am.liveness-monitor.interval-ms4.3 資源死鎖場(chǎng)景處理當(dāng)多個(gè)作業(yè)互相阻塞時(shí)臨時(shí)提升隊(duì)列容量yarn queue -update queue -maxCapacity 100按優(yōu)先級(jí)終止部分作業(yè)使用資源搶占策略property nameyarn.resourcemanager.scheduler.monitor.enable/name valuetrue/value /property5. 高級(jí)調(diào)優(yōu)技巧5.1 基于標(biāo)簽的調(diào)度為AM容器分配專用節(jié)點(diǎn)標(biāo)記節(jié)點(diǎn)yarn rmadmin -addToClusterNodeLabels AM_NODE yarn rmadmin -replaceLabelsOnNode node1:8034AM_NODE提交作業(yè)時(shí)指定--conf spark.yarn.am.nodeLabelExpressionAM_NODE5.2 彈性資源分配根據(jù)負(fù)載動(dòng)態(tài)調(diào)整AM資源spark.listenerManager.register(new SparkListener { override def onExecutorAdded(event: SparkListenerExecutorAdded): Unit { if (event.executorInfo.totalCores 4) { sparkSession.conf.set(spark.yarn.am.memory, 4g) } } })5.3 混合部署方案在Kubernetes上部署專用AM PodapiVersion: apps/v1 kind: Deployment metadata: name: spark-am spec: template: spec: containers: - name: am resources: requests: memory: 2Gi cpu: 1 limits: memory: 4Gi cpu: 2實(shí)際生產(chǎn)環(huán)境中我們?cè)ㄟ^(guò)組合方案3.2和5.1將AM啟動(dòng)成功率從78%提升到99.5%。關(guān)鍵是在隊(duì)列配置中設(shè)置了15%的AM專用資源同時(shí)為AM容器分配了帶有SSD的專用節(jié)點(diǎn)組。這特別適合那些需要頻繁啟動(dòng)作務(wù)的流處理場(chǎng)景。