一次IO效能問題的發現過程
背景
計劃搭建兩套完全的系統進行壓測.
但是發現自己給自己挖了一個坑, 沒注意到一個區別.
郵件在三點鐘發出去了, 但是問題是我在四點鐘發現的.
問題現象
阿里雲上面高一個虛擬機器 的CPU出現異常的 CPU用量上升的問題.
Busy IOwait 比較高. 有 60%
感覺非常奇怪.
我這邊我一開始認為只跑了一個MySQL資料庫, 理論上不應該如此.
然後開始問題發現和解決的過程
故障圖
問題確認
輸入 top 進行確認.
發現的確idle 只有 30% 是存在IO的瓶頸.
立即使用 iostat 進行檢視
發現了很詭異的問題
iostat 的結果
問題不對勁
iostat 裡面看到很多的磁碟讀取, 但是看不到具體的程序
所以機器有卡頓, 並且一號跑的內容可能存在有差池的情況.
立馬就很詭異. 我理解iostat 應該能看到所有程序的相關資訊
顯然, 沒有
立即給阿里雲提工單.
提工單的工程中, 突然靈機一閃
docker ps 了下
果然發現有之前自己驗證 telemetry的容器再跑
立馬 systemctl stop docker
在進行 iostat 的檢視
大量的讀取沒有了.
問題反思
1. 虛擬機器是我直接clone的. clone之前執行了 systemctl stop docker的處理
但是沒有關閉開機自啟動.
2. 早上檢查機器沒有發現異常, 就可以了壓測. 並且系統表面上也沒有問題.
3. 因為測試結果與自己的預期非常相仿, 加深了自己的主觀認識.
當然了最大的收穫是 iostat 竟然無法看到 容器內的讀寫.
後續再進行相關工作時 必須要進行全方面的檢查
容器沒怎麼佔記憶體, 但是沒想到佔用了那麼多的IO
是一個很大的教訓.