HDFS 排障
集群存储超过阈值
两个参数接近阈值时，就需要清理集群上数据 :
- HDFS 总文件数：HDFS 存储内有多少文件，警告阈值为 5000W
- HDFS 占用比：警戒阈值为 75%，如 : 超过，就告知业务组清理数据
平均负载和磁盘存储
-
当集群节点的磁盘使用普遍达到了 70%以上时 , 说明存储已经较满 , 建议进行扩容
-
平均负载如果超过 CPU 核数 2 倍以上时 , 说明有点高，如 : 在 5 ~ 10 倍以上就很高
清理集群数据方法
- 当集群存储使用率接近 75%时 , 通知业务组清理数据，务必将存储降到 75% 以下
- 通知主要的项目经理 , 必要时通知高层人推进
- 无法完成降到 75% 时，通过降副本方式降存储。如 : 大表
- HDFS:
/opt/hive/hivescratchdir为 M / R 加工临时目录，7 天以上的数据可以清理 - HDFS:
/xxx，该目录下小文件超多 , 文件数阈值 300 万 , 文件入其他库后 , 进行定时清理计划，如 : 接近阈值通知相关人 , 进行手动清理
清理回收站文件
每天定时执行 /home/xxx/trash.sh 清理脚本，来清除所有用户的 .Trash 目录
查看文件大小情况
hadoop fs -du -s -h /user/hadoop/.Trash/
清除该用户文件 , 小心操作
hadoop fs -rm -r /user/hadoop/.Trash/*
.meta 文件损坏
.meta 文件损坏导致 DataNode 进程无法启动
查看日志
发现数条关于无法读取 .meta 文件的报错：
org.apache.hadoop.util.ShellsExitCodeException: du: cannot access `/data/xxx/blk_xxx.meta`: Input/output error
检查文件
进入到 /data/xxx/blk_xxx.meta 目录下，发现该条报错中提到的 meta 文件的属主、属组和权限等信息显示异常
该磁盘下的某几个 meta 文件损坏，导致 DataNode 进程无法启动
解决方法
root 权限取消 hdfsdskxxx 的挂载
sudo umount /data/hdfsdskxxx
fsck 修复磁盘
sudo fsck /data/hdfsdskxxx
启动 DataNode
./sbin/hadoop-daemon.sh start datanode
如果磁盘无法通过 fsck 修复，就找 IAAS 人处理该磁盘
多个 DataNode 节点存储不足
HDFS 页面显示所有 DataNode 存储的标准差已达 11%（正常情况下 : 5%）
在空闲（内存占用低）的节点启动 balancer
设置 balancer 所能占用的带宽
带宽的大小与负载均衡的速度成正比，但是速度过大可能会导致 map/reduce 运行缓慢，所以务必选择业务空闲时间段启动 balancer。默认的带宽为 1048576（1M/S）。由于 balancer 可以在中断后重新执行（类似于迅雷的断点续传），所以可以先设置一个较低的带宽，慢了的话，再一次次加速。
此处设置为 2M/S。注意 : balancer 每次设置的带宽是临时性的，第二次启动 balancer 时，要重新设置带宽
hdfs dfsadmin -setBalancerBandwidth 2000000
执行 balancer
在内存占用较低的节点上启动 balancer 脚本，将 HDFS 中所有节点的存储值中的最低值和平均值的差值设置为 5
启动 balancer 后，在屏幕输出了 balancer 的日志路径
start-balancer.sh -threshold 5
查看进程
jps -l
查看 Balancer 的进展
HDFS 页面中的存储变化来间接反映 balancer 的进展外，还可以通过日志来量化其进展
more /app/hadoop/hadoop-3.1.2/logs/hadoop-hdfs-balancer-node196.out
more /app/hadoop/hadoop-3.1.2/logs/hadoop-hdfs-balancer-node196.log
定时执行 balancer
每天的定时计划 :
- 停止昨天的 balancer
- 设置带宽（非必须 )
- 启动今天的 balancer ( 避开主机繁忙期 )
DataNode 坏盘故障
发现数据坏盘的方式有两种，通过监控系统自动报警和在 CM 页面里肉眼观察
肉眼观察：在 HDFS 页面的 DataNodes 目录 (http://132.35.xx.xx:50070/dfshealth.html#tab-datanode)里，观察 Failed Volumes 列的数值，若有非 0 值，则该值对应的 DataNode 有坏盘
停止 Hadoop 上的进程
通知硬件侧更换硬盘
DataNode 存储超过阈值
Hadoop 盘的存储率超过了 90%
查看磁盘
df -h
检查 HDFS 存储
由于 DataNode 单块磁盘的存储过高，导致整个集群的 HDFS 存储超过了 75%
反馈相关人员进行删除
坏块处理
查看 HDFS 页面出现如下图报错即为有坏块
查看集群坏块的状况
查看集群坏块的状况，以及坏块的路径
hadoop fsck /
删除坏块
hadoop fsck / -delete
查看集群坏块的状况
hdfs fsck /
修改表的副本数，副本数 : 2
hadoop fs -setrep -R 2 /user/hive/warehouse/xxx.db
查看副本数是否正确
hadoop fsck /user/hive/warehouse/xxx.db
DataNode 宕机
DataNode 宕机过长 , 并把该节点重启
root 身份登录到该节点
su - hdfs
停止 ntp 服务
service ntpd stop
与 Hadoop 上的 NTP Server 同步
ntpdate hadoop188
将时间写到主板
hwclock -w
启动 ntp 服务
service ntpd start
启动 DataNode
./sbin/hadoop-daemon.sh start datanode
检查 DataNode 进程是否已经启动
jps -l
HDFS 目录被删除排查
集群某个目录被删除排查，并提供了被删除目录，请求定位被谁删除
查看 HDFS 审计日志 , 来定位用户
INFO FSNamesystem.audit: allowed=true
ugi=hdfs (auth:SIMPLE)ip=/10.191.xxx.xxx cmd=rename options=2
src=/serv/smartsteps/raw/events/locationevent/2022/05/28/011
dst=/user/hdfs/.Trash/Current/serv/smartsteps/raw/events/locationev
ent/2022/05/28/011perm=hdfs:ss_deploy:rwxr-xr-xproto=rpc
MaxDirectoryItemsExceededException
HDFS 目录存储最大文件数异常 MaxDirectoryItemsExceededException 问题描述
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
The directory item limit of /XXX/XXX is exceeded: limit=1048576 items=1048576
at org.apache.hadoop.hdfs.server.namenode.FSDirectory.verifyMaxDirItems(FSDirectory.java:2060)
at org.apache.hadoop.hdfs.server.namenode.FSDirectory.addChild(FSDirectory.java:2112)
at org.apache.hadoop.hdfs.server.namenode.FSDirectory.addLastINode(FSDirectory.java:2081)
at org.apache.hadoop.hdfs.server.namenode.FSDirectory.addINode(FSDirectory.java:1900)
at org.apache.hadoop.hdfs.server.namenode.FSDirectory.addFile(FSDirectory.java:327)
at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startFileInternal(FSNamesystem.java:2794)
解决方法
更改 hdfs-site.xml
<property>
<name>dfs.namenode.fs-limits.max-directory-items</name>
<value>1048576</value>
<description>Defines the maximum number of items that a directory may contain. Cannot set the property to a value less than 1 or more than 6400000.</description>
</property>
将值设置为大一些，最多不能超过 6400000，因此还需要考虑删除历史数据
NameNode 宕机太久
NameNode 停机很久，然后启动，JournalNode 同步元数据时，DataNode上传 block 报告给 NameNode。但由于 NameNode 内存有限，会触发 full gc 导致 DataNode 连接超时，然后就一直处于安全模式
IOException in offeRegionServerervice java.net.SocketTimeoutException: Call From
xxx/xxx.xxx to xxx:8022
failed on socket timeout exception: java.net.SocketTimeoutException: 60000 millis timeout while waiting for channel to be ready for read. ch :
java.nio.channels.SocketChannel[connected local=/xxx.xxx:39469
remote=xxx/1xx.xxx:8022]; For more details
see: http://wiki.apache.org/hadoop/SocketTimeout
启动 Standby NameNode 后，每次加载 needs additional 6267650 左右 blocks 时 , 备节点 NameNode 就会卡住，无法继续加载
解决办法
调整 NameNode handle 线程数，通过减少线程数来减少 request wite 线程，减少内存使用或 加大内存
DataNode 失联排查
问题
有个 DataNode 一直失联
排查
查看日志发现
错误 :
java.io.IOException:Not ready to serve the block pool,
查看 GC
查看该 DataNode 的进程号
jps -l
查看 DataNode GC
jstat -gcutil xxx
查看负载
查看系统负载
top
查看网络
查看网络流量
dstat
查看 IO
查看磁盘 IO，发现 %util 过高
%util： 一秒中有百分之多少的时间用于 I/O，如果%util 接近 100%，说明 : 产生的 I/O 请求太多，I/O 系统已经满负荷
iotop
发现 du -sk 操作，是对磁盘进行 blockpool ，该命令会持续很长时间
查看磁盘
查看磁盘情况，发现 sataxxx 分别挂载在了 sdxxx，正好与 iostat 中 %util 过高的磁盘吻合
lsblk
解决
du -sk : 统计某个目录的大小的，du 的运行机制是基于文件获取，并非针对某个分区，执行时间受限于文件和目录个数，当每个 DataNode 的 block 很大时 , du 会很慢，所以导致 DataNode 一直启动不完成，导致失联
在 core-site.xml 里面增加配置：
fs.getspaceused.classname=org.apache.hadoop.fs.DFCachingGetSpaceUsed
使用 df 替换 du
总结
df 直接使用 statfs 系统调用，直接读取分区的超级块信息获取分区使用情况，对整个分区，直接读取超级块，运行速度不受文件目录个数影响，执行很快
du 和 df 不一致情况 :
- 当文件被删除后，在文件系统目录中已经不可见了，所以 du 就不会再统计它了。如果此时还有运行的进程持有该被删除的文件的句柄，那么该文件就不会真正在磁盘中被删除， 分区超级块中的信息也就不会更改
- df 会统计这个被删除的文件
问题
DataNode 又出现失联
排除
查看日志
错误 :
GC pool 'PS MarkSweep'had collection(s): count=1 time=13963ms
timed out
发现频繁发生耗时长的 GC
查看GC
jstat -gcutil xxx
查看 DataNode JVM 堆栈信息，发现老年代使用 100%，且频繁发生 FULL GC
查看系统负载，发现负载过高，CPU 负载过高，符合频繁 FULL GC 的特征
top
解决
增大 DataNode 内存
hadoop-env.sh :
export HADOOP_DATANODE_OPTS="-Xms20480m -Xmx20480m"
重启 DataNode 回复正常
