1：解決與空間相關的問題
2：解決內存問題
3：處理不同類型的故障
4：對Spark作業執行進行故障排除
我要繼續講這本書的最後一章，簡短而有趣。故障排除是一個廣闊的領域，我想讓您瞭解一下您可能在hadoop集羣中遇到的一些更有趣的問題。hadoop有很多 配置屬性，並且掌握這些屬性對於充分利用hadoop集羣的投資至關重要。 但是，通過重新配置hadoop的各種組件，只能解決您每天遇到的一些錯誤。
我不認爲對羣集中運行的Hive，Spark或其他作業運行不佳的性能進行分析是故障排除。 “掛起”或長期運行的原因可能是由於代碼不正確或操作員選擇不當，連接策略效率低下或其他原因所致。 同樣，我也不會嘗試討論進程（例如Hive或Hue）無法啓動或崩潰的原因，這些原因通常又是由於主機服務器或組件上的配置錯誤/更改而引起的， 造成此類故障的原因很多，它們都屬於任何類型的常規系統管理，並且並不是Hadoop管理真正的專用。
有空間有關的問題
hadoop使用幾種類型的存儲。除了hdfs本身之外，hadoop還將日誌存儲在主機的/ var目錄以及本地目錄中，這些區域中任何一個與空間相關的問題都可能導致作業失敗，因此最好在本地目錄上進行操作。
正如您在第17章“監視，指標和Hadoop日誌記錄”中所瞭解的那樣，NodeManager始終將應用程序日誌文件存儲在本地目錄中。 即使在啓用日誌聚合（Hadoop將作業日誌存儲在HDFS中）的情況下，也是如此，因爲所有日誌都首先存儲在本地存儲中。 如果日誌目錄所在的掛載點已滿，則NodeManager將無法在該節點上寫入其日誌文件。 如果Hadoop守護程序正在記錄的目錄已滿，情況也是如此。
爲避免任務和潛在的作業失敗，您必須主動檢查這些安裝點下的可用空間，並清除所有不必要的文件。 如果無法刪除足夠的空間，則可能需要擴展安裝點本身的大小。
您可以通過在存在問題空間的節點上運行以下命令來確定要從這些目錄中刪除哪些文件：
find ./ -size +100000 –type f –ls |sort -n //查詢文件大於25MB的文件
du -a /var |sort –n –r |head –n 10 //查詢一個目錄裏面10大的文件
如果將NodeManager使用的Hadoop守護程序日誌和應用程序本地目錄的位置設置爲/ var目錄，請理解該目錄與tmp等其他目錄共享根文件系統（“ /”分區）。 除了Hadoop守護進程和NodeManager應用程序日誌之外，您可能還使用/ var目錄記錄來自多個與Hadoop相關的組件（例如ZooKeeper，Hive和Hue）的輸出。 因此，需要編寫一個簡單的shell腳本，該腳本會在此安裝點警告您空間不足的情況。
如果用yarn.nodemanager.local-dirs參數指定的NodeManager本地目錄在某個節點上填滿，則應用程序可能會失敗，因爲它嘗試在該節點上啓動的任務數量超過配置的嘗試次數。 在應用程序的日誌文件中，您將收到與以下內容類似的錯誤：
Application application_1437683566204_0394 failed 2 times due to AM Container for
appattempt_1437683566204_0394_000002 exited with exitCode: -1000 due to:No space available in any of the local directories. .Failing this attempt.. Failing the application.
處理100％完整的linux文件系統
有時，文件系統可能會報告它已100％充滿。 如果這恰好是根文件系統之類的掛載點，則將立即引發麻煩，因爲這是大多數文件存儲其Hadoop相關本地日誌（在/ var / log下）的地方。 顯然，某些用戶生成了一個大的轉儲文件，或者一個巨大的臨時文件存儲在已滿的目錄中。 請按照以下步驟釋放已用完的目錄中的空間.
使用find命令確定安裝點下最大的文件。 這是一個這樣的命令：
du –a /var |sort –n –r |head –n 10
確定最大的文件後，請刪除對集羣操作不重要的所有文件。
Hdfs 空間問題
HDFS空間問題可能有兩種類型：第一種是羣集中的HDFS可用空間不足時。 第二種情況是個別用戶違反了您分配給他們的HDFS配額。 這些用戶也可以稱爲功能帳戶，即您用來提交作業的通用用戶名，例如名爲produser的HDFS用戶。
如果羣集中HDFS的可用空間越來越少，有兩種基本的解決方案可用於增加空間：添加更多節點或向現有節點添加更多磁盤。
可以增加可用HDFS空間的另一種方法是刪除不再需要的數據，並減少歷史數據的複製因子，這些歷史數據被認爲與新數據沒有那麼重要。
如果用戶發佈的作業由於達到其最大配置的HDFS空間配額而失敗，則需要使用dfsadmin setSpaceQuota命令增加用戶的空間配額，如第9章“ HDFS命令，HDFS權限和HDFS存儲”中所述。 ”
要保持與HDFS配額相關的問題的領先地位，一種方法是定期運行以下命令，該命令顯示我所有用戶當前對HDFS空間的使用情況以及每個用戶仍在使用的HDFS空間配額的範圍 有：
hdfs dfs -count -q -h /user/* 查看某個空間配額
hdfs dfs –count q –h命令的部分輸出顯示，用戶alapati已使用了該用戶分配的30GB空間配額中的10GB。 因此，該用戶的空間配額還剩下20GB。 如果用戶不滿分配的空間配額，請使用dfsadmin -setSpaceQuota命令增加空間配額。
本地和日誌目錄的可用空間不足
在本章的前面，您瞭解了可以使用yarn.nodemanager.local-dirs參數指定NodeManager的本地目錄，並使用yarn.nodemanager.log-dirs參數指定NodeManager的日誌目錄。 Hadoop會定期執行磁盤運行狀況檢查。 如果可用空間低於閾值，則NodeManager將在其運行的節點上不啓動任何新容器。
兩個關鍵參數（yarn.nodemanager.disk-health-checker.min-healthydisks和yarn.nodemanager.disk-health-checker.max-disk-utilization-perdisk-percentage）在NodeManager的行爲方式中起着至關重要的作用。 本地目錄或日誌目錄空間不足的問題。 這是兩個參數如何確定Hadoop在每個存儲磁盤上使用的空間百分比，以及它如何認爲節點具有足夠數量的正常存儲驅動器：
yarn.nodemanager.disk-health-checker.max-disk-utilization-per diskpercentage：一旦磁盤達到此參數設置的空間利用閾值，它就會被標記爲不良（或不正常）。 您可以爲此參數設置一個介於0.0和100.0之間的值，默認值爲90.0。 一旦磁盤使用率超過90％，仍可以使用，但內部標記爲不良或運行不正常。 請記住，這適用於您指定爲yarn-nodemanager.local-dirs和yarn.nodemanager.log-dirs參數值的目錄。
yarn.nodemanager.disk-health-checker.min-healthy-disks：此參數確定節點上必須健康的磁盤總數的最小比例。 如果節點上的正常驅動器（本地目錄或日誌目錄）的數量低於此閾值，則NodeManager不會在該節點上啓動新容器。 實際上，只要進行處理，該節點就會從羣集中移出。 此參數的默認值爲0.25。 如果節點上有十二個磁盤，這意味着它們中至少有四分之一（即三個驅動器）必須處於正常狀態才能使NodeManager在該節點上啓動新容器。
假設您正在使用yarn.nodemanager.disk-healthchecker.max-disk-utilization-per-disk-percentage和yarn.nodemanager的默認值
.disk-health-checker.min-healthy-disks參數。 如果空間有限，並且12個驅動器節點上的10個以上驅動器達到90％的閾值，則NodeManager
不能在這些節點上啓動容器，這意味着該節點上作業的新任務將失敗，並且您會看到類似以下的錯誤：
假設您同時使用yarn.nodemanager.disk-healthchecker.max-disk-utilization-per-disk-percentage和yarn.nodemanager.disk-health-checker.min-healthy-disks參數的默認值。 如果空間有限，並且12個驅動器節點上的10個以上驅動器達到90％的閾值，則NodeManager將阻止在這些節點上啓動容器-這意味着作業在該節點上的新任務將失敗，您將 看到如下錯誤：
Application Type: MAPREDUCE
Application Tags:
State: FAILED
FinalStatus: FAILED
Started: Sat Jul 16 04:01:10 -0500 2016
Elapsed: 13sec
Tracking URL: History
Diagnostics:
Application application_1437683566204_0350 failed 2 times due to AM Container for
appattempt_1437683566204_0350_000002 exited with exitCode: -1000 due to: No space
available in any of the local directories.
.Failing this attempt.. Failing the application.
該錯誤表明NodeManager拒絕啓動ID爲000002的任務，因爲超過了“最小數量”的最小磁盤“不健康”。在3TB驅動器上，90％的已用空間意味着仍有300GB的可用空間，並且很可能可以繼續使用 驅動器。 在這種情況下，您可以執行以下兩項操作之一（或同時執行兩項操作）：
通過爲yarn.nodemanager.disk-health-checker.max-disk-utilization-per-diskpercentage參數設置較低的值，降低將磁盤標記爲不良的閾值。
通過設置yarn.nodemanager.disk-health-checker.min-healthy-disks參數來降低健康驅動器的最小數量。
顯然，最好的長期解決方案是爲羣集獲取更多節點。 參數yarn.nodemanager.disk-health-checker.min-free-spaceper-disk-mb確定NodeManager要使用的目錄的本地目錄和日誌目錄中應該有多少可用空間。 默認值爲0。
磁盤卷容錯
如果集羣中很小一部分的DataNode都已失效，則無需擔心，嘗試建立這些節點-Hadoop集羣中需要處理的更好，更關鍵的事情！ 但是，請務必跟蹤死節點的數量，並且當死節點的數量達到可觀數量時，請努力使這些節點恢復原狀。 與傳統的數據庫不同，在傳統的數據庫中丟失磁盤可能會造成災難性的影響，即使發生存儲故障，Hadoop也會輕鬆應對。 您的羣集將以相同的方式運行，但總存儲容量較小。 與傳統RAID系統不同，您可以在方便時修復故障磁盤。 您可以通過設置以下參數來配置節點可以容忍多少磁盤故障：
<property>
<name>dfs.datanode.failed.volumes.tolerated</name>
<value>4</value>
</property>
在這種情況下，Hadoop可以在將DataNode列入黑名單之前容忍四個磁盤卷出現故障。 重要的是要了解，默認情況下，單個卷（磁盤驅動器）發生故障後，DataNode將關閉。 因此，dfs.datanode.failed.volumes.tolerated參數的默認值爲零。 確保將其設置爲2、3或4之類的正數，以確保在單個卷出現故障後DataNodes不會關閉。 一旦失敗次數達到您設置的次數，DataNode將被標記爲“死節點”。
找出Hadoop集羣中是否有任何失敗的卷的最簡單方法是查看NameNode UI的Datanode Volume Failures頁面，如圖21.1所示。
圖21.1 NameNode UI的DataNode Volume Failures頁面，顯示失敗的卷數
熱替換盤
您可以添加或替換磁盤驅動器而無需關閉DataNode，因爲Hadoop支持DataNodes的熱插拔驅動器。 您需要使用新命令dfsadmin –reconfig datanode來執行熱交換。 以下是磁盤驅動器熱交換過程的高級說明。
1，格式化並安裝新的磁盤驅動器。
2，更新hdfs-site.xml文件中的dfs.datanode.data.dir配置屬性。 刪除要替換的故障數據卷，然後添加新數據卷
3，執行dfsadmin -reconfig datanode HOST：PORT start命令開始重新配置。
4.卸載已刪除的數據卷目錄，並在重新配置任務完成後從服務器中刪除磁盤。
設置dfs.datanode.du.reserved參數
在第3章“創建和配置簡單的Hadoop 2集羣”中，您瞭解了hdfs-site.xml文件中的dfs.datanode.du.reserved參數如何讓您設置保留空間的數量（每卷字節數） 用於非HDFS。 儘管存儲HDFS文件的目錄主要是供HDFS使用的，但它們並不完全供HDFS使用。 該目錄還保存Hadoop作業的臨時數據。 確保留出足夠的空間來容納您希望運行的最大Hadoop作業的臨時數據。
很好地使用複製英子
Hadoop使用默認複製級別3，如第3章所述，並在其他位置重複說明。 當然，更高的複製因子意味着更高的磁盤空間使用率，但是更高級別的複製也有其優勢。 高複製級別具有兩個明顯的好處：
更快的性能，尤其是在處理多個應用程序所需的“熱”數據時。
可靠性更高-複製級別越高，從存儲角度來看，數據越可靠。
一直處理accepted State 的yarn job 問題
有時，您可能會遇到在YARN中啓動Spark（或MapReduce）應用程序但從未使其進入RUNNING狀態的情況。 作業只是停留在“接受”狀態。 當Oozie啓動作業或您手動運行它時，可能會發生同樣的事情。 作業將停留在“接受”狀態，並且不會轉換爲“正在運行”狀態。 如果您查看ResourceManager的網絡用戶界面，您還將看到作業狀態爲“已接受”。 如果您查看應用程序日誌，則會看到類似以下的消息：
2016-09-01 00:48:14,121 INFO org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler:Added Application Attempt appattempt_1420073214126_0002_000001 to scheduler from user: admin
2015-09-01 00:48:14,121 INFO org.apache.hadoop.yarn.server.resourcemanager.rmapp.attempt.RMAppAttemptImpl:
appattempt_1420073214126_0002_000001 State change from SUBMITTED to SCHEDULED
您別無選擇，只能在大多數情況下殺死這些作業（yarn application –kill <appid>），然後手動或通過使下一個預定的Oozie作業開始新的作業來重新運行它們。 診斷和解決停滯的工作問題通常很容易。 我將說明如何在兩種常見情況下解決此問題。
造成工作停滯不前（可能永遠消失）的主要原因是缺乏足夠的資源來啓動工作。 如果一項工作要求爲一個容器（例如64GB）請求大量的RAM，但是羣集中沒有節點具有64GB的可用內存，則YARN將不會啓動該工作。 在這種情況下，您無能爲力，但要等到一段時間後釋放出足夠的內存來啓動作業。 您需要重新啓動該作業，因爲它不會自行過渡到“已接受”狀態。 從長遠來看，您可能希望探索增加羣集節點的RAM。
作業可能永遠處於“掛起”狀態的另一個原因是，您通過“公平調度程序”或“容量調度程序”限制了最大的作業數量。 爲確保您沒有將可同時運行的最大作業數設置得太低，如果您正在使用Fair Scheduler在集羣中分配資源，請檢查maxRunningApps隊列元素的值（這將限制 隊列中立即運行的隊列）。 maxRunningApps屬性設置了用戶可以隨時運行的最大應用程序數的限制。 如果您使用的是Capacity Scheduler，請檢查Capacity-scheduler.xml文件中以下屬性的值（這些屬性設置在運行和掛起狀態下可以同時活動的最大應用程序數）：
yarn.scheduler.capacity.maximumapplications/ yarn.scheduler.capacity.<queuepath>.maximum-applications
當然，如果您使用的是Cloudera Manager之類的工具，則需要通過該工具進行更改。 例如，如果您使用的是Cloudera Manager，則可以通過轉到集羣>動態資源池>配置來實現。 此時，您可以先單擊“默認設置”，然後檢查“每個資源池的最大正在運行的應用程序”屬性的值。 接下來，您需要編輯從中啓動該應用程序的特定資源池的配置，並增加Max Running Apps配置屬性的值。
JVM內存分配和垃圾回收策略
一切都在Hadoop的Java虛擬機（JVM）中運行。 要進行良好的故障排除，您必須瞭解JVM如何分配內存以及它們如何執行垃圾回收，這是JVM如何回收較舊和未使用的內存，以便可以將其分配給其他用途。 不同的垃圾收集策略對集羣中應用程序的性能有不同的影響。
第17章“監視，指標和Hadoop日誌記錄”介紹瞭如何通過Ganglia或通過查看各種Hadoop日誌來監視羣集。 如果一切都失敗了，該是回顧Java堆轉儲以找出YARN容器中問題的根本原因了！
瞭解jvm垃圾回收
Java堆是存儲Java程序對象的位置。 如第3章和第18章“調整羣集資源，優化MapReduce作業和基準測試”所述，當您爲映射分配內存或減少容器的JVM時，正是這些參數確定了YARN容器的Java堆大小。 堆可以包含活動對象，無效對象和空閒的未分配內存。 如果沒有正在運行的程序可以到達堆中的特定對象，則將其視爲“垃圾”，並且JVM準備將其從堆中刪除。 垃圾回收是JVM釋放Java堆中未使用的Java對象的方式。
每個JVM的堆都包括三個獨立的部分，稱爲世代。 這三代人分別是年輕的（新一代），老的和永久的。 JVM使用–Xms選項爲年輕人和老年人分配初始大小，而段的最大大小由–Xmx選項設置。 您還可以使用–XX：NewSize選項初始化年輕代的大小，並使用–XX：Newratio選項指定老一代的大小。 如果將–XX：NewRatio參數設置爲3，則表示舊一代的大小是新一代的三倍。
圖21.2顯示了Java堆中的世代
