30-套路篇:如何迅速分析出系統I/O的瓶頸在哪裡?
IO效能指標
檔案系統I/O效能指標
- 儲存空間的使用情況,包括容量、使用量以及剩餘空間等
通常也稱這些為磁碟空間的使用量,因為檔案系統的資料最終還是儲存在磁碟上
注意這只是檔案系統向外展示的空間使用,並非磁碟空間的真實用量,因為檔案系統的元資料會佔用磁碟空間
如果配置RAID,從檔案系統看到的使用量跟實際磁碟的佔用空間,也會因為RAID級別的不同而不一樣
例如配置RAID10後,從檔案系統最多也只能看到所有磁碟容量的一半 - 索引節點的使用情況,包括容量、 使用量以及剩餘量等
如果檔案系統中儲存過多的小檔案,就可能碰到索引節點容量已滿的問題 - 快取的使用情況,包括頁快取、目錄項快取、索引節點快取以及各個具體檔案系統(ext4、XFS等)的快取
這些快取會使用速度更快的記憶體用來臨時儲存檔案資料或者檔案系統的元資料,從而減少訪問慢速磁碟的次數 - 檔案I/O,包括IOPS(包括r/s和w/s)、響應時間(延遲)以及吞吐量(B/s)等
在考察這類指標時,通常還要考慮實際檔案的讀寫情況
比如結合檔案大小、檔案數量、I/O型別等,綜合分析檔案I/O的效能
這些效能指標非常重要,但Linux檔案系統並沒提供直接檢視這些指標的方法
只能通過系統呼叫、動態跟蹤或者基準測試等方法,間接進行觀察和評估
不過這些指標在考察磁碟效能時更容易見到,因為Linux為磁碟效能提供了更詳細的資料
磁碟I/O效能指標
- 使用率
是指磁碟忙處理I/O請求的百分比。過高的使用率(比如超過 60%)通常意味著磁碟I/O存在效能瓶頸 - IOPS(Input/Output Per Second)
是指每秒的I/O請求數 - 吞吐量
是指每秒的I/O請求大小 - 響應時間
是指從發出I/O請求到收到響應的間隔時間
考察這些指標時,一定要注意綜合I/O的具體場景來分析
比如讀寫型別(順序還是隨機)、讀寫比例、讀寫大小、儲存型別(有無RAID以及RAID級別、本地儲存還是網路 儲存)等
小結
這裡有個大忌,就是把不同場景的I/O效能指標,直接進行分析對比,這是很常見的一個誤區,一定要避免
檔案系統和磁碟I/O總結圖
效能工具
-
檔案系統原理
-
磁碟I/O原理
-
狂打日誌案例
-
磁碟I/O延遲的單詞熱度案例
-
MYSQL的案例
-
redis的案例
效能指標和工具的聯絡
-
第一個維度,從檔案系統和磁碟I/O的效能指標出發
換句話說,當想檢視某個效能指標時,要清楚知道,哪些工具可以做到
-
第二個維度,從工具出發
也就是當已經安裝了某個工具後,要知道這個工具能提供哪些指標
如何迅速分析I/O的效能瓶頸
有沒有什麼方法可以又快又準地找出系統的I/O瓶頸呢?
找關聯,多種效能指標間都有一定的關聯性,不要完全孤立的看待他們
想弄清楚效能指標的關聯性,就要通曉每種效能指標的工作原理
- 先用iostat發現磁碟I/O效能瓶頸
- 再借助pidstat ,定位出導致瓶頸的程序
- 隨後分析程序的I/O行為
- 最後結合應用程式的原理,分析這些I/O的來源
所以,為了縮小排查範圍,通常會先執行那幾個支援指標較多的工具,如iostat、 vmstat、pidstat等
然後再根據觀察到的現象,結合系統和應用程式的原理,尋找下一步的分析方向
推理圖
圖中列出了最常用的幾個檔案系統和磁碟I/O效能分析工具,以及相應的分析流程,箭頭則表示分析方向
這其中iostat、vmstat、pidstat是最核心的幾個效能工具,它們也提供了最重要的I/O效能指標
例如在前面講過的MySQL和Redis案例中,就是通過iostat確認磁碟出現I/O效能瓶頸
然後用pidstat找出I/O最大的程序,接著藉助strace找出該程序正在讀寫的檔案
最後結合應用程式的原理,找出大量I/O的原因
再如當用iostat發現磁碟有I/O效能瓶頸後,再用pidstat和vmstat檢查
可能會發現I/O來自核心執行緒,如Swap使用大量升高。
這種情況下,就得進行記憶體分析了,先找出佔用大量記憶體的程序,再設法減少記憶體的使用
轉載請註明出處喲~ https://www.cnblogs.com/lichengguo