A程序是提供介面給手機客戶端呼叫，B程序是剛上的服務，A程序呼叫B程序的超時時間設定為3秒，超過3秒就報錯，上報到監控系統。上線後收到簡訊告警，超時的請求量較多。檢視監控圖如下

縱座標的頂部是3秒，每隔一小時就有一個高峰達到3秒。剛開始懷疑B程序有定時任務在跑，檢視程式碼後發現沒有，最後查到運維人員在系統中跑定時任務，每小時檢查log目錄下的檔案是否大於500M，是的話就切割檔案壓縮。檔案的時間與監控圖的超時時間一致。

懷疑是在作業系統定時任務切割日誌檔案的時候，與業務程序搶壓日誌檔案資源，阻塞了業務程序IO。

由於B程序是個重要服務，開發人員為了方便定位問題，把每次的請求和返回資料都打開出來，請求量也較大，導致每小時內都達到500M。

做了以下優化：

1. 減少日誌量，只記錄關鍵資訊到日誌檔案

2. 修改log4j配置

log4j.additivity.monitorLogger=false
設定監控logger的日誌不會輸出到rootlogger
log4j.appender.monitorAppender.BufferedIO=true
log4j.appender.monitorAppender.BufferSize=8192設定log4j輸出日誌的時候採用緩衝的方式，而不是即時flush方式，並且設定了緩衝為8K，可以根據日誌輸出的情況來修改，不即時寫入檔案可以減少與定時任務衝突的概率。

log4j有個AsyncAppender選項可以設定為非同步輸出日誌，

優化完後，系統穩定，很少再收到告警簡訊，終於睡個好覺。