排查Mysql突然變慢的一次過程

2022-08-02 04:15:10 字數 1957 閱讀 8023

**自 嚴陣以待

目錄上週客戶說系統突然變得很慢,而且時不時的蹦出乙個404500,弄得真的是很沒面子,而恰巧出問題的時候正在深圳出差,所以一直沒有時間

看問題,一直到今天,才算是把問題原因找到。

剛開始得到是系統慢的反饋,沒有將問題點定位到資料庫上,查了半天服務是否正常(因為之前有一次dubbo記憶體洩漏)。

在將應用服務日誌檢視了一遍後,沒有發現任何異常,只是打了幾個警告的日誌。

於是又檢視了業務執行時的日誌,看到日誌都提示了乙個lock wait timeout exceeded; try restarting transaction的異常。

這時還是沒有將重心放到資料庫上,認為是**的原因,導致事務一直沒有提交。

重新將**審閱了一遍,覺得應該不是**邏輯的問題,而這個時候,lock wait timeout exceeded; try restarting transaction這個異常的日誌越來越多。

認為是資料庫層面出了問題,開始排查資料庫。

由於我們的資料庫不是用的 雲rds版本,是在一台8核32g的aws上的安裝版本。

使用 top 命令,檢視到 mysql 占用的 cpu 使用率高達 90% 左右。

心裡一慌,感覺不妙,這樣子高負載的cpu使用率,搞不好伺服器都要宕掉。

於是拿出了僅有的一點mysql基本知識,基本上這次只使用到了下面幾個語句:

檢視當前mysql所有的程序

show processlist;

檢視mysql的最大快取

show global variables like "global max_allowed_packet"

檢視當前正在進行的事務

select * from information_schema.innodb_trx

檢視當前mysql的連線數

show status like 'thread%'

按照上面的幾個語句,一步一步跟蹤定位下來。

show processlist; 下來,我們就可以檢視出當前所有的程序,並且得到最耗時的程序。

在當前資料庫中,看到處於sleep狀態的sql非常多,而這也是占用cpu過高的重大原因,休眠執行緒太多,於是配置了乙個wait_time_out為 600 秒的乙個解決方案。

為什麼配置600秒,因為我們應用超時時間配置的最大時間就是 600秒,10分鐘,這裡的配置需要根據業務來具體配置。

select * from information_schema.innodb_trx

執行這個語句,看到mysql中大部分處於 lock 的sql是一條update的sql,而且還有乙個單條件的sql,查詢居然耗時4分鐘,很是驚訝。

於是檢視了這張表。

剛一開啟結構,差點沒忍住口吐芬芳,居然乙個索引都沒有,資料量超過300w,沒有索引查詢基本上都要4分鐘往上走。

於是準備加上索引,在一陣漫長的等待中,索引終於加上去了。

show status like 'thread%'

索引加上去了之後,檢視了一下當前mysql的連線數,似乎沒有之前那麼高了,估計是擠壓的太多。

然後又檢視了下伺服器的cpu佔用率,這次好了一點,從1%到80%來回跳動,沒有出現90&那麼高的頻率。

mysql作為使用頻率非常高的資料庫,對於它的sql調優真的是一門技術活,而且專案中的一些sql看的也是想吐,這種調優起來真的難上加難。

其實 information_schema 這個資料庫,裡面的mysql日誌看起來比業務日誌順眼的很多。

排查Mysql突然變慢

剛開始得到是系統慢的反饋,沒有將問題點定位到資料庫上,查了半天服務是否正常 因為之前有一次dubbo記憶體洩漏 在將應用服務日誌檢視了一遍後,沒有發現任何異常,只是打了幾個警告的日誌。於是又檢視了業務執行時的日誌,看到日誌都提示了乙個lock wait timeout exceeded try re...

程式呼叫mysql突然變慢 排查Mysql突然變慢

定位問題 剛開始得到是系統慢的反饋,沒有將問題點定位到資料庫上,查了半天服務是否正常 因為之前有一次dubbo記憶體洩漏 在將應用服務日誌檢視了一遍後,沒有發現任何異常,只是打了幾個警告的日誌。於是又檢視了業務執行時的日誌,看到日誌都提示了乙個 lock wait timeout exceeded ...

網絡卡變慢 記一次線上請求偶爾變慢的排查

最近解決了個比較棘手的問題,由於排查過程挺有意思,於是就以此為素材寫出了本篇文章。這是乙個偶發的效能問題。在每天幾百萬比交易請求中,平均耗時大約為300ms,但總有那麼100多筆會超過1s,讓我們業務耗時監控的99.99線變得很尷尬。如下圖所示 為了精益求精,更為了消除這個尷尬的指標,筆者開始探尋起...