1.總結
"Slow ReadProcessor" 和"Slow BlockReceiver"往往是因為集群負載比較高或者某些節點不健康導致的,本文主要是幫助你確認是因為集群負載高導致的還是因為某些節點的硬件問題。
2.症狀
1.作業比以前運行的時間變長
2.Job的日志中有以下WARN的信息
2018-04-18 00:16:11,632 WARN [ResponseProcessor for block BP-<pool_id>:blk_<block_id>] org.apache.hadoop.hdfs.DFSClient: Slow ReadProcessor read fields took 57485ms (threshold=30000ms); ack: seqno: 4 status: SUCCESS status: SUCCESS status: SUCCESS downstreamAckTimeNanos: 3284342, targets: [DatanodeInfoWithStorage[x.x.x.x:50010,DS-26391dd6-c34d-4f7a-a6ff-6b9d264a6edd,DISK], DatanodeInfoWithStorage[x.x.x.x:50010,DS-1840e064-e616-49d5-8ead-91f65bb3af93,DISK], DatanodeInfoWithStorage[x.x.x.x:50010,DS-e884e0d2-b1a1-414d-925c-5d6efd1258e4,DISK]]
3.Datanode的日志中有以下WARN信息
2018-04-17 06:23:48,796 WARN org.apache.hadoop.hdfs.server.datanode.DataNode: Slow BlockReceiver write packet to mirror took 341ms (threshold=300ms) 2016-06-21 06:23:55,775 WARN org.apache.hadoop.hdfs.server.datanode.DataNode: Slow BlockReceiver write data to disk cost:873ms (threshold=300ms) 2018-04-17 08:37:52,397 WARN org.apache.hadoop.hdfs.server.datanode.DataNode: Slow flushOrSync took 534ms (threshold=300ms), isSync:false, flushTotalNanos=533345033ns 2018-04-17 08:38:57,929 WARN org.apache.hadoop.hdfs.server.datanode.DataNode: Slow manageWriterOsCache took 331ms (threshold=300ms)
請注意,單個節點的硬件問題可能會在整個群集中導致“Slow”錯誤。
3.原因
症狀 |
原因 |
---|---|
集群負載高 |
如果你的集群處於或接近資源上限(內存,cpu或磁盤),則你在處理作業時,你的集群可能無法確保數據本地化,因此需要在網絡上傳輸數據塊。如果是這種情況,由於使用集群上的額外負載來傳輸數據塊,因此可能會在作業或數據節點中看到WARN消息。 |
Slow BlockReceiver write packet to mirror |
這表明在網絡上寫入塊時有延遲 |
Slow BlockReceiver write data to disk cost |
這表示在將塊寫入OS緩存或磁盤時存在延遲 |
Slow flushOrSync |
這表示在將塊寫入OS緩存或磁盤時存在延遲 |
Slow manageWriterOsCache |
這表示在將塊寫入OS緩存或磁盤時存在延遲 |
需要注意的是,在生產環境的正常負載下,一些集群的WARN消息在datanode日志中是正常的。當單個節點具有比正常情況更多的上述WARN消息時,表明存在底層硬件問題。
4.解決辦法
以下步驟將有助於確定導致DataNode日志中的“Slow”消息的底層硬件問題。
1.在每個DataNode上運行以下命令來收集所有Slow消息的計數:
egrep -o "Slow.*?(took|cost)" /path/to/current/datanode/log | sort | uniq -c
該命令將提供DataNode日志中所有“Slow”消息的計數。輸出將類似於:
1000 Slow BlockReceiver write data to disk cost
234 Slow BlockReceiver write packet to mirror took 4 Slow flushOrSync took 6 Slow manageWriterOsCache took
2.如果單個節點的一個或多個類別的”Slow“消息比其他主機的”Slow“消息數量多出數量級,則需要調查底層硬件問題。
3.如果Slow消息數最多的是Slow BlockReceiver write packet tomirror took,請通過以下命令的輸出來調查可能的網絡問題:
- ifconfig -a(定期檢查問題主機上增加的errors和dropped的數量,往往代表的是網卡,網線或者上游的網絡有問題)
- netstat -s(與正常節點相比,查找大量重新傳輸的數據包或其他異常高的指標)。
- netstat -s | grep -i retrans(整個集群執行)。 (在一個或多個節點上查找大於正常的計數)。
4.如果Slow消息最多的是一些其他消息,請使用以下命令檢查磁盤問題:
- iostat[高iowait百分比,超過15%]
- iostat -x和sar -d(特定分區的高await或%util)
- dmesg (磁盤錯誤)
- 使用smartctl對磁盤進行健康檢查:停止受影響節點的所有Hadoop進程,然后運行sudo smartctl -H /dev/<disk>,檢查HDFS使用的每塊<disk>