一個鎖等待現象的診斷案例

在這裏插入圖片描述

作者:蘇坡

雲服務部-DBA團隊

數據庫工程師

前兩日與一個客戶交流,

客戶提出了一些

對mysql隔離級別以及鎖的疑問,

然後問到了出現鎖等待現象的排查思路。

這不禁讓我回想起

long long ago,

做過的一個診斷案例。

當年我還不是一枚老司機,

折騰了兩三天才完全搞定,

現在回想還頗有些借鑑價值,

故,分享之~

一、問題描述

數據庫實例:主庫XXXX:3306

問題詳情:客戶反映,涉及到user_site表相關的程序回調操作很慢,部分操作會超時報錯;

下單操作很慢甚至直接報錯失敗

程序端報錯信息如下:

General error: 1205 Lock wait timeout exceeded; try restarting transaction"

二、分 析

這是個典型的鎖等待超時退出的報錯,原因可能是某些事務未及時提交導致鎖資源不被釋放導致。

1、慢SQL分析

思路:通過rds控制檯查看最近一段時間的慢SQL,看是否出現user_site表相關的DML或者select鎖定讀操作。

查看慢SQL方式見下圖

在這裏插入圖片描述

很可惜,並沒有找到相關的慢SQL,那麼就代表SQL執行都很快,事務的處理上出現了問題,因此,我們更相信是某些程序沒有及時提交事務導致的了。

不過,還是有些收穫的,我們發現一些潛在的問題,就是top前幾的慢SQL。都是非鎖定select,因此和本次現象無關,但是這幾個查詢操作最長需要近百秒,十分消耗CPU以及內存資源,需要優化。

2、事務阻塞分析

思路:通過一個腳本,定期採集出現阻塞的事務信息,只要再次進行相關操作,阻塞事件的參與事務信息便被計入日誌,可對其進行詳細分析。

採集腳本如下:

在這裏插入圖片描述

大約半小時後,日誌中抓取到相關的信息

通過分析日誌,我們發現每隔一段時間會出現較爲嚴重的連環鎖等待現象,主要是以下兩種情況:

在這裏插入圖片描述

在這裏插入圖片描述

解釋下上面的日誌輸出:

waiting_trx_id: 被阻塞的事務ID

waiting_thread:被阻塞的mysql線程ID

waiting_query:被阻塞的SQL語句

blocking_trx_id: 阻塞者的事務ID

blocking_thread: 阻塞者的mysql線程ID

blocking_query: 阻塞者的SQL語句

我們發現,阻塞者總是處於非活躍狀態,而後的相繼操作會進入一個等待隊列。之所以會發生阻塞,就是這個空事務持有着被阻塞事務所需要的鎖資源,也就是說,以鎖定的方式,訪問到了相同的記錄。

參考前面的慢SQL分析結果,進一步推論,事務內部的SQL執行應該是較快的,那麼程序可能處理完SQL之後沒有進行提交操作。

定位程序

與客戶開發同學後溝通後,對該場景進行重現。實時輸出日誌,得到阻塞者的線程ID,通過information_schema.processlist視圖查詢出訪問mysql數據庫的程序。

客戶開發同學仔細排查代碼,很可惜也並沒有發現未提交事務的代碼。那麼問題就可能出現在程序自身,是程序處理慢,而並非SQL。提交事務之前,程序極有可能經過一個緩慢的處理過程,至於處理什麼,需要下一步做進一步的驗證。

接下來,對上面的推論做驗證~

3、SQL審計分析

思路:想要找到是哪塊代碼的問題,盲目的找無疑是大海撈針,所幸的是,RDS提供SQL審計功能,只要找到事務提交之前的SQL操作,這個問題的定位就應該清晰明瞭了。

通過前面排查的線程ID,搜索相關的SQL審計記錄。SQL審計可以通過下圖方式查看。

在這裏插入圖片描述

點擊數據庫安全→SQL審計。輸入篩選條件:database name,程序訪問數據庫的用戶名,關鍵字輸入線程ID,並選擇有效的時間範圍。

這次,終於有些收穫了,並且應該可以對本次現象做出合理的解釋了。以下是可疑的數據庫操作

在這裏插入圖片描述

在這裏插入圖片描述

我們發現,事務開啓後,立即進行了幾個SQL操作,而這幾個SQL都沒有被計入慢日誌,因此SQL執行很快(2S以內),從前面的日誌輸出我們也能看出,SQL執行是瞬間完成的,因爲我們根本抓取不到事務的SQL語句。

而事務的提交操作卻發生在十幾分鍾之後,那麼現在的疑問就是解決問題的關鍵了。長達十幾分鐘的事務,而SQL執行總共不到2S,那麼其餘的時間程序在幹什麼?

有了針對性的目的後,該客戶開發同學馬上定位到程序並找到了問題所在,在提交之前,程序會去進行插入隊列和刪除緩存的操作,而這些操作,佔用的都是事務的持有鎖且非活動時間。

屆此,該問題的分析過程全部結束,出現問題的原因就在於事務內部的非數據庫操作 。

3

處理方案

根因分析
事務內部進行的不只是數據庫操作,程序進行的插入隊列以及刪除緩存操作,讓一個2S之內完成的事務,延長至十幾分鍾;也就意味着,這十幾分鍾內,凡是請求事務內部鎖資源的SQL操作,必須進入鎖等待狀態。

處理建議
1.事務內部只進行SQL操作,程序的處理一律放在事務提交之後或開始之前。

2.如果存在邏輯問題不可修改,可爲相關處理過程設計處理隊列,拋出指令即可,而不用等待這個過程處理完畢再提交事務。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章