緊急處理

第一: 先限制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，然後分析報錯，找相關人解決。