记一次低级错误导致的频繁Full Gc

最近在Flink平台上发布了一个简单的任务,在测试环境测试时没有发现什么问题,但是线上数据增加后发生了两次Full Gc频率过高,查看了相关的监控器,发现容器内存使用超过70%,我以为是应用发布时选择参数不合理,于是重新配置了taskmanager内存和并行度。

今天测试时,又发生了相同的问题,Full Gc频率更是高达每分钟7次。这次注意到Flink平台上的流图监控界面,之前对这个平台不熟悉没能好好利用这些监控工具。从流图监控上看到写入TSDB的task几乎完全停止,数据完全缓存,更奇怪的是CPU飙升,几乎完全占满。而内存监控中,老年代被占用了80%,所以造成频繁的Full GC。

怀疑是否是代码中哪里出现了内存泄漏,或者是出现了特定情况下的死循环。于是又查了一遍代码,最后发现竟是一个十分低级的错误。程序中需要调用ipdb的库对ip地址进行解析,这个文件有100多M,需要在包内读取后生成一个City对象,然后调用方法。这个读取并初始化对象的过程,我竟然写到了方法内部,导致每次需要解析IP时,都会去读取一下这个大文件,从而造成CPU高转,都阻塞在IO上了,而读取的大文件直接保存到老年代,造成老年代塞满了,于是Full Gc发生。

这真是太低级的错误了,编码过程中完全没有考虑,作为教训吧,要丢人还是趁早,以后要好好注意细节。

展开阅读全文

Windows版YOLOv4目标检测实战:训练自己的数据集

04-26
©️2020 CSDN 皮肤主题: 数字20 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值