mysql故障 異常資料 最近一次

發一個報警和故障資料對比圖

性能對比

sda.util

報警  139%

故障  100%-149%

bytes read per second on sda

報警  500K

故障  15-20M

sda:read:iops per second

報警  66

read requests issued per second to sda

報警  50

故障  400

mysql異常的特征和監控的關鍵資料

1.nginx 連接配接數

waiting：200  accept和waiting 一樣

2.io,cpu，swap 

cpu wait 20

cpu load 3.0

swap 已經占用了一半以上

3.io 

使用率超過了100% 

注意 iops per second  read per second  30

Bytes read per second on sda 20M/s

3.mysql 性能參數

讀寫次數

insert 20

read 300k 增加到800k  

Template MySQL InnoDB: InnoDB Rows Read per second

mysql.status[Innodb_rows_read]

update 0

state sending data 13.45 開始增長 5-20  (show processlist 也能看到)

State Sending Data

MySQL.State-sending-data

threads running  也變得很大

Thread_running突然飙高的誘因：

1 用戶端連接配接暴增；

2 系統性能瓶頸，如CPU,IO或者mem swap；

3 異常sql；

往往在這種情況下，MySQL server會表現出hang住的假象

反而threads cached 複用資源很高 最多到20-25

mysql連接配接數 120-200

handler_read_key per second 變大了

innodb log pending fsyncs 有2.0的波動

innodb transaction lock memory 增加到10k-25k

Template MySQL InnoDB: InnoDB Transaction Lock Memory

mysql.innodb[Innodb_trx_lock_memory]

innodb  transaction running 變大 25

query cache not cached per second  某刻從0到800

Template MySQL DB: Query Cache not cached per second

mysql.status[Qcache_not_cached]

4.tomcat 連接配接數

5.nginx 每個連接配接時間

6.平常swap經常告警，說明有慢查詢語句，應該是沒用索引。swap缺少這個就需要開始收集慢查詢語句了。

報警

Response time is too high on 172.1.1.1  

system.swap.size[,pfree]  50%，swap居高不下，就要關注了，容易崩潰了

172.1.1.1 Disk I/O is overloaded on 172.1.1.1

cpu.load[percpu,avg1]

cpu.util[,iowait]

mysql程序占用的cpu,記憶體等

zabbix建立一個觸發器

{172.1.1.1:mysql.status[Innodb_rows_read].avg(5)}>500000 and {172.1.1.1:MySQL.State-sending-data.last()}>=5

當io超過磁盤承受能力，而sql沒有索引，容易引起cpu很高。

建議建立觸發器

<a href="https://s2.51cto.com/wyfs02/M01/A6/5F/wKioL1nNrayTUQjdAAAhqPnJEpc620.png" target="_blank"></a>

<a href="https://s2.51cto.com/wyfs02/M02/07/AE/wKiom1nNre7BK0D0AAApOMDRe6c771.png" target="_blank"></a>

收集到的關系圖

416k  106

10k    50

本文轉自 liqius 51CTO部落格，原文連結：http://blog.51cto.com/szgb17/1967747，如需轉載請自行聯系原作者