原文地址：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
image.png
就是说，每3秒就执行一次对差不多11万个文件都去获取他的最后修改时间getLastModifiedTime
4.CPU占用是达到了60-100%
image.png
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多个文件
image.png
2.CPU占用资源对比5%和100%
image.png
4.问题总结
1.运维方面：需要运维同事增加相关目录处理压缩日志脚本，本次处理了10万个过期日志文件
2.数据平台：后续不断的在代码和业务层面上优化和处理问题