Hadoop節點需要很長時間才能退役

編輯：我終於想出了問題所在。有些文件具有非常高的複製因子集，而我正在將我的羣集縮減爲2個節點。一旦我減少了這些文件的複製因素，退役成功就很快結束。Hadoop節點需要很長時間才能退役

我已經添加在dfs.hosts.exclude和mapred.hosts.exclude文件退役的節點，然後執行此命令：

bin/hadoop dfsadmin -refreshNodes。

在NameNode用戶界面中，我看到此節點在Decommissioning Nodes之下，但它耗時過長，而且我沒有關於正在停用的節點的很多數據。

它是否總是需要很長時間才能解散節點或者是否應該找一些地方？我不確定究竟發生了什麼。

我看不出有任何損壞塊也是這個節點上：

$ ./hadoop/bin/hadoop fsck -blocks/
Total size: 157254687 B 
Total dirs: 201 
Total files: 189 (Files currently being written: 6) 
Total blocks (validated):  140 (avg. block size 1123247 B) (Total open file blocks (not validated): 1) 
Minimally replicated blocks: 140 (100.0 %) 
Over-replicated blocks:  6 (4.285714 %) 
Under-replicated blocks:  12 (8.571428 %) 
Mis-replicated blocks:   0 (0.0 %) 
Default replication factor: 2 
Average block replication:  1.9714285 
Corrupt blocks:    0 
Missing replicas:    88 (31.884058 %) 
Number of data-nodes:   3 
Number of racks:    1 
FSCK ended at Mon Jul 22 14:42:45 IST 2013 in 33 milliseconds 


The filesystem under path '/' is HEALTHY 

$ ./hadoop/bin/hadoop dfsadmin -report 
Configured Capacity: 25357025280 (23.62 GB) 
Present Capacity: 19756299789 (18.4 GB) 
DFS Remaining: 19366707200 (18.04 GB) 
DFS Used: 389592589 (371.54 MB) 
DFS Used%: 1.97% 
Under replicated blocks: 14 
Blocks with corrupt replicas: 0 
Missing blocks: 0 

------------------------------------------------- 
Datanodes available: 3 (3 total, 0 dead) 

Name: 10.40.11.107:50010 
Decommission Status : Decommission in progress 
Configured Capacity: 8452341760 (7.87 GB) 
DFS Used: 54947840 (52.4 MB) 
Non DFS Used: 1786830848 (1.66 GB) 
DFS Remaining: 6610563072(6.16 GB) 
DFS Used%: 0.65% 
DFS Remaining%: 78.21% 
Last contact: Mon Jul 22 14:29:37 IST 2013 


Name: 10.40.11.106:50010 
Decommission Status : Normal 
Configured Capacity: 8452341760 (7.87 GB) 
DFS Used: 167412428 (159.66 MB) 
Non DFS Used: 1953377588 (1.82 GB) 
DFS Remaining: 6331551744(5.9 GB) 
DFS Used%: 1.98% 
DFS Remaining%: 74.91% 
Last contact: Mon Jul 22 14:29:37 IST 2013 


Name: 10.40.11.108:50010 
Decommission Status : Normal 
Configured Capacity: 8452341760 (7.87 GB) 
DFS Used: 167232321 (159.49 MB) 
Non DFS Used: 1860517055 (1.73 GB) 
DFS Remaining: 6424592384(5.98 GB) 
DFS Used%: 1.98% 
DFS Remaining%: 76.01% 
Last contact: Mon Jul 22 14:29:38 IST 2013

來源

2013-07-22 Srikanth

退役不是一個瞬間的過程，即使你沒有太多的數據。

首先，當您退役時，意味着數據必須被複制到相當多的塊（取決於您的塊大小有多大），並且這可能很容易覆蓋您的羣集並導致操作問題，所以我相信這是有點扼殺。

此外，根據您使用的Hadoop版本，監視中斷的線程每隔一段時間纔會喚醒。過去的Hadoop版本過去大約需要5分鐘，但現在我認爲這是每分鐘或更少的時間。

退役正在進行意味着該塊被複制，所以我想這真的取決於你有多少數據，你不得不等待，因爲這將不被充分利用集羣完成這個任務。

來源

2013-07-22 18:59:53

感謝您的回答。我終於明白了問題所在。有些文件具有非常高的複製因子集，而我正在將我的羣集縮減爲2個節點。一旦我減少了這些文件的複製因素，退役成功就很快結束。 – Srikanth

在進行退役時，臨時文件或臨時文件會自動清理。這些文件現在丟失了，hadoop沒有意識到如何失蹤。因此，即使對所有其他文件進行了實際的退役，退役過程也會一直等待，直到解決方案結束。

在Hadoop GUI中 - 如果您注意到參數「不足重複塊的數量」在整個時間內沒有減少或幾乎不變，那麼這很可能是原因。

因此，使用下面的命令

的Hadoop的fsck/-files -blocks -racks

如果你看到這些文件都是暫時的，不需要再刪除這些文件或文件夾

舉例列出文件： hadoop fs -rmr /var/local/hadoop/hadoop/.staging/*（在此給出正確的路徑）

這將立即解決問題。未委任節點將在5分鐘內轉移到死節點。

來源

2014-11-10 07:37:20 Prabakaran

請注意，如果您沒有比文件級別或默認級別的複製因子更多的活動數據節點，狀態不會改變或將需要很長時間（並最終失敗）。

來源

2016-06-02 05:27:14 Niks

Hadoop節點需要很長時間才能退役

回答

相關問題