【案例】常驻查询引发的thread pool 性能问题之二
生活随笔
收集整理的這篇文章主要介紹了
【案例】常驻查询引发的thread pool 性能问题之二
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
一 現象?
? ?某業務單機4個實例中的一個實例出現連接數遠高于其他三個實例（正常是4K，問題實例是8K+），但是這4個實例的配置完全相同。業務開發反饋為部分連接失敗。? ?
?執行show processlist結果顯示：
? ? ??存在大量的Killed狀態的連接126個，處于Connect狀態的6K+，以及6個binlog dump連接(如果看了前面一篇文章是否有點觸動，會不會是這個導致的？)
? 執行pt-pmp結果顯示：
? ? ??mysqld 十分的空閑
??執行show engine innodb status：
? ? 不存在空閑大事務
二 處理
? ? ?根據上一篇文章的知識，初步判斷該數據庫實例遇到為Thread Pool的部分group被阻塞了，（能把query堵在login階段的大部分為threadpool調度的問題，當然也不排除是因為邏輯原因造成login中出現內部鎖等待）
在調整thread_pool_oversubscribe后所有的Connect/Killed狀態的連接全部消失，連接數恢復正常。
三 問題分析
? ? ?雖然問題是解決了，但是還有大量的疑問存在，顯然在原因未知的情況下，如果在業務高峰期意外出現類似現象，后果非常嚴重，因此我們開始挖掘深層次的原因。
【曲折】
? ? ?既然調整thread_pool_oversubscribe后問題就解決了，很顯然是有group被阻塞了，因此最重要的就是找出是什么阻塞了Thread Pool。
? ? ?這次最能引起人注意的現象當然是這126個Killed狀態的連接了，我們知道當連接在運行中，被kill后處于回滾階段時，會顯示Killed。一般來說這個階段非常短暫（除非有大量的rollback工作，但是State信息是空的，顯然不是在rollback），pt-pmp的結果也證明了這一點。最開始一直懷疑是這些Killed的連接阻塞了threadpool的某些group，但是想來想去沒有想到合理的解釋，這里浪費了很多的時間。
【柳暗花明】
? 間隔32遞增，很明顯是其中一個group被阻塞了。對32取模后發現全部為19號group,那看來是binlog dump沒跑了。
對binlog dump線程的thread id對32取模后發現，6個thread中有4個在19號group中，而thread_pool_oversubscribe才3（內部限制為3+1），因此把19號group完全堵死。
到這里完全解釋了本次擁堵產生的原因。本次問題中的126個Killed session極大的誤導了我們的判斷。
【深入分析】
? ?回過頭來有人會問，那126個Killed session是怎么來的呢？
這里就需要講一下Thread Pool對kill處理的原理:
但是本case中，在這126個session被kill以后，剛好有一個binlog dump連接連到了即將擁堵的19號group。
看上圖緊跟在Killed連接后面的4261459連接,使得19號group徹底被堵住，可憐的Killed連接連退出的機會都沒有了,這就是這126個Killed連接的由來...
? ?某業務單機4個實例中的一個實例出現連接數遠高于其他三個實例（正常是4K，問題實例是8K+），但是這4個實例的配置完全相同。業務開發反饋為部分連接失敗。? ?
?執行show processlist結果顯示：
? ? ??存在大量的Killed狀態的連接126個，處于Connect狀態的6K+，以及6個binlog dump連接(如果看了前面一篇文章是否有點觸動，會不會是這個導致的？)
? 執行pt-pmp結果顯示：
? ? ??mysqld 十分的空閑
??執行show engine innodb status：
? ? 不存在空閑大事務
二 處理
? ? ?根據上一篇文章的知識，初步判斷該數據庫實例遇到為Thread Pool的部分group被阻塞了，（能把query堵在login階段的大部分為threadpool調度的問題，當然也不排除是因為邏輯原因造成login中出現內部鎖等待）
在調整thread_pool_oversubscribe后所有的Connect/Killed狀態的連接全部消失，連接數恢復正常。
三 問題分析
? ? ?雖然問題是解決了，但是還有大量的疑問存在，顯然在原因未知的情況下，如果在業務高峰期意外出現類似現象，后果非常嚴重，因此我們開始挖掘深層次的原因。
【曲折】
? ? ?既然調整thread_pool_oversubscribe后問題就解決了，很顯然是有group被阻塞了，因此最重要的就是找出是什么阻塞了Thread Pool。
? ? ?這次最能引起人注意的現象當然是這126個Killed狀態的連接了，我們知道當連接在運行中，被kill后處于回滾階段時，會顯示Killed。一般來說這個階段非常短暫（除非有大量的rollback工作，但是State信息是空的，顯然不是在rollback），pt-pmp的結果也證明了這一點。最開始一直懷疑是這些Killed的連接阻塞了threadpool的某些group，但是想來想去沒有想到合理的解釋，這里浪費了很多的時間。
【柳暗花明】
? ?在Killed session上走不通，那只能看看其他session了，這時發現被阻塞的Connect連接的thread id十分有規律:
? 間隔32遞增，很明顯是其中一個group被阻塞了。對32取模后發現全部為19號group,那看來是binlog dump沒跑了。
對binlog dump線程的thread id對32取模后發現，6個thread中有4個在19號group中，而thread_pool_oversubscribe才3（內部限制為3+1），因此把19號group完全堵死。
到這里完全解釋了本次擁堵產生的原因。本次問題中的126個Killed session極大的誤導了我們的判斷。
【深入分析】
? ?回過頭來有人會問，那126個Killed session是怎么來的呢？
這里就需要講一下Thread Pool對kill處理的原理:
但是本case中，在這126個session被kill以后，剛好有一個binlog dump連接連到了即將擁堵的19號group。
看上圖緊跟在Killed連接后面的4261459連接,使得19號group徹底被堵住，可憐的Killed連接連退出的機會都沒有了,這就是這126個Killed連接的由來...
總結
以上是生活随笔為你收集整理的【案例】常驻查询引发的thread pool 性能问题之二的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【MySQL】Got fatal err
- 下一篇： HDFS存储系统