背景

年前本應該是回顧一年工作和收尾的階段，奈何各種促銷，活動都等著春節(jié)，因此也遇到了不少的問題，回顧了一下最近遇到的問題，發(fā)現(xiàn)有好幾個問題比較類似，正好整理一下，作為年前收尾的案例吧。表現(xiàn)上都是數(shù)據(jù)庫假死，無響應，發(fā)生的場景有較高的業(yè)務壓力到來時，也有業(yè)務正常運行的時候，突然就出現(xiàn)問題了。

問題描述

由于騰訊云數(shù)據(jù)庫 MySQL 本身是有故障檢測和高可用機制的，這幾例問題發(fā)生的時候，從用戶反饋的問題出現(xiàn)的時間點到實際介入排查的時候已經(jīng)有好幾分鐘了，但是并沒有觸發(fā)高可用切換，說明這個問題可能并不是數(shù)據(jù)庫自身的故障，也不是一些外部原因?qū)е聰?shù)據(jù)庫不可用。

檢查一下數(shù)據(jù)庫當時候的狀態(tài)，發(fā)現(xiàn)一個很不正常的指標：

在問題的時間點附近，連接數(shù)的總數(shù)量和 threads_running 的數(shù)量在短時間內(nèi)開始飆升，并且接近半分鐘的時間內(nèi)，連監(jiān)控插件都采集不到數(shù)據(jù)了。在相同的時間段內(nèi)，CPU 的使用率（達到 100%）、慢查詢數(shù)量也跟著飆升。基本上可以確認 CPU 使用率，慢查詢，連接數(shù)的指標這三者應該是相關聯(lián)的，可以從這三者入手來分析這次問題的起因。

原因分析

99%的情況下，只要慢查詢數(shù)量在飆升，那么這個問題就和慢查詢脫不了關系，但是案例分析并不能這么草率的下結(jié)論。言歸正傳，既然目標縮小在三個指標上，那么分別考慮一下這三個指標的意義，看看這幾個指標的異常會帶來什么問題。

CPU

CPU 過高說明 MySQL 的計算能力被占滿了，能占用 MySQL 計算資源的只有用戶線程和 MySQL 自身的系統(tǒng)線程，這次問題明顯和 MySQL 系統(tǒng)線程沒什么關系，說明用戶線程在大量占用 CPU 的計算資源，而且使用率達到 100% 說明有這個資源爭搶的程度是非常嚴重的，可能會導致原本效率極高的查詢因為拿不到 CPU 資源而變得非常緩慢，從高效率的查詢變成低效的慢查詢，從而產(chǎn)生數(shù)據(jù)庫假死或者 hang 死的現(xiàn)象。

慢查詢

慢查詢是個老生常談的問題了，因為查詢效率過低，會過度占用 CPU，IO，內(nèi)存等資源，從而影響到其他正常的查詢，從監(jiān)控指標上來說，CPU 使用率，IO 使用情況，內(nèi)存使用率都可能會有不同程度的上升，嚴重的情況下也會引發(fā)這幾個指標的飆升，導致整個數(shù)據(jù)庫響應緩慢。

連接數(shù)

連接數(shù)通常是一個引發(fā)“實際故障”的指標，例如連接數(shù)達到 max_connections 的上限，從而導致整個數(shù)據(jù)庫無法新建連接，程序側(cè)直接是報錯的，而不是無響應。threads_running 這個指標，參考官方文檔的描述：

The number of threads that are not sleeping.

簡單直白的解釋，這個指標的飆升代表當時候有大量活躍的用戶連接在 MySQL 實例中。而且從這個案例的監(jiān)控圖表來看，是一個飆升的趨勢，說明是在短時間內(nèi)出現(xiàn)了大量的活躍連接。

分析

完成這三個指標的簡單分析，可以發(fā)現(xiàn)這個三個指標是互相影響：

1. 慢查詢堆積會導致 CPU 使用率過高；
2. CPU 過高會導致整體的查詢效率變低，進而導致一些高效的查詢變成慢查詢；
3. 慢查詢的執(zhí)行效率過低，會較長時間的保持活躍狀態(tài)，所以 Threads_running 這個指標一定會上漲。
4. 過高的并發(fā)突然到來時，大量的查詢處于活躍狀態(tài)會讓 Threads_running 這個指標飆升，同時這種尖刺型的高峰也很容易占滿 CPU。
   

看起來三個指標飆升的原因是自洽的，只靠這三個指標并不能真正的判斷出問題的原因。那么仔細考慮一下這幾個指標飆升的原因為什么會自洽？會發(fā)現(xiàn)有一個核心現(xiàn)象，或者說是共性：查詢要能夠堆積起來。如果：

1. 堆積起來的查詢本來效率就不高，那么這個問題的誘因基本就是慢查詢了。
2. 堆積起來的查詢效率很高，那么這個問題的誘因可能是瞬間并發(fā)過高，或者是其他的原因?qū)е?CPU 使用率暴漲，然后反過來影響了這些效率很高的查詢。
   

所以檢查一下堆積起來的查詢，就能比較直白的分辨出問題了，就上圖展示的這個案例而言，堆積起來的查詢大量使用了 group by 和 order by，查詢的效率比較低，所以根因還是慢查詢。

拓展一下

如開篇所提及，最近發(fā)生的問題有多起，且原因類似。除了這個飆升的案例，還有如下所示的現(xiàn)象。

threads_running 保持在一個相對平穩(wěn)的數(shù)值，參考前文的分析，可以發(fā)現(xiàn)這個現(xiàn)象代表著在平時的時候，就有約 10 個查詢長時間處于活躍狀態(tài)，可以預測一個故障場景：業(yè)務量繼續(xù)上升，活躍的查詢變多，當高效的查詢受影響，效率降低到一定程度的時候，前端程序/用戶會因為超時或者響應慢的原因，發(fā)起重試，然后因為查詢效率降低，這個重試被反復觸發(fā)，然后引發(fā)雪崩效應，慢慢拖垮數(shù)據(jù)庫。

萬幸的是多個類似現(xiàn)象的實例僅有一個出現(xiàn)了問題，就是預測的這個場景，其他的都及時優(yōu)化掉了。

總結(jié)一下

雖說仍舊是慢查詢的問題，但是從這個案例可以發(fā)現(xiàn)另外一個 MySQL 指標，threads_running 的用處：監(jiān)控活躍的連接，提前發(fā)現(xiàn)一些并發(fā)量過高和異常的查詢，防止數(shù)據(jù)庫堆積查詢，產(chǎn)生假死的現(xiàn)象。

以上就是MySQL Threads_running飆升與慢查詢的問題解決的詳細內(nèi)容，更多關于MySQL Threads_running飆升與慢查詢的資料請關注腳本之家其它相關文章！

最新評論