「这是我参与11月更文挑战的第18天,活动详情查看:2021最后一次更文挑战」。
一、HDFS 核心参数
1、NameNode 内存生产配置
-
NameNode内存计算
NameNode内存计算 每个文件块大概占用150byte,一台服务器128G内存为例,能存储多少文件块呢? 128 * 1024 * 1024 * 1024 / 150Byte ≈ 9.1亿 G MB KB Byte
-
Hadoop2.x系列,配置NameNode内存
NameNode内存默认2000m,如果服务器内存4G,NameNode内存可以配置3g。
在hadoop-env.sh文件中配置如下。
HADOOP_NAMENODE_OPTS=-Xmx3072m
-
Hadoop3.x系列,配置NameNode内存
hadoop-env.sh中描述Hadoop的内存是动态分配的
# The maximum amount of heap to use (Java -Xmx). If no unit # is provided, it will be converted to MB. Daemons will # prefer any Xmx setting in their respective _OPT variable. # There is no default; the JVM will autoscale based upon machine # memory size. # export HADOOP_HEAPSIZE_MAX= # The minimum amount of heap to use (Java -Xms). If no unit # is provided, it will be converted to MB. Daemons will # prefer any Xms setting in their respective _OPT variable. # There is no default; the JVM will autoscale based upon machine # memory size. # export HADOOP_HEAPSIZE_MIN= HADOOP_NAMENODE_OPTS=-Xmx102400m
查看NameNode占用内存
[moe@hadoop102 bin]$ jps 6816 NameNode 7558 Jps 6951 DataNode 7289 NodeManager 7471 JobHistoryServer [moe@hadoop102 bin]$ jmap -heap 6816 MaxHeapSize = 1031798784 (984.0MB)
查看DataNode占用内存
[moe@hadoop102 bin]$ jps 6816 NameNode 7654 Jps 6951 DataNode 7289 NodeManager 7471 JobHistoryServer [moe@hadoop102 bin]$ jmap -heap 6951 MaxHeapSize = 1031798784 (984.0MB)
查看发现hadoop102上的NameNode和DataNode占用内存都是自动分配的,且相等。不是很合理。
经验参考:docs.cloudera.com/documentati…
具体修改:hadoop-env.sh
export HDFS_NAMENODE_OPTS="-Dhadoop.security.logger=INFO,RFAS -Xmx1024m" export HDFS_DATANODE_OPTS="-Dhadoop.security.logger=ERROR,RFAS -Xmx1024m"
2、NameNode 心跳并发配置
hdfs-site.xml
The number of Namenode RPC server threads that listen to requests from clients. If dfs.namenode.servicerpc-address is not configured then Namenode RPC server threads listen to requests from all nodes.
NameNode有一个工作线程池,用来处理不同DataNode的并发心跳以及客户端并发的元数据操作。
对于大集群或者有大量客户端的集群来说,通常需要增大该参数。默认值是10。
<property>
<name>dfs.namenode.handler.count</name>
<value>21</value>
</property>
[moe@hadoop102 ~]$ sudo yum install -y python
[moe@hadoop102 ~]$ python
Python 2.7.5 (default, Nov 16 2020, 22:23:17)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-44)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> print int(20*math.log(3))
21
>>>
3、开启回收站配置
开启回收站功能,可以将删除的文件在不超时的情况下,恢复原数据,起到防止误删除、备份等作用。
-
回收站工作机制
-
开启回收站功能参数说明
(1)默认值fs.trash.interval = 0,0表示禁用回收站;其他值表示设置文件的存活时间。
(2)默认值fs.trash.checkpoint.interval = 0,检查回收站的间隔时间。如果该值为0,则该值设置和fs.trash.interval的参数值相等。
(3)要求fs.trash.checkpoint.interval <= fs.trash.interval。
-
启用回收站
修改core-site.xml,配置垃圾回收时间为1分钟。
<property> <name>fs.trash.interval</name> <value>1</value> </property>
-
查看回收站
回收站目录在HDFS集群中的路径:/user/moe/.Trash/...
-
通过网页上直接删除的文件也不会走回收站。
-
通过程序删除的文件不会经过回收站,需要调用moveToTrash()才进入回收站
Trash trash = New Trash(conf); trash.moveToTrash(path);
-
只有在命令行利用hadoop fs -rm命令删除的文件才会走回收站。
[moe@hadoop102 hadoop]$ hadoop fs -rm -r /input 2021-11-17 23:16:50,135 INFO fs.TrashPolicyDefault: Moved: 'hdfs://hadoop102:8020/input' to trash at: hdfs://hadoop102:8020/user/moe/.Trash/Current/input
-
恢复回收站数据
[moe@hadoop102 hadoop]$ hadoop fs -mv /user/moe/.Trash/Current/input /input
二、HDFS 集群压测
在企业中非常关心每天从Java后台拉取过来的数据,需要多久能上传到集群?消费者关心多久能从HDFS上拉取需要的数据?
为了搞清楚HDFS的读写性能,生产环境上非常需要对集群进行压测。
HDFS的读写性能主要受网络和磁盘影响比较大。为了方便测试,将hadoop102、hadoop103、hadoop104虚拟机网络都设置为100mbps。
100Mbps单位是bit;10M/s单位是byte ; 1byte=8bit,100Mbps/8=12.5M/s。
测试网速:来到hadoop102的/opt/module目录,利用python开启一个web服务,方便下边统计测试文件。
[moe@hadoop102 ~]$ cd /opt/module/
[moe@hadoop102 module]$ python -m SimpleHTTPServer
1、测试 HDFS 写性能
写测试底层原理
-
测试内容:向HDFS集群写10个128M的文件
[moe@hadoop102 mapreduce]$ hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -write -nrFiles 10 -fileSize 128MB
Number of files:生成mapTask数量,一般是集群中(CPU核数-1),我们测试虚拟机就按照实际的物理内存-1分配即可
- Total MBytes processed:单个map处理的文件大小
- Throughput mb/sec:单个mapTak的吞吐量
- 计算方式:处理的总文件大小/每一个mapTask写数据的时间累加
- 集群整体吞吐量:生成mapTask数量*单个mapTak的吞吐量
- Average IO rate mb/sec::平均mapTak的吞吐量
- 计算方式:每个mapTask处理文件大小/每一个mapTask写数据的时间 全部相加除以task数量
- IO rate std deviation:方差、反映各个mapTask处理的差值,越小越均衡
-
注意:如果测试过程中,出现异常
- 可以在yarn-site.xml中设置虚拟内存检测为false
<!--是否启动一个线程检查每个任务正使用的虚拟内存量,如果任务超出分配值,则直接将其杀掉,默认是true --> <property> <name>yarn.nodemanager.vmem-check-enabled</name> <value>false</value> </property>
- 分发配置并重启Yarn集群
-
测试结果分析
(1)由于副本1就在本地,所以该副本不参与测试
一共参与测试的文件:10个文件 * 2个副本 = 20个
压测后的速度:1.61
实测速度:1.61M/s * 20个文件 ≈ 32M/s
三台服务器的带宽:12.5 + 12.5 + 12.5 ≈ 30m/s
所有网络资源都已经用满。
如果实测速度远远小于网络,并且实测速度不能满足工作需求,可以考虑采用固态硬盘或者增加磁盘个数。
(2)如果客户端不在集群节点,那就三个副本都参与计算
2、测试 HDFS 读性能
-
测试内容
读取HDFS集群10个128M的文件
[moe@hadoop102 mapreduce]$ hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -read -nrFiles 10 -fileSize 128MB
-
删除测试生成数据
[moe@hadoop102 mapreduce]$ hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -clean
-
测试结果分析
为什么读取文件速度大于网络带宽?由于目前只有三台服务器,且有三个副本,数据读取就近原则,相当于都是读取的本地磁盘数据,没有走网络。