记录一次服务器降配引起的服务器宕机导致的hdfs磁盘激增问题

一，背景

        公司服务器资源公司要求要刚好满足大数据集群的使用，坚决杜绝浪费。项目上线后，服务器管理员通过华为云监控发现，cpu和内存只在晚上的时候有一段时间cpu在95%左右，内存飙到85%左右，认为服务器资源有浪费。奈何疫情期间要理解降本增效的举措，资源这样，真心是不浪费，马上就要缺资源了，不过还是没办法，机器降低配置。

原来的配置是4台，3台是8core 16线程64g,1台4core 8线程 32g，降低配置 后，是3台是4core 8线程32g,1台4core 8线程 16g，基本上砍掉一半的资源。后面重启所有任务后，做了不少资源，任务调优，总算是没报错。

二：现象：

1，第二天xhshell连接4core 8线程 16g这一台,直接连接不上，控制台显示在运行中，外网ip 在 windows本地可以telnet 连接上。

2，jps 查看 nodemanager进程在，但是页面上显示其他的nodemanager挂掉。排查原因，nodemanager的目录没有空间，导致挂掉。

3，平台监控上，前一天还是不到80%，但是突然 到了99.9%，不符合公司的业务增长规模。

4，通过hdfs dfsadmin -report  ，发现有很多在underreplication  block  ，大约几万个

三，解决：

1，通过华为云工单，他们也找不找出原因。只有强制重启服务器。重启后，重启所有的进程，包括dn，snn,nm，再次去看页面，又是3个nodes,而且查看hdfs的复制问题，已经只有几个正在复制。所有的一切又好了。

综上：问题的原因，服务器过于繁忙宕机，引起hdfs的部分块被认为是“丢掉了”，所以hdfs为了数据安全，就启动了一个复制数据块的线程，保证满足我们设定的两个副本，所以会导致其他机器的磁盘短时间内激增问题，进而引起一些列问题。

吃一堑长一智：

1，在 做监控的时候，明明节点不能工作，但进程仍然在。比如该文章的nm,我们监控的时候，仅仅监控进程，有时候不准，这里我们可以利用yarn的api,获取节点信息，进行监控，两种监控一起用。

2，在做flueme数据采集的时候也是，有时候flume报错了，但是进程在，无法及时报警。所以我们需要写一个脚本，监控flume的结果产出，比如是否生成了对应的目录。两种也可以一起使用，监控的更好。

当然，以上的建议只是在非常重要的进程上，不重要的就不用了，否则浪费精力太多