常見問題

YARN集群還有資源，為什么部分任務(wù)還是一直處于ACCEPT狀態(tài)？

大數(shù)據(jù)集群還剩有很多資源，部分任務(wù)還是一直處于ACCEPT狀態(tài)。首先，處于ACCEPTED狀態(tài)則說明ApplicationMaster沒有創(chuàng)建，很大概率和資源有關(guān)。比較常見的原因有兩個：

1. 集群的AM資源不足
   yarn資源劃分為AM資源和計算資源，AM資源顧名思義是專門為ApplicationMaster準(zhǔn)備的資源，當(dāng)集群中AM的資源用盡之后，剩余的任務(wù)則無法創(chuàng)建ApplicationMaster，即使還有剩余的計算資源。所以此時可適當(dāng)調(diào)整AM資源所占的比例來使任務(wù)繼續(xù)執(zhí)行。
2. 相應(yīng)的隊列資源不足
   隊列資源不足也會導(dǎo)致任務(wù)處于ACCEPTED狀態(tài)，有人可能會問，隊列資源我分配的是最大100%，為什么還不會去占用集群剩余的資源呢?看下一問題。

還有一種可能，多與集群外客戶端有關(guān)，是客戶端無法與YARN節(jié)點正常通信造成的。具體的做法參考《Spark提交HDP YARN任務(wù)》。

隊列設(shè)置最大可用資源為100%，但集群資源始終無法占滿

當(dāng)使用一個用戶高負(fù)荷執(zhí)行任務(wù)到某個隊列時，即使該隊列配置的可用資源為100%，但任務(wù)始終無 法占滿全部資源。該問題為用戶因子參數(shù)影響。yarn為了避免一個用戶占據(jù)所有資源，增加了用戶因子這樣一個參數(shù)，該參數(shù)可以限制一個用戶能夠占用隊列資源的多少。下面舉個栗子：

AB兩隊列，A/B最小容量各為50%，最大容量均為100%。
yarn.scheduler.capacity.root.A.user-limit-factor=1； B隊列空閑，A隊列滿任務(wù)運行時會發(fā)現(xiàn)資源仍舊不能充分占用。
原因：user-limit-factor=1，通過計算公式min(capacity*user-limit-factor,maximum-capacity)，該用戶能拿到A隊列的最大資源為min(50%*1,100%)，集群50%的資源。增大user-limit-factor即可實現(xiàn)資源的充分利用。

Timeline Server是什么服務(wù)，有什么用？

引用官方的描述——持久化應(yīng)用特定信息和保存已完成應(yīng)用的相關(guān)信息 ，通俗的理解就像是mapreduce的Job Historyserver，保存應(yīng)用的相關(guān)信息。目前有1.5版本和2.0版本，1.5使用leveldb的形式將 數(shù)據(jù)保存在本地，2.0則存儲在內(nèi)嵌或者分布式的HBase中，2.0性能和功能比1.5提升較多，但由于引入HBase，所以故障率也有所升高。

可以不用，不影響作業(yè)執(zhí)行。

報錯Connection reset by peer

連接斷開后，讀和寫操作引起的異常。常見的原因有以下幾點：

• 防火墻未關(guān)（關(guān)閉防火墻）
• ulimit值太小 （增大系統(tǒng)上ulimit的值）
• nm心跳丟失 （檢查集群網(wǎng)絡(luò)、agent或重啟NodeManger等等）

開啟kerberos后，執(zhí)行任務(wù)報錯Operation not permitted？

main : run as user is ambari-qa 
main : requested yarn user is ambari-qa 
Error setting supplementary groups for user ambari-qa: Operation not permitted

此問題是setuid操作被阻止導(dǎo)致，存在nosuid或者掛載情況。使用root用戶啟動NM時，錯誤消失。參考鏈接：
https://henning.kropponline.de/2017/02/05/yarn-secure-container/

開啟cpu調(diào)度后，執(zhí)行任務(wù)報錯run as user is nobody?

此問 題 官 方 有 相 關(guān) 介 紹 。 是 因 為 開 啟 cpu 調(diào) 度 之 后 ， container-executor 的主類由DefaultContainerExecutor(DCE)轉(zhuǎn)變?yōu)?code>LinuxContainerExecutor(LCE)，而如果在非安全情況下，默認(rèn)LCE使用nodoby用戶提交作業(yè)。可以通過以下兩個配置實現(xiàn)其他用戶提交。

nobody

TimelineServer Reader服務(wù)啟動報錯？

TimelineServer Reader服務(wù)啟動時報錯，主要是由于HBase造成的，包括與HBase的交互，HBase與zk的 交互，所以出現(xiàn)問題的概率也比較大。
首先TimelineServer有兩類方式使用hbase，一類是內(nèi)嵌的HBase， 另一類是外部的HBase。內(nèi)嵌的HBase又有兩種啟動HBase的方式，第一種是container的形式啟動HBase，第二種是使用HBase命令行的形式啟動。開源版本的兩者之間的選擇是判斷每個NM節(jié)點資源大于10G，總集群資源大于50G時選擇使用第一種，否則使用第二種。

RM和NM服務(wù)進程正常，但RM識別不到NM

RM和NM服務(wù)進程正常，但RM卻識別不到NM，主要是和沒有創(chuàng)建local dir或者local dir下面沒有NM的相關(guān)目錄文件導(dǎo)致。第一步應(yīng)檢查local dir目錄是否存在，如果存在再檢查該目錄下是否有以下目錄：

|_filecache
|_nmPrivate 
|_usercache

local dir及下面的目錄均為nm自動生成，創(chuàng)建過程可能會存在延遲。

新安裝的集群YARN服務(wù)無法啟動

Web頁面的現(xiàn)象：
安裝時ResourseManager，check狀態(tài)報紅色。
重啟啟動ResourseManager時有短暫啟動標(biāo)識，但隨后立即轉(zhuǎn)為停止?fàn)顟B(tài)。

查機器上/var/log/hadoop-yarn下的ResourseManager日志，可見明顯報錯：For input string:”undefined” ,由此追溯到與Zookeeper有關(guān)。

排查到集群服務(wù)的安裝順序為YARN早于zookeeper，因此可認(rèn)為yarn安裝時需要寫入zk的數(shù)據(jù)不存在于zk中，因此yarn在讀取時讀到一個undefined，此處應(yīng)為一個數(shù)字，造成了解析錯誤。

解決辦法：
由此，依次關(guān)閉所有的YARN服務(wù)，因為這是新安裝集群，沒有任何業(yè)務(wù)運行，故選擇卸載yarn服務(wù)進行重新安裝即可。

YARN的常用配置

ResourceManager的配置

NodeManager的配置

YARN的日志配置

YARN Capacity調(diào)度隊列的參數(shù)

YARN調(diào)度隊列Capacity-參數(shù)

點：YARN Debug，YARN配置
線：YARN
面：資源調(diào)度