（161）慢磁盤監(jiān)控

慢磁盤，是指寫入數(shù)據(jù)時特別慢的一類磁盤。這種磁盤并不少見，當(dāng)機器運行久了，跑任務(wù)跑的多了，磁盤的壽命到一定程度的時候，磁盤的讀寫性能自然就會退化，嚴(yán)重時就會出現(xiàn)寫數(shù)據(jù)延遲的問題。

比如說，如果正常在HDFS上創(chuàng)建一個目錄，只需要1s左右。但是你偶爾發(fā)現(xiàn)創(chuàng)建目錄時超過了1分鐘或者更久，但次數(shù)不多，就很有可能存在慢磁盤。

那怎么找到是哪塊磁盤慢呢？

第一種方式是通過心跳未聯(lián)系時間。

一般出現(xiàn)慢磁盤現(xiàn)象，會影響到DataNode與NameNode之間的心跳。正常情況心跳時間間隔是3s。超過3s說明有異常。

第二種方式，是通過fio命令，測試磁盤的讀寫性能。

（1）順序讀測試

[atguigu@hadoop102 ~]# sudo yum install -y fio[atguigu@hadoop102 ~]# sudo fio -filename=/home/atguigu/test.log -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_rRun status group 0 (all jobs):READ: bw=360MiB/s (378MB/s), 360MiB/s-360MiB/s (378MB/s-378MB/s), io=20.0GiB (21.5GB), run=56885-56885msec

結(jié)果顯示，磁盤的總體順序讀速度為360MiB/s。

（2）順序?qū)憸y試

[atguigu@hadoop102 ~]# sudo fio -filename=/home/atguigu/test.log -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_wRun status group 0 (all jobs):WRITE: bw=341MiB/s (357MB/s), 341MiB/s-341MiB/s (357MB/s-357MB/s), io=19.0GiB (21.4GB), run=60001-60001msec

結(jié)果顯示，磁盤的總體順序?qū)懰俣葹?41MiB/s。

（3）隨機寫測試

[atguigu@hadoop102 ~]# sudo fio -filename=/home/atguigu/test.log -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_randwRun status group 0 (all jobs):WRITE: bw=309MiB/s (324MB/s), 309MiB/s-309MiB/s (324MB/s-324MB/s), io=18.1GiB (19.4GB), run=60001-60001msec

結(jié)果顯示，磁盤的總體隨機寫速度為309MiB/s。

（4）混合隨機讀寫：

[atguigu@hadoop102 ~]# sudo fio -filename=/home/atguigu/test.log -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=test_r_w -ioscheduler=noopRun status group 0 (all jobs):READ: bw=220MiB/s (231MB/s), 220MiB/s-220MiB/s (231MB/s-231MB/s), io=12.9GiB (13.9GB), run=60001-60001msecWRITE: bw=94.6MiB/s (99.2MB/s), 94.6MiB/s-94.6MiB/s (99.2MB/s-99.2MB/s), io=5674MiB (5950MB), run=60001-60001msec

結(jié)果顯示，磁盤的總體混合隨機讀寫，讀速度為220MiB/s，寫速度94.6MiB/s。

隨機讀寫會稍慢一些，這個是合理的，因為多了步磁盤尋址的過程，所以會多花些時間。

（162）小文件歸檔

小文件過多的問題

HDFS存儲的小文件過多，會極大的影響數(shù)據(jù)搜索和讀取的速度。

100個1K的文件塊和100個128M的文件塊，占用NN的內(nèi)存是一樣的。

因為NN在內(nèi)存里會為每個文件塊存儲一份150byte大小的元數(shù)據(jù)。

所以在副本數(shù)為3的情況下，128個1M的文件塊，在DN中占用存儲空間是128 * 3M，在NN中占用128 * 150byte。

而1個128M的文件塊，在DN中占用128*3M，在NN中占用1*150byte

看出問題了吧，雖然兩種情況下占用的DN存儲空間是一樣的，但是小文件情況下，NN占用的內(nèi)存飆升，關(guān)鍵是占用的這部分內(nèi)存太過浪費了。

解決小文件的方法之一，就是 使用HAR文件來進行歸檔 ?？梢院唵卫斫獬?#xff0c;HAR會把小文件進行壓縮，壓縮成一個文件，放進一個文件塊里。

壓縮產(chǎn)生的HAR文件會被NameNode視為是一個整體，但是其內(nèi)部仍然是多個小文件。但是在NameNode登記的時候，就會作為一個整體來登記了。

如何對小文件進行歸檔

接下來來做一個案例實操：

（1）需要啟動YARN進程

[atguigu@hadoop102 hadoop-3.1.3]$ start-yarn.sh

啟動yarn進程是因為這個壓縮歸檔的過程其實是一個MR處理，因此必須要開啟YARN來做調(diào)度。

（2）歸檔文件

把/input目錄里面的所有文件歸檔成一個叫input.har的歸檔文件，并把歸檔后文件存儲到/output路徑下。

[atguigu@hadoop102 hadoop-3.1.3]$ hadoop archive -archiveName input.har -p /input  /output

（3）查看歸檔

[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -ls /output/input.har[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -ls har:///output/input.har

使用第一個指令嘗試查看歸檔文件的話，是無法查看到被壓縮的一個個小文件的，只能看到幾個壓縮的索引文件和特殊格式的數(shù)據(jù)文件。

使用第二種指令，是可以成功看到被壓縮的一個個小文件。

（4）解歸檔文件

[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -cp har:///output/input.har/*  /

這個是把歸檔文件在指定目錄重新解壓出來。

參考文獻

1. 【尚硅谷大數(shù)據(jù)Hadoop教程，hadoop3.x搭建到集群調(diào)優(yōu)，百萬播放】