背景：
某一天,一個客戶打電話來需要技術幫助,并抱怨平常15秒就可以打開的網頁現在需要20分鐘才可以打開.
具體系統配置如下：
RedHat Enterprise Linux 3 update 7
Dell 1850 Dual Core Xenon Processors, 2 GB RAM, 75GB 15K Drives
Custom LAMP software stack(譯注:Llinux+apache+mysql+php 環境)
性能分析之步驟
7.1. 首先使用vmstat 檢視大緻的系統性能情況
分析：
- 不會是記憶體不足導緻,因為swapping 始終沒變化(si 和 so).盡管空閑記憶體不多(free),但swpd 也沒有變化.
- CPU 方面也沒有太大問題,盡管有一些運作隊列(procs r),但處理器還始終有50% 多的idle(CPU id).
- 有太多的上下文切換(cs)以及disk block從RAM中被讀入(bo).
- CPU 還有平均20% 的I/O 等待情況.
結論：
從以上總結出,這是一個I/O 瓶頸.
7.2. 然後使用iostat 檢查是誰在發出IO 請求
看上去隻有/dev/sda3 分區很活躍,其他分區都很空閑.
差不多有1200 讀IOPS,磁盤本身是支援200 IOPS左右(譯注:參考之前的IOPS 計算公式).
有超過2秒,實際上沒有一個讀磁盤(rkb/s).這和在vmstat 看到有大量I/O wait是有關系的.
大量的read IOPS(r/s)和在vmstat 中大量的上下文是比對的.這說明很多讀操作都是失敗的.
從以上總結出,部分應用程式帶來的讀請求,已經超出了I/O 子系統可處理的範圍.
7.3. 使用top 來查找系統最活躍的應用程式
占用資源最多的好像就是mysql 程序,其他都處于完全idle 狀态。
在top(wa) 看到的數值,和在vmstat 看到的wio 數值是有關聯的.
從以上總結出,似乎就隻有mysql 程序在請求資源,是以可以推論它就是導緻問題的關鍵.
7.4. 現在已經确定是mysql 在發出讀請求,使用strace 來檢查它在讀請求什麼.
大量的讀操作都在不斷尋道中,說明mysql 程序産生的是随機IO.
看上去似乎是,某一sql 查詢導緻讀操作.
從以上總結出,所有的讀IOPS 都是mysql 程序在執行某些讀查詢時産生的.
7.5. 使用mysqladmin 指令,來查找是哪個慢查詢導緻的.
# ./mysqladmin -pstrongmail processlist
+—-+——+———–+————+———+——+———-+—————————————-
| Id | User | Host | db | Command | Time | State | Info
+—-+——+———–+————+———+——+———-+—————————————-
| 1 | root | localhost | strongmail | Sleep | 10 | |
| 2 | root | localhost | strongmail | Sleep | 8 | |
| 3 | root | localhost | root | Query | 94 | Updating | update `failures` set
`update_datasource`=’Y’ where database_id=’32′ and update_datasource=’N’ and |
| 14 | root | localhost | | Query | 0 | | show processlist
MySQL 資料庫裡,似乎在不斷的運作table update查詢.
基于這個update 查詢,資料庫是對所有的table 進行索引.