本文實例講述了MySQL性能瓶頸排查定位的方法。，具體如下：
導讀
從一個現(xiàn)場說起，全程解析如何定位性能瓶頸。
排查過程
收到線上某業(yè)務(wù)后端的MySQL實例負載比較高的告警信息，于是登入服務(wù)器檢查確認。
1. 首先我們進行OS層面的檢查確認
登入服務(wù)器后，我們的目的是首先要確認當前到底是哪些進程引起的負載高，以及這些進程卡在什么地方，瓶頸是什么。
通常來說，服務(wù)器上最容易成為瓶頸的是磁盤I/O子系統(tǒng)，因為它的讀寫速度通常是最慢的。即便是現(xiàn)在的PCIe SSD，其隨機I/O讀寫速度也是不如內(nèi)存來得快。當然了，引起磁盤I/O慢得原因也有多種，需要確認哪種引起的。
第一步，我們一般先看整體負載如何，負載高的話，肯定所有的進程跑起來都慢。
可以執(zhí)行指令 w 或者 sar -q 1 來查看負載數(shù)據(jù)，例如：
| [yejr@imysql.com:~ ]# w 11:52:58 up 702 days, 56 min, 1 user, load average: 7.20, 6.70, 6.47USER TTY FROM LOGIN@ IDLE JCPU PCPU WHATroot pts/0 1.xx.xx.xx 11:51 0.00s 0.03s 0.00s w |
或者 sar -q 的觀察結(jié)果：
| [yejr@imysql.com:~ ]# sar -q 1Linux 2.6.32-431.el6.x86_64 (yejr.imysql.com) 01/13/2016 _x86_64_ (24 CPU)02:51:18 PM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked02:51:19 PM 4 2305 6.41 6.98 7.12 302:51:20 PM 2 2301 6.41 6.98 7.12 402:51:21 PM 0 2300 6.41 6.98 7.12 502:51:22 PM 6 2301 6.41 6.98 7.12 802:51:23 PM 2 2290 6.41 6.98 7.12 8 |
load average大意表示當前CPU中有多少任務(wù)在排隊等待，等待越多說明負載越高，跑數(shù)據(jù)庫的服務(wù)器上，一般load值超過5的話，已經(jīng)算是比較高的了。
引起load高的原因也可能有多種：
某些進程/服務(wù)消耗更多CPU資源(服務(wù)響應(yīng)更多請求或存在某些應(yīng)用瓶頸)；
發(fā)生比較嚴重的swap(可用物理內(nèi)存不足)；
發(fā)生比較嚴重的中斷(因為SSD或網(wǎng)絡(luò)的原因發(fā)生中斷)；
磁盤I/O比較慢(會導致CPU一直等待磁盤I/O請求)；
這時我們可以執(zhí)行下面的命令來判斷到底瓶頸在哪個子系統(tǒng)：
| [yejr@imysql.com:~ ]# toptop - 11:53:04 up 702 days, 56 min, 1 user, load average: 7.18, 6.70, 6.47Tasks: 576 total, 1 running, 575 sleeping, 0 stopped, 0 zombieCpu(s): 7.7%us, 3.4%sy, 0.0%ni, 77.6%id, 11.0%wa, 0.0%hi, 0.3%si, 0.0%stMem: 49374024k total, 32018844k used, 17355180k free, 115416k buffersSwap: 16777208k total, 117612k used, 16659596k free, 5689020k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND14165 mysql 20 0 8822m 3.1g 4672 S 162.3 6.6 89839:59 mysqld40610 mysql 20 0 25.6g 14g 8336 S 121.7 31.5 282809:08 mysqld49023 mysql 20 0 16.9g 5.1g 4772 S 4.6 10.8 34940:09 mysqld |
