欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

MySQL Threads_running飆升與慢查詢的相關(guān)問題解決

 更新時(shí)間:2021年05月08日 11:53:58   作者:王文安@DBA  
這篇文章主要介紹了MySQL Threads_running飆升與慢查詢的問題解決,幫助大家更好的理解和學(xué)習(xí)使用MySQL數(shù)據(jù)庫(kù),感興趣的朋友可以了解下

背景

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

問題描述

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

檢查一下數(shù)據(jù)庫(kù)當(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è)資源爭(zhēng)搶的程度是非常嚴(yán)重的,可能會(huì)導(dǎo)致原本效率極高的查詢因?yàn)槟貌坏?CPU 資源而變得非常緩慢,從高效率的查詢變成低效的慢查詢,從而產(chǎn)生數(shù)據(jù)庫(kù)假死或者 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ù)庫(kù)響應(yīng)緩慢。

連接數(shù)

連接數(shù)通常是一個(gè)引發(fā)“實(shí)際故障”的指標(biāo),例如連接數(shù)達(dá)到 max_connections 的上限,從而導(dǎo)致整個(gè)數(shù)據(jù)庫(kù)無法新建連接,程序側(cè)直接是報(bào)錯(cuò)的,而不是無響應(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)控圖表來看,是一個(gè)飆升的趨勢(shì),說明是在短時(shí)間內(nèi)出現(xiàn)了大量的活躍連接。

分析

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

  1. 慢查詢堆積會(huì)導(dǎo)致 CPU 使用率過高;
  2. CPU 過高會(huì)導(dǎo)致整體的查詢效率變低,進(jìn)而導(dǎo)致一些高效的查詢變成慢查詢;
  3. 慢查詢的執(zhí)行效率過低,會(huì)較長(zhǎng)時(shí)間的保持活躍狀態(tài),所以 Threads_running 這個(gè)指標(biāo)一定會(huì)上漲。
  4. 過高的并發(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)象,或者說是共性:查詢要能夠堆積起來。如果:

  1. 堆積起來的查詢本來效率就不高,那么這個(gè)問題的誘因基本就是慢查詢了。
  2. 堆積起來的查詢效率很高,那么這個(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è)查詢長(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ù)。

萬幸的是多個(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ù)庫(kù)堆積查詢,產(chǎn)生假死的現(xiàn)象。

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

相關(guān)文章

  • MySQL JOIN之完全用法

    MySQL JOIN之完全用法

    最近在做mysql的性能憂化,做到多表連接查詢,比較頭疼,看了一些join的資料,終于搞定,這里分享出來!
    2009-12-12
  • mysql中的json處理方案

    mysql中的json處理方案

    這篇文章主要介紹了mysql中的json處理方案,本文通過實(shí)例代碼給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下
    2023-08-08
  • mysql的左右內(nèi)連接用法實(shí)例

    mysql的左右內(nèi)連接用法實(shí)例

    這篇文章主要介紹了mysql的左右內(nèi)連接用法,以一個(gè)完整實(shí)例較為詳細(xì)的分析了mysql的左右內(nèi)連接使用技巧,具有一定參考借鑒價(jià)值,需要的朋友可以參考下
    2015-02-02
  • centos 7系統(tǒng)下編譯安裝 mysql5.7教程

    centos 7系統(tǒng)下編譯安裝 mysql5.7教程

    因?yàn)镸ysql5.7的更新特性還是非常多,所以這篇文章就給大家介紹以下在centos上面編譯安裝mysql5.7的教程。本文給大家介紹的步驟還是相對(duì)來說比較詳細(xì)的,相信對(duì)大家具有一定的參考借鑒價(jià)值,有需要的朋友們可以參考借鑒,下面來一起看看吧。
    2016-11-11
  • 解決mysql數(shù)據(jù)庫(kù)設(shè)置遠(yuǎn)程連接權(quán)限執(zhí)行g(shù)rant all privileges on *.* to 'root'@'%' identified by '密碼' with grant optio報(bào)錯(cuò)

    解決mysql數(shù)據(jù)庫(kù)設(shè)置遠(yuǎn)程連接權(quán)限執(zhí)行g(shù)rant all privileges on&n

    這篇文章主要介紹了解決mysql數(shù)據(jù)庫(kù)設(shè)置遠(yuǎn)程連接權(quán)限執(zhí)行g(shù)rant all privileges on *.* to 'root'@'%' identified by '密碼' with grant optio報(bào)錯(cuò),通過本文給大家分享問題原因解析及解決方法,需要的朋友可以參考下
    2022-11-11
  • 為何不要在MySQL中使用UTF-8編碼方式詳解

    為何不要在MySQL中使用UTF-8編碼方式詳解

    這篇文章主要給大家介紹了關(guān)于為何不要在MySQL中使用UTF-8編碼方式的相關(guān)資料,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家學(xué)習(xí)或者使用MySQL具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面來一起學(xué)習(xí)學(xué)習(xí)吧
    2019-06-06
  • Mysql導(dǎo)出數(shù)據(jù)的正確方法

    Mysql導(dǎo)出數(shù)據(jù)的正確方法

    想在Mysql命令行下導(dǎo)出數(shù)據(jù)庫(kù),但就是每天提示不那個(gè)錯(cuò)誤,后來才知道其實(shí)mysqldump不是mysql命令,因此不能在Mysql命令行下導(dǎo)出。
    2011-05-05
  • Mysql閃退問題圖文解決辦法

    Mysql閃退問題圖文解決辦法

    之前在使用MySQL 5.5 Command Line Client時(shí),無論輸入什么密碼,都出現(xiàn)閃退的情況,糾結(jié)了半天才找到原因,下面小編給大家分享我的解決方法,感興趣的朋友一起看看吧
    2016-11-11
  • MySQL實(shí)戰(zhàn)之Insert語(yǔ)句的使用心得

    MySQL實(shí)戰(zhàn)之Insert語(yǔ)句的使用心得

    這篇文章主要給大家介紹了關(guān)于MySQL實(shí)戰(zhàn)之Insert語(yǔ)句的使用心得的相關(guān)資料,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2020-10-10
  • MySQL中將逗號(hào)分隔的字段轉(zhuǎn)換為多行數(shù)據(jù)的方法

    MySQL中將逗號(hào)分隔的字段轉(zhuǎn)換為多行數(shù)據(jù)的方法

    在我們的實(shí)際開發(fā)中,經(jīng)常需要存儲(chǔ)一些字段,它們使用像,?-?等連接符進(jìn)行連接,在查詢過程中,有時(shí)需要將這些字段使用連接符分割,然后查詢多條數(shù)據(jù),今天,我們將使用一個(gè)實(shí)際的生產(chǎn)場(chǎng)景來詳細(xì)解釋這個(gè)解決方案,需要的朋友可以參考下
    2024-04-04

最新評(píng)論