# MySQL Threads_running突發性的飆高，導致worker timeout

[TOC]

前幾天告警群突然噴了一堆`worker timeout error(>30s)`的訊息，導致服務有短時間的卡頓，擅長通靈的工程師們，又準備解每日任務囉

### 尋找問題:
因為目前服務採用微服務的架構，很多台同時都噴類似的error，所以原因應該是一個大家都需要使用到的東西，像是DB異常、Trigger沒正常觸發、Gateway斷掉...等問題

- 所以先查看一下MySQL的狀態，我們是使用Python的Statsd套件 + Graphite，來監控MySQL的一些性能指標
- 其中發現`Threads_running`的指標，在告警的時間點，突然飆到70左右，原本幾乎都是10以下的，就懷疑是他在搞鬼了

### 開始詢問Google大神
找到了這篇：https://blog.csdn.net/zsx0728/article/details/114536258
- 簡單介紹一下Threads_running是什麼東西。`Threads_running`：代表MySQL的工作強度。就跟汽車上面的轉速表一樣，代表著當下汽車出了多少力，就可以想成是`MySQL當下出了多少力來處理請求`
- 從下圖中我們可以看到50-100屬於overload的階段，如果持續時間<5s是可以接受的範圍，但從Graphite中我們可以看到大概持續了2分鐘左右

### 目前想法:
- 先使用`mysqlbinlog`來抓取特定時間範圍內執行哪些的SQL，來確認是不是有什麼特殊的SQL在大量消耗DB資源。`ps：有抓出來看過並沒有發現特別耗時的SQL，都是一些常態性的Update語法`

    mysqlbinlog --no-defaults --start-datetime="2023-01-05 14:55:00" --stop-datetime="2023-01-05 14:57:00" mysql-bin.000769 -r check20230105.sql

### 解決方案
1. 因為目前MySQL採用Master-Slave Replication架構，但只Slave只當做備份的作用，並沒有實際讀寫分離，可以改成真正的讀寫分離
2. DB sharding。這感覺很有難度，要把原本的資料給分一堆一堆的，來減少DB負荷
3. 提高硬體效能，但很難跟上面提

## Q：想問還有什麼解決方案嗎?

### 參考資料
1. https://blog.csdn.net/zsx0728/article/details/114536258
2. https://kkc.github.io/2015/09/05/monitoring-with-graphite/
3. https://www.cnblogs.com/xuliuzai/p/10763354.html