原文地址:https://www.jianshu.com/p/0b8c59a1b58b
问题描述
Flume多个配置合并后,发现占用cpu很高,利用top有30-50%的使用率,某几台机器60-100%,有时候还会挂起,挂起的时候,有个专门记录读取文件位置的json文件,都是0,似乎是因为某些原因卡住了。初步猜测是多线程问题引起的,但是没有挂起的时候正常采集的情况占用cpu也很高
1.问题定位
1.利用JAVA进程占用cpu很高的方法定位到代码,输出jstack信息发现是这段代码对cpu占用最高
java.lang.Thread.State: RUNNABLE at java.io.UnixFileSystem.getLastModifiedTime(Native Method) at java.io.File.lastModified(File.java:937) at org.apache.flume.source.taildir.ReliableTaildirEventReader.updateTailFiles(ReliableTaildirEventReader.java:342
2.查看源码逻辑发现,TailDirSource为了做到实时采集文件的变化,每隔3秒钟就要去遍历所有文件的最后修改时间,和内存中保存文件信息的最后修改时间作对比,如果有变化,则采集内存中保存offset后的数据,写json文件类似内存中信息的一个快照。
3.查看出异常的机器,110.10.41.43
发现该文件达到了15M,文件数差不多11万个[m_loguser_login@FK-isolation-java-provider-41-212 cache]$ grep -o inode DP_monitor_service.json | wc -l 108530
就是说,每3秒就执行一次对差不多11万个文件都去获取他的最后修改时间getLastModifiedTime
4.CPU占用是达到了60-100%
5.查看json发现,采集的文件从3月30号到今天,6月26号,每2分钟一个日志文件,所以问题出现在文件过多导致的
2.问题处理
1.找运维同事chrisli将所有的过期日志都压缩,只保留最近3天的日志,主要的日志目录
1./home/product/logs/repay_java_logs/frame/consumer_monitor 2./home/product/logs/fsof_monitor 3./home/product/logs/server-credit-dataadapter-java/frame/consumer_monitor
3.问题处理后效果
1.处理前监控的文件数和处理后监控的文件数
4000多个和10800多个文件
2.CPU占用资源对比
5%和100%
4.问题总结
1.运维方面:需要运维同事增加相关目录处理压缩日志脚本,本次处理了10万个过期日志文件
2.数据平台:后续不断的在代码和业务层面上优化和处理问题