背景

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

問題描述

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

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

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

原因分析

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

CPU

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

慢查詢

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

連接數(shù)

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

The number of threads that are not sleeping.

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

分析

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

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

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

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

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

拓展一下

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

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

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

總結(jié)一下

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

以上就是MySQL Threads_running飆升與慢查詢的問題解決的詳細(xì)內(nèi)容，更多關(guān)于MySQL Threads_running飆升與慢查詢的資料請(qǐng)關(guān)注好吧啦網(wǎng)其它相關(guān)文章！