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