背景

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

問(wèn)題描述

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

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

在問(wèn)題的時(shí)間點(diǎn)附近，連接數(shù)的總數(shù)量和 threads_running 的數(shù)量在短時(shí)間內(nèi)開(kā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)的，可以從這三者入手來(lái)分析這次問(wèn)題的起因。

原因分析

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

CPU

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

慢查詢

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

連接數(shù)

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

The number of threads that are not sleeping.

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

分析

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

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

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

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

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

拓展一下

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

threads_running 保持在一個(gè)相對(duì)平穩(wěn)的數(shù)值，參考前文的分析，可以發(fā)現(xiàn)這個(gè)現(xiàn)象代表著在平時(shí)的時(shí)候，就有約 10 個(gè)查詢長(zhǎng)時(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ù)庫(kù)。

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

總結(jié)一下

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

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

最新評(píng)論