溫馨提示×

溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

【案例】常駐查詢引發(fā)的thread pool 性能問題之二

發(fā)布時間：2020-08-15 18:48:02 來源：ITPUB博客 閱讀：183 作者：風塵_NULL 欄目：MySQL數據庫
一 現(xiàn)象 
   某業(yè)務單機4個實例中的一個實例出現(xiàn)連接數遠高于其他三個實例（正常是4K，問題實例是8K+），但是這4個實例的配置完全相同。業(yè)務開發(fā)反饋為部分連接失敗。   
 執(zhí)行show processlist結果顯示：
      存在大量的Killed狀態(tài)的連接126個，處于Connect狀態(tài)的6K+，以及6個binlog dump連接(如果看了前面一篇文章是否有點觸動，會不會是這個導致的？)
  執(zhí)行pt-pmp結果顯示：
      mysqld 十分的空閑
  執(zhí)行show engine innodb status：
    不存在空閑大事務

二 處理
     根據上一篇文章的知識，初步判斷該數據庫實例遇到為Thread Pool的部分group被阻塞了，（能把query堵在login階段的大部分為threadpool調度的問題，當然也不排除是因為邏輯原因造成login中出現(xiàn)內部鎖等待）
在調整thread_pool_oversubscribe后所有的Connect/Killed狀態(tài)的連接全部消失，連接數恢復正常。

三 問題分析
     雖然問題是解決了，但是還有大量的疑問存在，顯然在原因未知的情況下，如果在業(yè)務高峰期意外出現(xiàn)類似現(xiàn)象，后果非常嚴重，因此我們開始挖掘深層次的原因。
【曲折】
     既然調整thread_pool_oversubscribe后問題就解決了，很顯然是有group被阻塞了，因此最重要的就是找出是什么阻塞了Thread Pool。
     這次最能引起人注意的現(xiàn)象當然是這126個Killed狀態(tài)的連接了，我們知道當連接在運行中，被kill后處于回滾階段時，會顯示Killed。一般來說這個階段非常短暫（除非有大量的rollback工作，但是State信息是空的，顯然不是在rollback），pt-pmp的結果也證明了這一點。最開始一直懷疑是這些Killed的連接阻塞了threadpool的某些group，但是想來想去沒有想到合理的解釋，這里浪費了很多的時間。
【柳暗花明】
   在Killed session上走不通，那只能看看其他session了，這時發(fā)現(xiàn)被阻塞的Connect連接的thread id十分有規(guī)律:
  1. | 4261587 | unauthenticated user | connecting host | NULL | Connect | NULL | login | NULL |
  2. | 4261619 | unauthenticated user | connecting host | NULL | Connect | NULL | login | NULL |
  3. | 4261651 | unauthenticated user | connecting host | NULL | Connect | NULL | login | NULL |
  4. | 4261683 | unauthenticated user | connecting host | NULL | Connect | NULL | login | NULL |
  5. | 4261715 | unauthenticated user | connecting host | NULL | Connect | NULL | login | NULL |
  6. | 4261747 | unauthenticated user | connecting host | NULL | Connect | NULL | login | NULL |
   間隔32遞增，很明顯是其中一個group被阻塞了。對32取模后發(fā)現(xiàn)全部為19號group,那看來是binlog dump沒跑了。
對binlog dump線程的thread id對32取模后發(fā)現(xiàn)，6個thread中有4個在19號group中，而thread_pool_oversubscribe才3（內部限制為3+1），因此把19號group完全堵死。
到這里完全解釋了本次擁堵產生的原因。本次問題中的126個Killed session極大的誤導了我們的判斷。

【深入分析】
   回過頭來有人會問，那126個Killed session是怎么來的呢？
這里就需要講一下Thread Pool對kill處理的原理:
  1. 當一個正在運行的連接被kill的時候，它所執(zhí)行的sql會失敗，其thd->killed會被置為THD::KILL_CONNECTION，同時通知Thread Pool（回調函數）。Thread Pool在回調函數中會發(fā)出一個io信號，worker需要捕獲這個event（和正常的event一樣處理）后，才會退出這個session，否則一直可以在show processlist看上類似本例子中126個session的狀態(tài)。
但是本case中，在這126個session被kill以后，剛好有一個binlog dump連接連到了即將擁堵的19號group。
  1. | 4261363 | xxxx | 10.9.6.57:10843| xxxx_0133 | Killed  | 246196 |                                                                 | NULL |
  2. | 4261395 | xxxx | 10.8.9.18:35401| xxxx_0133 | Killed  | 246186 |                                                                 | NULL |
  3. | 4261459 | xxxx | 10.8.2.61:60919| NULL| Binlog Dump | 246110| Master has sent all binlog to slave; waiting for binlog to be updated | NULL |
  4. | 4261491 | unauthenticated user  | connecting host | NULL    | Connect    | NULL   | login                                           | NULL |
  5. | 4261502 | xxxx  | 10.8.2.41:11862 | xxxx_0133 | Sleep       | 1      |                                                              | NULL |
  6. | 4261523 | unauthenticated user   | connecting host | NULL   | Connect     | NULL   | login                                          | NULL |
看上圖緊跟在Killed連接后面的4261459連接,使得19號group徹底被堵住，可憐的Killed連接連退出的機會都沒有了,這就是這126個Killed連接的由來...

向AI問一下細節(jié)

免責聲明：本站發(fā)布的內容（圖片、視頻和文字）以原創(chuàng)、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。

AI
助
手