调优&故障案例-集群某节点CPU LOAD规律性的在60上下 ...

游洪波

记录团队小伙伴的一次生产故障排查历程，要沉着冷静，要胆大心细。
1.怎么发现

环境: CDH5.16.1
1.1 MCP数据同步

先说说怎么发现该节点繁忙的，当MCP数据同步的JOB都停止了，我们通过观察redis的mcp_job_772_latestpos发现各个节点的MCP Agent点都停止写数据的，更新pos位置点。
唯独hadoopnode145节点的binlog file文件都是落后其他节点的2个文件的差距！
1.2 CDH Web

然后去CDH Web观察各个节点CPU LOAD是否正常，发现hadoopnode145节点表现为CPU LOAD 1min的指标在60上下波动，一般在10以下是正常的，超过10，就是服务器很繁忙！
(PS: 还未做好CDH节点的硬件全面指标预警，如磁盘空间、内存使用、CPU Load等)


1.3 HBase RS进程

CDH WEB界面显示HBase RS进程老是警告：

• 1.The health test result for REGION_SERVER_FLUSH_QUEUE has become unknown: Not enough data to test: Test of whether the RegionServer's flush queue is too full.
  
• 2.The health test result for REGION_SERVER_COMPACTION_QUEUE has become unknown: Not enough data to test: Test of whether the RegionServer's compaction queue is too full.
  

2.系统命令排查

2.1 top命令

通过top命令，发现HBase RegionServer进程的CPU使用率超大3568%。


2.2 查看RS进程

然后查看RS进程的CPU LOAD和本节点的CPU LOAD的使用对比趋势 ，来再次判断RS是不是罪魁祸首？




发现RS进程的Role CPU Usage基本是在50波动的，通过两幅图对比，那么判断Role CPU Usage是该节点的CPU LOAD的主要部分！
难道该RS进程有问题吗？
3.排查RS GC

看了一下 该节点的RS GC时间太长，一般毫秒ms基本的GC，而不是秒s的GC的，所以感觉是young gc频繁触发。


3.1部署jstatd

[root@hadoopnode145 ~]# vi /usr/java/jdk1.8.0_181/jstatd.all.policy
grant codebase "file:${java.home}/../lib/tools.jar" {
permission java.security.AllPermission;
};

[root@hadoopnode145 ~]# nohup jstatd -J-Djava.security.policy=/usr/java/jdk1.8.0_181/jstatd.all.policy &4.通过VisualVM工具再次定位 RS进程的GC情况

VisualVM工具排查定位没有截图，发现Eden Space的Young GC时间，从起动到当前时间累积的时间超久，我记得都超过1day多。
然后通过CDH的GC总时间/天，每天的累计为60min~110min波动，这其实也是很可怕的。


当时RS进程的内存为32G，G1垃圾选择器。
通过这幅图，我们发现GC总时间/天，是从5-15号开始持续递增，这时我在怀疑我们，是那天开始部署了什么spark job嘛？
5.这时我们再仔细看？

图1，CPU LOAD的时间波动为10min间隔，仔细排查我们的rundeck的spark job调度粒度: 确实有10min。
这时再看一下，原来是我们5月中旬的上的电商节假日618的指标的相关spark job，是要从 HBase抽数据，那么RS进程要交互的！
于是申请，先停止相关10min的job，继续观察节点的CPU LOAD，发现确实下降了在30左右，也是非常高，繁忙！
6.难道这618的Spark Job有毒吗？

• 排查代码，取数据也就当前月，百W的数据量也还好，SKIP；
  
• 排查代码，有没有使用非常规的函数，毕竟在apache issue看过非常规的函数确实有问题，也没有，SKIP;
  
• 排查参数，要不给executor加点个数、cores、内存，无效，SKIP；
  
• 通过Spark Web发现task的Locality Level级别基本都是RACK_LOCAL、NODE_LOCAL，调整参数--conf "spark.locality.wait=10s" ，
  

发现host load稍微改善点了，并没有根本解决；还是先启动相关的spark job。
7.于是乎的调整HBase参数

7.1 RS进程的内存从32G调整48G

(你们知道为什么官方不建议超过32G设置呢？但是我依然忽略)


7.2 调整RS进程的G1参数

-XX:+UseG1GC
-XX:+UnlockExperimentalVMOptions
-XX:G1NewSizePercent=30
-XX:G1MaxNewSizePercent=60
-XX:+ParallelRefProcEnabled
-XX:InitiatingHeapOccupancyPercent=65
-XX:-ResizePLAB
-XX:MaxGCPauseMillis=500
-XX:+UnlockDiagnosticVMOptions
-XX:+G1SummarizeConcMark
-XX:G1HeapRegionSize=32m
-XX:G1HeapWastePercent=20
-XX:ConcGCThreads=16
-XX:ParallelGCThreads=38
-XX:MaxTenuringThreshold=2
-XX:G1MixedGCCountTarget=64
-XX:G1OldCSetRegionThresholdPercent=5
-XX:MetaspaceSize=300M
-Dcom.sun.management.jmxremote.port=39999
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false7.3 Disabling the BoundedByteBufferPool



7.4 其他参数

hbase.hregion.max.filesize : 10G
hbase.hregion.memstore.flush.size : 1G
hbase.hregion.memstore.block.multiplier : 6
hbase.hregion.majorcompaction : 3day



hbase.regionserver.global.memstore.upperLimit(hbase.regionserver.global.memstore.size): 0.45
hbase.regionserver.global.memstore.lowerLimit(hbase.regionserver.global.memstore.size.lower.limit): 0.91
hbase.regionserver.handler.count : 128
hbase.regionserver.metahandler.count : 64

调整完成后，重启HBase，该节点CPU LOAD，始终依旧如此的高！8.排查memory、disk 、cpu的明细情况

8.1安装 htop 、iotop、iftop命令

(不会的，自行百度去)
8.2 htop命令显示

56core的都使用满满的情况，很繁忙，竖杠线全部沾满(忘记截图了，先奉上故障解决后的图)


8.3iotop 命令

查看磁盘io ，对比，无异常
8.4iftop -i bond0 命令

查看网卡bond0，对比其他节点，无异常
9.但是我们还是要冷静再分析一下

Phoenix table是salted表，读写均衡，无热点。每个节点的region数量差不多及读写请求也是差不多。


所以，到底是哪里发生的问题呢？
我心里不止一次问自己！难道硬件问题吗！
10.端午节最后1天晚上24凌晨

开始停止所有的数据同步MCP JOB和Spark Job

• 停止hadoopnode145节点的DN RS Broker NM进程
  
• 但是如何检测硬件的好坏呢，百度谷歌搜了一堆，也都正常显示命令的值，真的硬件没问题了吗？
  
• 这时我下定决心，使出最后一招！看看能不能解决，万能的重启！
  

......
等待30s，开始ping hadoopnode145，发现无法ping通！这时心里是喜悦的，也是复杂的！

• 凌晨半小时，开始电话给IT运维，反馈这个节点情况，IT回复：有可能是系统卡住了，硬件不可能坏的！我想也是有可能的！
  
• 我不死心，直接联系IDC机房托管人员，帮我去查看这台机器的起不来的真正的异常，焦急的等待10min，前方回复：
  

• 直接发授权邮件，让对方直接操作拔掉坏的内存条，再帮我启动系统；
  
• 又经过焦急的等待，这时我心里是清楚知道的，就是内存条导致 CPU LOAD负载高！差不多过了15min，前方回复：好了。
  
• 快速操作，启动所有暂停的进程和数据同步job 、sparkjob （包含那10min粒度调度的job），
  

观察半小时，发现CPU LOAD一直在10以下，很平稳！
这时已经凌晨3点半！

• 第二天，让IT运维开始走工单，邮寄内存条 返厂换新！
  

11.第二天的19点截图（已经过了40h）

hadoopnode145节点稳稳地在CPU LOAD在10以下，完美


12.经历过618电商节日，很平稳，在10以下



13.故障排查总结

为什么要写此故障文档？排查思路很重要！特此记录

• GC 工具查看及dump分析
  
• HBase bug搜索定位
  
• HBase参数调优
  
• Spark参数调优
  
• htop等命令及硬件检查
  
• 重启节点来检查
  
• 冷静，思考，一步步排查
  

七洲遛狼

专业抢沙发的！哈哈