MySQL 資料庫高負載故障分析
阿新 • • 發佈:2019-01-26
緊急處理
第一: 先限制Innodb的併發處理.如果innodb_thread_concurrency = 0 可以先改成 16或是64 看機器壓力,如果 非常大,先改成16讓機器的壓力下來,然後慢慢增達,適應自已的業務. 處理方法:
set global innodb_thread_concurrency=16;
第二: 對於連線數已經超過600或是更多的情況,可以考慮適當的限制一下連線數,讓前端報一下錯,也別讓DB掛了. DB在了,總是可以用來載入一下資料,當資料載入到了nosql裡了,慢慢的DB壓力也會降下來的. 限制單使用者連線數在500以下. 如:
set global max_user_connections=500;
(MySQL隨著連線數的增加效能會是下降的,這也是thread_pool出現的原因) 另外對於有的監控程式會讀取information_schema下面的表的程式可以考慮關閉下面的引數 innodb_stats_on_metadata=0
set global innodb_stats_on_metadata=0;
故障分析
注:一般mysql的配置檔案都是初始配置好的,緊急處理的方法有可能不適用,這事就要分析突然產生高負載的原因有哪些?
- 分析思路:
1、檢視mysql的slow.log,看是否出現死鎖,及其他報錯
2、show processlist; 檢視mysql都有哪些連線,判斷這些connect是否正常
3、通過使用htop、dstat等命令檢視負載高來源是CPU還是IO
htop、dstat 使用
epel源下載htop
# rpm -ivh http://mirrors.aliyun.com/epel/epel-release-latest-6.noarch.rpm
yum install htop dstat -y
htop是加強版的top,這裡對其使用不錯介紹
- dstat常用命令
dstat -l -m -r -c --top-io --top-mem --top-cpu
- tcpdump使用
抓包分析,預設mysql埠為3306
tcpdump -i eth0 -A -s 3000 port 3306 > /tmp/sql.log
- 引用perl
tcpdump -i eth0 -s 0 -l -w - dst port 3306 | strings | perl -e '
while(<>) { chomp; next if /^[^ ]+[ ]*$/;
if(/^(SELECT|UPDATE|DELETE|INSERT|SET|COMMIT|ROLLBACK|CREATE|DROP|ALTER)/i) {
if (defined $q) { print "$qn"; }
$q=$_;
} else {
$_ =~ s/^[ t]+//; $q.=" $_";
}
}'
# 這裡引用,找到最頻繁的SQL語句
- 使用strace 或 pstack檢視具體程序狀態
檢視系統呼叫是否有問題,程序是否堵塞,是否有Broken pipe
strace -p 22222
- pt-query-digest
分析mysql慢日誌,檢視哪些sql語句最耗時
pt-query-digest db-slow.log
總結: 有時候不需要全部操作就能找到問題的所在,這次故障中個人是通過show processlist找到不正常的連線,檢視是從哪裡連過來的,然後到特定的伺服器上,檢視指定的那個服務狀態是否正常。
故障分析:後端API服務拋異常,導致一個SELECT頻繁去執行,先重啟後端API,然後分析報錯,找相關人解決。