以下爲使用yarn過程中遇到的問題，會持續更新，也當做是個個人筆記吧，好記性不如爛筆頭。
一、部分nodemanager節點狀態變爲unhealthy
現象：
首先會在ambari界面看到有兩臺機器上的nodemanager被標誌位unhealthy （圖中已經被修復，所以沒有顯示出有unhealthy的。），也可以去yarn的界面有個左邊有個nodes選項，也可以查看nodemanager的服務狀態,命令yarn node -list -all 當然也可以查看。然後我以爲可能是服務有問題，就跑去那兩臺機器去重啓nodemanager，但是發現重啓沒有用，還是兩臺上的nodemanager 狀態爲unhealthy。
如果某臺機器上的nodemanager變爲了unhealthy，那麼那臺內存和cpu都將不可用，這將極大影響我們使用yarn集羣來跑我們的離線任務，所以我們要恢復它。
yarn-site.xml
yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage 這個配置項默認是90，意思是如果路配置項下的yarn.nodemanager.local-dirs路徑或者yarn.nodemanager.log-dirs.配置項下的路徑的磁盤使用率達到了90%以上，則將此臺機器上的nodemanager標誌爲unhealthy，這裏面的值可以設置爲0到100之間，如果超過100的話，就不生效了。
yarn.nodemanager.disk-health-checker.min-healthy-disks 默認值是0.25 只要不足25%的磁盤使用率超過90%，那麼這些機器就會被標誌爲unhealthy，同樣作用於yarn.nodemanager.local-dirs下的路徑或者yarn.nodemanager.log-dirs.配置項下的路徑。
解決方案：
1.刪除以上目錄下的無用數據，讓磁盤使用率降低到90%以下。
2.將 yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage 設置爲100.yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage 設置爲0.
提示：
所以，這也給我們了一種提示和優化方法吧，就是：
yarn.nodemanager.local-dirs下的路徑或者yarn.nodemanager.log-dirs.配置項下的路徑要和hdfs數據路徑分開！！！！！，做到日誌和數據分離。這樣就不會導致hdfs數據寫滿了，yarn也不可用了（unhealthy），也就是磁盤和內存+cpu分離。
二、集羣有資源，但是任務一直停留在accept狀態，一直進入不了RUNNING狀態 或者集羣有資源，但是提交任務不能運行。
首先要明確一下什麼是accept狀態和running狀態，只要你向hadoop yarn提交任務，yarn queue中的待等待任務數沒超過上限，就可以進入accept狀態，這時client就會向yarn申請一個container，來運行application master，只要得到了container 來運行application master，就會進入running狀態，這時你的任務就會開始運行。
通過上述描述，也就是說一個任務從accept狀態轉化爲running狀態的一個充要條件是你的application master獲得一個container 並且運行起來。
也就是說，任務一直停留在accept狀態，一直進入不了RUNNING狀態 或者集羣有資源，但是提交任務不能運行，這個問題的根源是application master 沒獲得到container ，但是有個疑問，我集羣明明有資源，但是爲什麼application master獲得不來資源呢。
明確一下，大家應該都是默認用的是Capacity Scheduler（容量調度器）
在hadoop配置目錄下：capacity-scheduler.xml
或者ambari yarn 配置界面:
yarn.scheduler.capacity.maximum-am-resource-percent=0.2
這個值調爲0.5 或者根據適當情況調大。
這個屬性的意思是你的application master 申請的container資源最大不能超過集羣總資源的百分之多少，默認是百分之20.
舉個例子哈，你的集羣資源總共有100G內存，100*0.2也就是20G，也就是說你的application master申請的container資源總共最大爲20G，假設一個container最小memory爲4G，也就是說，你的application master最多有5個可以並行，如果當第六個任務提交時，即使集羣有資源，但是你的application master獲取不到container，你的任務狀態也無法從accept轉化爲running，你的任務照樣不可以運行，官網說這個其實也是控制任務並行度的，其實也對，因爲你控制了application master的個數，不就是控制了任務並行度嘛？
三、任務長時間卡在map 0%，reduce 0%
如果任務走到這一步，肯定是RUNNING狀態了，application master得到了container資源。
你們應該可以看到你們RUNNING界面，
應該會只顯示這個任務佔用了1個container，內存應該是你配置的container最低配，然後核也是，這時你們應該會有個疑問，就是我任務既然有container了！爲什麼任務進度不會前進呢？是因爲你這1個container僅僅運行了application master，並沒有運行實際工作的exector，所以當然任務不會前進了，也就是說，你這個實際運行的 任務，僅僅領導了一個運行着application master的container ，並沒有執行exector，你領到的僅僅是個“”低保“”而已，所以進度不會前進。
所以，這會導致一個問題，一個大任務和一個小任務同時運行，大任務佔了很多資源，小任務就領導了一份“低保“（僅僅一個container裏運行着application master），這就會導致小任務的運行時間可能會跟大任務運行時間差不多的一種假象。可能會造成這種困擾。這裏要注意哈。
所以！Capacity Scheduler裏面的隊列（資源隔離，分組）多麼重要！
四、Task attempt failed to report status for xxx seconds. Killing!
在mapred-site.xml當中，有個這麼個配置文件：
mapreduce.task.timeout 我們配置的是1200000
意思是：如果mapreduce任務既不讀取輸入，也不寫入輸出，也不更新其狀態字符串，當時間超過1200000毫秒的時候，就會出現這個錯誤，出現這個錯誤可能是出現死循環，我們是長時間scan hbase數據超時。
如果出現這個錯可以增大上述配置時間，或者檢查你的代碼。
五、提交任務到yarn ，出現Unsupported major.minor version 52.0
這個錯誤意思是你項目用JDK1.8運行過，現在又在本地環境變量爲低版本的jdk1.7或者jdk1.6下運行，就會報錯：“本地jdk版本太低，不支持這個jdk1.8編譯過的項目運行”
首先檢查下你編譯代碼的環境和你實際運行的環境是不是jdk8，如果檢查無誤的話，進入下一步。
yarn其實也是會獲取java環境變量的，檢查yarn-env.sh的腳本當中的JAVA_HOME是否是jdk1.8版本，這點也是需要非常注意的。
以後持續更新，目前就先想到這麼多。。