大量删除hdfs历史文件导致全部DataNode心跳汇报超时为死亡状态问题解决

背景：
由于测试环境的磁盘满了，导致多个NodeManager出现不健康状态，查看了下，基本都是data空间满导致，不是删除日志文件等就能很快解决的，只能删除一些历史没有用的数据。于是从大文件列表中，找出2018年的spark作业的历史中间文件并彻底删除(跳过回收站)

/usr/local/hadoop-2.6.3/bin/hdfs dfs -rm -r -skipTrash /user/hadoop/.sparkStaging/application_1542856934835_1063/Job_20181128135837.jar

问题产生过程：
hdfs删除大量历史文件过程中，standby的namenode节点gc停顿时间过长退出了
当时没注意stanby已经退出了，还在继续删除数据，后面发现stanby停了后，于是重启stanby的NN，
启动时active的namenode已经删除了许多文件，导致两个namenode保存的数据块信息不一致了，出现大量数据块不一致的报错，使得所有的DataNode在与NameNode节点汇报心跳时，超时而被当做dead节点。
问题现象：
active的namenode的webUI里datanode状态正常，
但是standby的webUI里datanode全部dead，日志显示datanode频繁连接standby的NN且被远程standby的NN连接关闭，standby的NN显示一直在添加新的数据块
解决过程:
【重启stanby的NN】重启stanby的NN,重启后，stanby的NN存在GC停顿时间长的日志，之后出现大量写数据时管道断开(java.io.IOException: Broken pipe)的报错，stanby的节点列表还都是dead状态，且DataNode节点的日志大量报与stanby的NN的rpc端连接被重置错误(Connection reset by peer)，这个过程之前还不知道原理，原来DN也会往stanby的NN发送报告信息。
【active的NN诡异的挂掉】stanby的NN重启一段时间后发现active的NN也挂掉了，而且日志没有明显的报错，于是重启active的NN，过后发现active和stanby的NN的50070的webUI中DataNode列表都是dead了，且DataNode节点的日志依然大量报与NN的rpc端连接被重置错误(Connection reset by peer)
【尝试重启DataNode】尝试重启DataNode让其重新注册，发现重启后还是依然报与NN的rpc连接重置的错
【刷新节点操作】问了位大神后，尝试刷新节点，让全部节点重新注册，发现刷新节点失败，也是报的rpc连接被重置问题
【排查网络问题】由于服务并没有挂掉，且对应的rpc端口也有监听，猜测是网络、dns、防火墙、时间同步等问题，让运维一起排查都反馈没问题，不过运维帮忙反馈该rpc端口有时可以连接有时超时，连接中有大量的close_wait，一般情况下说明程序已经没有响应了，导致客户端主动断开请求。
【调整active的NN堆内存大小重启并刷新节点】于是猜想是不是现在active的NN的堆内存不足了，导致大量的rpc请求被阻塞，于是尝试调大active的NN的堆内存大小，停止可能影响NN性能的JobHistoryServer、Balancer和自身的agent监控服务，重启，重启后发现active的DN节点列表已恢复正常，但是stanby的DN节点列表还都是dead，尝试再次刷新节点，发现有刷新成功和刷新失败的rpc连接重置的日志，观察节点列表仍然还不能恢复正常
【发现JN挂掉了一个】于是查看stanby的DN的日志，发现报了JN连接异常的错误，发现确实active的NN中的JN挂了，重启JN，以为节点恢复了，发现还是不行，大神指点JN挂掉其实无所谓，确实，理论上数据块信息都是在NN，挂掉最多导致部分新数据没有，后面还会补上的
【重启stanby的NN】在大神的指点下，这时候重启stanby的NN能解决90%的问题，重启后果然active和stanby的DN列表都恢复正常了。
相关日志：
stanby的NameNode因gc停顿时间过长导致退出日志

2019-08-20 14:06:38,841 INFO org.apache.hadoop.hdfs.server.namenode.FileJournalManager: Finalizing edits file /usr/local/hadoop-2.6.3/data/dfs/name/current/edits_inprogress_0000000000203838246 -> /usr/local/hadoop-2.6.3/data/dfs/name/current/edits_0000000000203838246-0000000000203838808
2019-08-20 14:06:38,841 INFO org.apache.hadoop.hdfs.server.namenode.FSEditLog: Starting log segment at 203838809
2019-08-20 14:06:40,408 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 1069ms
GC pool 'PS MarkSweep' had collection(s): count=1 time=1555ms
2019-08-20 14:06:45,513 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 2139ms
GC pool 'PS MarkSweep' had collection(s): count=2 time=2638ms
2019-08-20 14:06:45,513 INFO org.apache.hadoop.hdfs.server.blockmanagement.CacheReplicationMonitor: Rescanning after 30749 milliseconds
2019-08-20 14:07:03,010 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 3326ms
GC pool 'PS MarkSweep' had collection(s): count=11 time=14667ms
2019-08-20 14:07:14,188 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 1009ms
GC pool 'PS MarkSweep' had collection(s): count=1 time=1509ms
2019-08-20 14:07:18,175 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 2179ms
GC pool 'P