前言
最近客户反馈，HDFS系统版本反馈出现偶然性的慢写入，慢写入时间达到10s以上。经过详细的排查，基本确定为DataNode机器的网络问题，现记录下问题的排查过程。
现象
1、2023-12-19客户开始保障。
2、客户请求耗时统计。
3、上传的小文件大小是一样的。
4、6个DataNode节点。
初步处理
三线处理人员发现当前集群机器某些DN节点磁盘空间已经满了，三线建议hdfs datanode节点存储空间不要超过75%，先让一线处理做下垃圾回收清理了磁盘空间。
处理空间后发现还是有慢写入。
之前了解到上传的小文件均是大小差不多的文件，且换了ftp节点，ftp内存调整到10G后还是存在问题，因此大概判断为hdfs集群应该是存在某些问题。
继续处理
经历过清理磁盘空间→换ftp节点→调整ftp内存依旧无效后，开始从hdfs集群排查。通过大概对hdfs和小文件ctdfs的了解给了客户以下的排查思路。
1，在datanode节点上，hdfs问题，使用命令 hdfs dfsadmin -report 检查。
2，在datanode节点上，节点网络问题 ping 192.168.62.2 -s 3000
3，在datanode节点上，查看datanode节点是否有问题，使用" egrep -o "Slow .?(took|cost)" /var/log/hadoop/hdfs/*.log | sort | uniq -c "查看慢请求
4，在FTP节点上，查看并发链接是否过高，netstat -an |grep ESTABLISHED |wc -l
5，在datanode节点上，磁盘是否有问题，sudo fdisk -l;sudo badblocks -v /dev/sde
6，在FTP节点上，估计下所有客户端的并发数，因为默认的句柄池是1000，如果超过这个可能也会导致慢写，可以调大下filerel.size这个值试试
经过客户排查，长连接不多，并发不高。设计到HDFS的客户长连接应该在有230、240的样子。
且对hdfs集群和datanode节点上的磁盘做过多轮检查，并未发现异常。
综上所述，大概排除掉1，4，5，6的问题。现在着重从datanode的慢日志入手。
深入排查
排查项
1、在每个datanode的节点上执行 egrep -o "Slow.*?(took|cost)" /var/log/hadoop/hdfs/*.log | sort | uniq -c 。
2、查看ambari上的hdfs监控。
通过以上发现，出现大量 “Slow BlockReceiver write packet tomirror took” WARN日志。通过Google可知，当前问题主要是因为网络导致。
在继续让一线统计下6个DN节点的情况。
可以发现有大量的Slow BlockReceiver write packet tomirror took日志，且大量出现超过10s的情况。经过和HDFS高手和Google了解到，
主要要关注在日志Pipeline的downtream日志。在继续让客户提供18这个节点上的详细日志， egrep -C 10 "Slow BlockReceiver write packet to mirror took" /var/log/hadoop/hdfs/*.log。
综上所属，基本上可以确定是当前hdfs的集群的网络存在问题。推荐客户执行以下流程排查问题。
1、ifconfig -a(定期检查问题主机上增加的errors和dropped的数量，往往代表的是网卡，网线或者上游的网络有问题)
2、netstat -s（与正常节点相比，查找大量重新传输的数据包或其他异常高的指标）。
3、netstat -s | grep -i retrans（整个集群执行）。 （在一个或多个节点上查找大于正常的计数）
最后发现存在大量的RX errors。
通过和运维专家确定当前集群节点的网络肯定存在相应问题。
给与客户最后事故处理结论：RX error值这么大可能是1：网线问题；2：机器网卡问题，3：上层交换机拥堵。
