慢磁盘,是指写入数据时特别慢的一类磁盘。这种磁盘并不少见,当机器运行久了,跑任务跑的多了,磁盘的寿命到一定程度的时候,磁盘的读写性能自然就会退化,严重时就会出现写数据延迟的问题。
比如说,如果正常在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。
随机读写会稍慢一些,这个是合理的,因为多了步磁盘寻址的过程,所以会多花些时间。
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/* /
这个是把归档文件在指定目录重新解压出来。