文章目录
（161）慢磁盘监控
慢磁盘，是指写入数据时特别慢的一类磁盘。这种磁盘并不少见，当机器运行久了，跑任务跑的多了，磁盘的寿命到一定程度的时候，磁盘的读写性能自然就会退化，严重时就会出现写数据延迟的问题。
比如说，如果正常在HDFS上创建一个目录，只需要1s左右。但是你偶尔发现创建目录时超过了1分钟或者更久，但次数不多，就很有可能存在慢磁盘。
那怎么找到是哪块磁盘慢呢？
第一种方式是通过心跳未联系时间。
一般出现慢磁盘现象，会影响到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_r
Run 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
结果显示，磁盘的总体顺序读速度为360MiB/s。
（2）顺序写测试
[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_w
Run 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
结果显示，磁盘的总体顺序写速度为341MiB/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_randw
Run 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
结果显示，磁盘的总体随机写速度为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=noop
Run 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-60001msec
WRITE: 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
结果显示，磁盘的总体混合随机读写，读速度为220MiB/s，写速度94.6MiB/s。
随机读写会稍慢一些，这个是合理的，因为多了步磁盘寻址的过程，所以会多花些时间。
（162）小文件归档
小文件过多的问题
HDFS存储的小文件过多，会极大的影响数据搜索和读取的速度。
100个1K的文件块和100个128M的文件块，占用NN的内存是一样的。
因为NN在内存里会为每个文件块存储一份150byte大小的元数据。
所以在副本数为3的情况下，128个1M的文件块，在DN中占用存储空间是128 * 3M，在NN中占用128 * 150byte。
而1个128M的文件块，在DN中占用128*3M，在NN中占用1*150byte
看出问题了吧，虽然两种情况下占用的DN存储空间是一样的，但是小文件情况下，NN占用的内存飙升，关键是占用的这部分内存太过浪费了。
解决小文件的方法之一，就是 使用HAR文件来进行归档 。可以简单理解成，HAR会把小文件进行压缩，压缩成一个文件，放进一个文件块里。
压缩产生的HAR文件会被NameNode视为是一个整体，但是其内部仍然是多个小文件。但是在NameNode登记的时候，就会作为一个整体来登记了。
如何对小文件进行归档
接下来来做一个案例实操：
（1）需要启动YARN进程
[atguigu@hadoop102 hadoop-3.1.3]$ start-yarn.sh
启动yarn进程是因为这个压缩归档的过程其实是一个MR处理，因此必须要开启YARN来做调度。
（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
使用第一个指令尝试查看归档文件的话，是无法查看到被压缩的一个个小文件的，只能看到几个压缩的索引文件和特殊格式的数据文件。
使用第二种指令，是可以成功看到被压缩的一个个小文件。
（4）解归档文件
[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -cp har:///output/input.har/* /
这个是把归档文件在指定目录重新解压出来。