flink+kafka消息堆积的一些思路

• 问题描述
• 排查技术方向
  • 服务器CPU高
  • 内存占用高
• 具体技术排查

目录

• 问题描述
• 排查技术方向
  • 服务器CPU高
  • 内存占用高
• 具体技术排查

问题描述

flink+kafka，某些时候会有消息规程，量不大，但缓慢上升。

初步排查:

kafka集群正常，消息接入，节点，内存，CPU均正常。
宽带正常。
flink反压正常。

--本文问题由flink+kafka引出，但与kafka和flink技术本身无关。
--本文主要记录内存CPU高的解决思路做一次重温和记录。

排查技术方向

服务器CPU高

1. top
   得到cpu占用高的pid

注意：这里判断CPU利率用是否很高，不能只看PID是否超过100%，还应结合CPU核数
cat /proc/cpuinfo| grep "processor"| wc -l

PID cpu% < 100*cpu cores %不算是CPU利用率高

看第三行更直观

• %Cpu(s): 36.5 us, 0.9 sy, 0.0 ni, 62.4 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st

2. top -Hp pid
   得到该应用的所有子进程占用cpu情况

subpid1
subpid2

3. printf '%x\n' subpid1
   得到该进程的十六进制码

如遇大写转小写
如 A5DE 转 a5de

4. jstack pid | grep subpid1的十六进制码

定位到代码

5. jstack pid 报错

jstack Unable to open socket file: target process not responding or HotSpot

网上很多方案都是当前进程不是当前用户所发起。切换了用户依然不能执行。最后解决方案是：

切换到/tmp/hsperfdata_root
看是否有pid
如有，在此执行

总结

不一定能完全记住命令，但思路应该是很清晰的。
基本原理是
jstack pid 查看进程的堆栈信息
但是这是查看的全部，如果要查看该应用里占CPU高的具体进程的具体代码得到筛选，做法就是将CPU高的子进程翻译为十六进进制，再grep命令筛选

内存占用高

1. jmap -heap pid
   查看堆栈信息

2. 查看大对象
   jmap -histo:live pid
   输出内容的一些说明：

[C is a char[]
[S is a short[]
[I is a int[]
[B is a byte[]
[[I is a int[][]

上面的输出中[C对象占用Heap这么多，往往跟String有关，String其内部使用final char[]数组来保存数据的。

可以使用jmap把堆信息导出，并使用可视化工具mat分析。导出的命令如下：

3. jmap -dump:live,format=b,file=a.dmp pid

Dumping heap to /Users/canglong/dev/test/a.dmp ...
Heap dump file created

下载到本地，再使用内存分析工具mat分析。

具体技术排查

1. 使用top命令可以看到最大进程占用CPU达到1000+%
   

但总体cpu user 使用率为30+%。
服务器为32核，因此1000+的CPU使用刚好为30%左右。
正常。

2. 使用top -Hp pid看到大量线程CPU使用率为70+
   

提取一个线程将之转换为十六进制

printf "%X\n" 42455
A5D7 -> a5d7

使用jstack查看只包含该线程的堆栈信息

jstack pid | grep a5dc -C 10

可以看到占用CPU率高的代码出处。经检查，正常。

直接使用jastack查看公司包名关键字的信息

jstack pid | grep com.xxx

看到大量TIMED_WAITING(sleep)，经排查，是使用sleep定时唤醒kafka的一个心跳任务。疑似正常。

3. 查看大对象

jmap -histo:live pid| head -20

可以看到有一个自定义的对象达到30多个G。

再通过查看flink gc日志

发现大约每小时会有一次full gc.

疑似问题症结所在。