最近出現多次由於上層組件異常導致DB雪崩的情況,筆者將部分監控DB啟用了線程池功能,在使用線程池的過程中不斷深入學習的同時,也遇到了不少問題。
本文就來詳細講述一下MySQL線程池相關的知識,以幫助廣大DBA快速瞭解MySQL的線程池機制,快速配置MySQL的線程池以及裡面存在的一些坑。其實我想說,瞭解和使用MySQL線程池,看這篇文章就夠了。
一、為何要使用MySQL線程池
在介紹為什麼要使用線程池之前,我們都知道隨著DB訪問量越來越大,DB的響應時間也會隨之越來越大,如下圖:
而DB的訪問大到一定程度時,DB的吞吐量也會出現下降,並且會越來越差,如下圖所示:
那麼是否有什麼方式,能實現隨著DB的訪問量越來越大,DB始終表現出最佳的性能呢?類似下圖的表現:
答案就是今天要重點介紹的線程池功能。總結一下,使用線程池的理由有兩個:
1、減少線程重複創建與銷燬部分的開銷,提高性能
線程池技術通過預先創建一定數量的線程,在監聽到有新的請求時,線程池直接從現有的線程中分配一個線程來提供服務,服務結束後這個線程不會直接銷燬,而是又去處理其他的請求。這樣就避免了線程和內存對象頻繁創建和銷燬,減少了上下文切換,提高了資源利用率,從而在一定程度上提高了系統的性能和穩定性。
2、對系統起到保護作用
線程池技術限制了併發線程數,相當於限制了MySQL的runing線程數,無論系統目前有多少連接或者請求,超過最大設置的線程數的都需要排隊,讓系統保持高性能水平,從而防止DB出現雪崩,對底層DB起到保護作用。
可能有人會問,使用連接池能否也達到類似的效果?
也許有的DBA會把線程池和連接池混淆,但其實兩者是有很大區別的:連接池一般在客戶端設置,而線程池是在DB服務器上配置;另外連接池可以起到避免了連接頻繁創建和銷燬,但是無法控制MySQL活動線程數的目標,在高併發場景下,無法起到保護DB的作用。比較好的方式是將連接池和線程池結合起來使用。
二、MySQL線程池介紹
MySQL線程池簡介
為了解決one-thread-per-connection(每個連接一個線程)存在的頻繁創建和銷燬大量線程以及高併發情況下DB雪崩的問題,實現DB在高併發環境依然能保持較高的性能。
Oracle和MariaDB都推出了ThreadPool方案,目前Oracle的Thread pool實現為Plugin方式,並且只添加到在Enterprise版本中,Percona移植了MariaDB的Thread pool功能,並做了進一步的優化。本文的環境就基於Percona MySQL 5.7版本。
MySQL線程池架構
MySQL的Thread pool(線程池)被劃分為多個group(組),每個組又有對應的工作線程,整體的工作邏輯還是比較複雜,下面我試圖通過簡單的方式來介紹MySQL線程池的工作原理。
1、架構圖
首先來看看Thread Pool的架構圖。
2、Thread Pool的組成
從架構圖中可以看到Thread Pool由一個Timer線程和多個Thread Group組成,而每個Thread Group又由兩個隊列、一個listener線程和多個worker線程構成。下面分別來介紹各個部分的作用:
- 隊列(高優先級隊列和低優先級隊列)
用來存放待執行的IO任務,分為高優先級隊列和低優先級隊列,高優先級隊列的任務會優先被處理。
什麼任務會放在高優先級隊列呢?
事務中的語句會放到高優先級隊列中,比如一個事務中有兩個update的SQL,有1個已經執行,那麼另外一個update的任務就會放在高優先級中。這裡需要注意,如果是非事務引擎,或者開啟了Autocommit的事務引擎,都會放到低優先級隊列中。
還有一種情況會將任務放到高優先級隊列中,如果語句在低優先級隊列停留太久,該語句也會移到高優先級隊列中,防止餓死。
- listener線程
listener線程監聽該線程group的語句,並確定當自己轉變成worker線程,是立即執行對應的語句還是放到隊列中,判斷的標準是看隊列中是否有待執行的語句。
如果隊列中待執行的語句數量為0,而listener線程轉換成worker線程,並立即執行對應的語句。如果隊列中待執行的語句數量不為0,則認為任務比較多,將語句放入隊列中,讓其他的線程來處理。這裡的機制是為了減少線程的創建,因為一般SQL執行都非常快。
- worker線程
worker線程是真正幹活的線程。
- Timer線程
Timer線程是用來週期性檢查group是否處於處於阻塞狀態,當出現阻塞的時候,會通過喚醒線程或者新建線程來解決。
具體的檢測方法為:通過queue_event_count的值和IO任務隊列是否為空來判斷線程組是否為阻塞狀態。
每次worker線程檢查隊列中任務的時候,queue_event_count會+1,每次Timer檢查完group是否阻塞的時候會將queue_event_count清0,如果檢查的時候任務隊列不為空,而queue_event_count為0,則說明任務隊列沒有被正常處理,此時該group出現了阻塞,Timer線程會喚醒worker線程或者新建一個wokrer線程來處理隊列中的任務,防止group長時間被阻塞。
3、Thread Pool的是如何運作的?
下面描述極簡的Thread Pool運作,只是簡單描述,省略了大量的複雜邏輯,請不要挑刺~
Step1:請求連接到MySQL,根據threadid%thread_pool_size確定落在哪個group;
Step2:group中的listener線程監聽到所在的group有新的請求以後,檢查隊列中是否有請求還未處理。如果沒有,則自己轉換為worker線程立即處理該請求,如果隊列中還有未處理的請求,則將對應請求放到隊列中,讓其他的線程處理;
Step3:group中的thread線程檢查隊列的請求,如果隊列中有請求,則進行處理,如果沒有請求,則休眠,一直沒有被喚醒,超過thread_pool_idle_timeout後就自動退出。線程結束。當然,獲取請求之前會先檢查group中的running線程數是否超過thread_pool_oversubscribe+1,如果超過也會休眠;
Step4:timer線程定期檢查各個group是否有阻塞,如果有,就對wokrer線程進行喚醒或者創建一個新的worker線程。
4、Thread Pool的分配機制
線程池會根據參數thread_pool_size的大小分成若干的group,每個group各自維護客戶端發起的連接,當客戶端發起連接到MySQL的時候,MySQL會跟進連接的線程id(thread_id)對thread_pool_size進行取模,從而落到對應的group。
thread_pool_oversubscribe參數控制每個group的最大併發線程數,每個group的最大併發線程數為thread_pool_oversubscribe+1個。若對應的group達到了最大的併發線程數,則對應的連接就需要等待。這個分配機制在某個group中有多個慢SQL的場景下會導致普通的SQL運行時間很長,這個問題會在後面做詳細描述。
MySQL線程池參數說明
關於線程池參數不多,使用show variables like 'thread%'可以看到如下圖的參數,下面就一個一個來解析:
- thread_handling
該參數是配置線程模型,默認情況是one-thread-per-connection,即不啟用線程池;將該參數設置為pool-of-threads即啟用了線程池。
- thread_pool_size
該參數是設置線程池的Group的數量,默認為系統CPU的個數,充分利用CPU資源。
- thread_pool_oversubscribe
該參數設置group中的最大線程數,每個group的最大線程數為thread_pool_oversubscribe+1,注意listener線程不包含在內。
- thread_pool_high_prio_mode
高優先級隊列的控制參數,有三個值(transactions/statements/none),默認是transactions,三個值的含義如下:
transactions:對於已經啟動事務的語句放到高優先級隊列中,不過還取決於後面的thread_pool_high_prio_tickets參數。
statements:這個模式所有的語句都會放到高優先級隊列中,不會使用到低優先級隊列。
none:這個模式不使用高優先級隊列。
- thread_pool_high_prio_tickets
該參數控制每個連接最多語序多少次被放入高優先級隊列中,默認為4294967295,注意這個參數只有在thread_pool_high_prio_mode為transactions的時候才有效果。
- thread_pool_idle_timeout
worker線程最大空閒時間,默認為60秒,超過限制後會退出。
- thread_pool_max_threads
該參數用來限制線程池最大的線程數,超過該限制後將無法再創建更多的線程,默認為100000。
- thread_pool_stall_limit
該參數設置timer線程的檢測group是否異常的時間間隔,默認為500ms。
三、MySQL線程池的使用
線程池的使用比較簡單,只需要添加配置後重啟實例即可。
具體配置如下:
#thread pool
thread_handling=pool-of-threads
thread_pool_oversubscribe=3
thread_pool_size=24
performance_schema=off
#extra connection
extra_max_connections = 8
extra_port = 33333
備註:其他參數默認即可
以上具體的參數在前面已做詳細說明,下面是配置中需要注意的兩個點:
1、之所以添加performance_schema=off,是由於測試過程中發現Thread pool和PS同時開啟的時候會出現內存洩漏問題(後文會詳細敘述);
2、添加extra connection是防止線程池滿的情況下無法登錄MySQL,因此特意用管理端口,以備緊急的情況下使用;
重啟實例後,可以通過show variables like '%thread%';來查看配置的參數是否生效。
四、使用中遇到的問題
在使用線程池的過程中,我遇到了幾個問題,這裡也順便做個總結:
內存洩漏問題
DB啟用線程池後,內存飆升了8G左右,如下圖:
不但啟用線程池後內存飆升了8G左右,而且內存還在持續增長,很明顯啟用線程池後存在內存洩漏問題了。
網上也有不少的人遇到這個問題,確認是percona的bug導致(https://jira.percona.com/browse/PS-3734),只有開啟Performance_Schema和ThreadPool的時候才會出現,解決辦法是關閉Performance_Schema,具體操作方法是在配置文件添加performance_schema=off,然後重啟MySQL就OK。
下面是關閉PS後的內存使用情況對比:
備註:目前Percona server 5.7.21-20版本已經修復了線程池和PS同時打開內存洩漏的問題,從我測試的情況來看問題也得到了解決,大家可以直接使用Percona server 5.7.21-20的版本,如下圖。
撥測異常問題
啟用線程池以後,相當於限制了MySQL的併發線程數,當達到最大線程數的時候,其他的線程需要等待,新連接也會卡在連接驗證那一步,這時候會造成撥測程序連接MySQL超時,撥測返回錯誤如下:
撥測程序連接實例超時後,就會認為master已經出現問題。極端情況下,重試多次都有異常後,就啟動自動切換的操作,將業務切換到從機。
這種情況有兩種解決辦法:
1、啟用MySQL的旁路管理端口,監控和高可用相關直接使用MySQL的旁路管理端口。
具體做法為:在my.cnf中添加如下配置後重啟,就可以通過旁路端口登錄MySQL了,不受線程池最大線程數的影響:
extra_max_connections = 8
extra_port = 33333
備註:建議啟用線程池後,把這個也添加上,方便緊急情況下進行故障處理。
2、修改高可用探測腳本,將達到線程池最大活動線程數返回的錯誤做異常處理,當作超過最大連接數的場景。(備註:超過最大連接數只告警,不進行自動切換)
慢SQL引入的問題
隨著對撥測超時的問題的深入分析,線程池滿只是監控撥測出現超時的其中一種情況,還有一種情況是線程池並沒有滿,線上的兩個配置:
thread_pool_oversubscribe=3
thread_pool_size=24
按照上面的兩個配置來計算的話,總共能併發運行24x(3+1)=96,但是根據多次問題的追中,發現有多次線程池並沒有達到96,也就是說整體的線程池並沒有滿。那會是什麼問題導致撥測失敗呢?
鑑於線程池的結構和分配機制,通過前面線程池部分的描述,大家都知道了在內部是將線程池分成一個一個的group,我們線上配置了24個group,而線程池的分配機制是對Threadid進行取模,然後確定該線程是落在哪個group。
出現超時的時候,有很多的load線程到導入數據。也就是說那個時候有部分線程比較慢的情況。那麼會不會是某個group的線程滿了,從而導致新分配的線程等待?
有了這個猜想以後,接下來就是來驗證這個問題。驗證分為兩步:
1、抓取線上運行的processlist,然後對threadid取模,看看是否有多個load線程落在同一個group的情況;
2、在測試環境模擬這種場景,看看是否符合預期。
線上場景分析
先來看線上的場景,通過抓取撥測超時時間點的processlist,找出當時正在load的線程,根據threadid進行去模,並進行彙總統計後,得出如下結果:
可以看出,當時第4和第7個group的請求個數都超過了4個,說明是單個group滿導致的撥測異常。當然,也會導致部分運行很快的SQL變慢。
測試環境模擬場景分析
為了構建快速重現環境,我將參數調整如下:
thread_pool_oversubscribe=1
thread_pool_size=2
通過上面參數的調整,可以計算出最大併發線程為2x(1+1)=4,如下圖,當活動線程數超過4個後,其他的線程就必須等待:
我模擬線上環境的方法為開啟1個線程的慢SQL,這時測試環境的線程池情況如下:
按照之前的推測,這時Group1的處理能力相當於Group2的處理能力的50%,如果之前的推論是正確的,那麼分配在Group1上的線程就會出現阻塞。
比如此時來了20個線程請求,按照線程池的分配原則,此時Group1和Group2都會分到10個線程請求。如果所有的線程請求耗時都是一樣的,那麼分配到Group1上的線程請求整體處理時間應該是分配到Group2上整體處理時間的2倍。
我使用腳本,併發起12個線程請求,每個線程請求都運行select sleep(2),那麼在Group1和Group2都空閒的情況下,運行情況如下:
2018-03-18-20:23:53
2018-03-18-20:23:53
2018-03-18-20:23:53
2018-03-18-20:23:53
2018-03-18-20:23:55
2018-03-18-20:23:55
2018-03-18-20:23:55
2018-03-18-20:23:55
2018-03-18-20:23:57
2018-03-18-20:23:57
2018-03-18-20:23:57
2018-03-18-20:23:57
每次4個線程,總共運行了6秒。
接下來在Group1被1個長時間運行的線程沾滿以後,看看測試結果是怎麼樣的:
2018-03-18-20:24:35
2018-03-18-20:24:35
2018-03-18-20:24:35
2018-03-18-20:24:37
2018-03-18-20:24:37
2018-03-18-20:24:37
2018-03-18-20:24:39
2018-03-18-20:24:39
2018-03-18-20:24:39
2018-03-18-20:24:41
2018-03-18-20:24:43
2018-03-18-20:24:45
從上面的結果中可以看出,在沒有阻塞的時候,每次都是4個線程,而後面有1個線程長時間運行的時候,就會出現那個長時間線程對應的group出現排隊的情況,最後雖然有3個空閒的線程,但是卻只有1個線程在處理(標紅部分結果)。
解決方法有兩個:
1、將thread_pool_oversubscribe適當調大,這個辦法只能緩解類似問題,無法根治;
2、找到慢的SQL,解決慢的問題。
歡迎大家點贊關注轉發一起來討論~~如有錯誤,還請多多指正哦!!!
閱讀更多 Java技術虎 的文章