Flink集群cpu-LOAD抖动问题排查
故障经过
月8日 22点左右 线上flink集群开始报警，经查看 部分节点load搞达100+，cpu 100%耗尽，
通过top命令查看cpu情况找到耗费cpu的进程，然后根据进程ID 找到此进程的相关信息，发现是直播业务方昨天新提交上来的flink任务的task进程。然后又查了一下此任务的GC情况，如下
很明显内存不够用了，频繁触发FULL-GC，最终引发cpu抖动，占内存且无法回收的直接能想到的就是窗口中的STATE，那么大小怎么看呢，flink里有个比较方便的办法，就是通过UI界面直接查看这个任务的checkpoint大小，我们看了一下这个任务的checkpoint的大小，大约是1G（图忘截了，就不放了）。情况比较明显就是这个有点大了，导致内存不够了
为了快速恢复故障，当时也没多想，直接采用了最粗暴的方式，将STATE从内存改用rocksdb，让业务方修改完代码之后重新发布上线
观察了一下，情况明显好转，但是负载还是稍微有点高，跟业务方交流了一下，这个任务每秒数据量只有几百条，讲道理这么小的数据，不应该有这么高的负载才对，而且网卡流量也有点高，
好吧虽然现在集群是稳定住了，但是这个任务为什么耗那么多资源呢？现在不急了，我们慢慢排查一下
我们又执行了cpu分析脚本(我们公司内部用的专门分析cpu占比线程以及代码堆栈的脚本)，结果如下
看了一下 吃cpu的基本都是这个代码堆栈，通过代码堆栈，很明显能看出来，这个是写checkpoint到hdfs，这玩意为什么写的这么猛？除了checkpoint比较大之外（1G左右），估计也是写的太频繁了，跟业务方协商后，把他们的代码拉下来看了一下
果然5秒一次，让业务方把间隔改成10分钟试试，改之后重新发布上去，系统负载瞬间小了很多，但是每10分钟，仍然会有一波峰值（写checkpoint）
好了，到这系统负载是基本下来了，但是问题还未彻底解决，现在可以静下心来去看看为什么checkpoint这么大了，了解flink的朋友应该知道STATE在每个窗口里都会存在，既然这个数据量应该不大，那么就可能是窗口太多了，带着这个问题，我们执行了一下 jmap -histo 看了一下，果然不出所料
看过源码朋友应该都知道这个TimeWindow就是窗口，1600万个窗口，WAHT？疯了吗？没办法找业务方交流了一下，一起review了代码，他们的窗口设置是30分钟的滑动窗口，滑动步长是10秒，这样的话窗口就比较多了，另外最关键的是，他们为了统计进入直播间的userId的进出次数，对userId进行了group by，而userId不用想也知道非常非常多，大致处理sql如下
SELECT utc2local(TUMBLE_END(rowtime, INTERVAL '20' SECOND)) as atime, roomId, sum(fnMin(c, 10)) as num FROM
(
SELECT
HOP_ROWTIME(rowtime, INTERVAL '10' SECOND, INTERVAL '10' MINUTE) as rowtime, roomId, userId,
count(*) as c
FROM
30
GROUP BY
HOP(rowtime, INTERVAL '10' SECOND, INTERVAL '10' MINUTE), roomId, userId
) GROUP BY
TUMBLE (rowtime, INTERVAL '20' SECOND), roomId
好了一切谜团都解开了，让业务方修改代码逻辑，不要再 gourp by userId了，通过别的方式进行进出直播间次数统计。一切又归于平静
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
