追追追之dockerd.exe持續高佔用CPU執行時間

我們某台Docker Host不斷發出CPU Alert，也就是CPU長時間不斷在高百分比情況。關於執行中的容器，我們可以使用docker stats觀察容器的CPU、RAM、I/O等整體狀態。雖然有幾秒會突然有某個容器衝高CPU的情況，但在某個AP容器被呼叫的情況，且只有短短幾秒，看起來合情合理。但如上圖，為何dockerd.exe的CPU一直持續在某個高點？而且不斷往上成長，雖然成長速度不快。所有容器服務在此台Docker Host都很正常執行，但就是想不到何為dockerd.exe為何持續佔用CPU。陷入苦思許久，苦思針對dockerd.exe我要如何偵錯；要針對某個處理程序（process）要偵錯，說起來不容易。

最簡單的方法就是更新Docker到最新版，找個好時間把dockerd.exe更新至目前最新版Server Version: 20.10.4，結果，不到幾十秒的時間，CPU又衝上去(容器一一啟動了)。我管理的數十台Docker Host，只有這台有這個狀況，萬中選一？正在苦思不到可能的因素時，回想到一個神器：Procmon.exe。設定好我們要取得的處理程序名稱：

犯人？

我可以看到超大量的ReadFile被觸發，畫面極快速被往下拉，從截圖可以看得出來，幾乎是固定某一個.log檔案造成。進一步依畫面的路徑查詢，什麼，這已經是一個超過1.2GB的.log檔案了。(因為是這個正式區域，不是處於隨時能更新的狀態，最後處理時已經成長到超過3GB的.log檔案了，忘了抓個圖了。)

一個超大型的.log加上Procmon.exe的佐證，大致可以合理推論出犯人是誰了。查詢文件，有個log-opts可以設定Docker本身在產出容器日誌的組態，調整daemon.json，加入以下組態：

{
    "log-opts":{
        "max-size":"10m",
        "max-file":"10"
    }
}

以上組態表示，每個日誌檔案最大10MB，最多10個，也就是最多保留100MB的資訊量。不過，發現一件事，在重啟docker(Restart-Service docker)之後並沒有生效。測試之後了解，舊容器不會直接吃新的組態，就算重開機也一樣，但如果是新部屬的容器就能看到效果：

最後找了一天週末，將所有容器重新部屬之後，看到dockerd.exe的CPU使用率立馬回到正常值。這也讓我學習到：

• 如果是會大量呼叫且穩定的容器(也就是不會頻繁更新)，要注意日誌(.log)相關設定。
• 容器內的應用程式要小心做STDOUT。STDOUT的量在應用程式大量被呼叫時，可能會造成問題。尤其是在未進行相關Log組態的狀況下。
• 如果要找特定執行緒的運作情況，Procmon絕對是首選。