問題描述
Flume多個配置合并后罩句，發(fā)現(xiàn)占用cpu很高裳朋，利用top有30-50%的使用率，某幾臺機(jī)器60-100%窟感，有時候還會掛起讨彼，掛起的時候，有個專門記錄讀取文件位置的json文件柿祈，都是0哈误，似乎是因為某些原因卡住了。初步猜測是多線程問題引起的谍夭，但是沒有掛起的時候正常采集的情況占用cpu也很高
1.問題定位
1.利用JAVA進(jìn)程占用cpu很高的方法定位到代碼，輸出jstack信息發(fā)現(xiàn)是這段代碼對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.查看源碼邏輯發(fā)現(xiàn)憨募，TailDirSource為了做到實時采集文件的變化紧索，每隔3秒鐘就回去遍歷所有要采集的文件的最后修改時間，和內(nèi)存中保存文件信息的最后修改時間作對比菜谣，如果有變化珠漂，則采集內(nèi)存中保存offset后的數(shù)據(jù)，寫json文件類似內(nèi)存中信息的一個快照尾膊。
3.查看出異常的機(jī)器媳危，110.10.41.43發(fā)現(xiàn)該文件達(dá)到了15M,文件數(shù)差不多11萬個
[m_loguser_login@FK-isolation-java-provider-41-212 cache]$ grep -o inode DP_monitor_service.json | wc -l 108530
image.png
就是說，每3秒就執(zhí)行一次對差不多11萬個文件都去獲取他的最后修改時間getLastModifiedTime
4.CPU占用是達(dá)到了60-100%
image.png
5.查看json發(fā)現(xiàn)冈敛，采集的文件從3月30號到今天待笑，6月26號，每2分鐘一個日志文件抓谴，所以問題出現(xiàn)在文件過多導(dǎo)致的
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.處理前監(jiān)控的文件數(shù)和處理后監(jiān)控的文件數(shù)
4000多個和10800多個文件
image.png
2.CPU占用資源對比5%和100%
image.png
4.問題總結(jié)
1.運維方面：需要運維同事增加相關(guān)目錄處理壓縮日志腳本癌压，本次處理了10萬個過期日志文件
2.數(shù)據(jù)平臺：后續(xù)不斷的在代碼和業(yè)務(wù)層面上優(yōu)化和處理問題
