MySQL thread pool【轉】

時間 2019-12-20

標籤 mysql thread pool 欄目 MySQL 简体版

原文原文鏈接

本文來自：http://blog.chinaunix.net/uid-26896862-id-3993773.htmlhtml

剛剛經歷了淘寶的雙11，真實感覺到了緊張的氛圍。儘管DB淡定的度過，可是歷程中的波折，可謂驚心動魄。其中MySQL在大量鏈接（萬級）的場景下，表現出性能遠遠低於預期，而且出現明顯的波動，成爲一個很是重要的問題。問題雖然解決，可是後續的思考和方法的探索，仍然繼續。如下是在MySQL層增長Thread pool方式，解決大量鏈接問題。mysql

一、《MySQL Thread Pool: Problem Definition》

MySQL企業版在5.5中，引入了Thread pool方案。本文主要是分析現有方式存在的問題，並引入Thread pool方式以及需求。主要解決MySQL傳統鏈接設計中one-to-one方式（一個鏈接使用一個線程服務）存在兩個方面的問題：算法

1.1 CPU資源限制

在鏈接數很是多，併發較大時，CPU可用資源會成爲MySQL的鏈接線程的瓶頸，致使MySQL性能下降。有兩個緣由：一個是併發數較大時，CPU的cache命中率下降，以及併發線程建立消耗內存資源，可能致使swap影響MySQL的性能；另外一個緣由是併發較大時，會致使經過臨界資源時，產生大量的鎖競爭。這些問題在系統層都很難解決，只能經過應用層解決。sql

1.2 Innodb mutex鎖

在併發較大時，會引發Innodb的mutex鎖爭用。當前解決方法是經過innodb_thread_concurrency參數，可是該參數自身也存在鎖爭用，一樣影響了MySQL的性能。在咱們的優化歷程中，也嘗試經過優化該參數，來解決併發狀況下，性能下降的問題。可是測試過程當中發現，會有大量的鏈接等待kernel mutex鎖，可是持續的壓力會致使MySQL的thread running，最終致使MySQL不可用。數據庫

Thread pool主要從四個方面考慮：減小SQL併發，使得有足夠的資源；使用線程組，獨立管理；使用優先級隊列，限制併發執行的事務；避免死鎖。服務器

在以上闡述的內容中，幾乎涵蓋了咱們遇到的全部現象和問題，而性能影響會如此嚴重，是咱們始料未及的。數據結構

二、《MySQL Thread Pool: Scalability solution》

基於上文中問題定義，本文主要討論Thread pool的可擴展性解決方案。爲了解決併發鏈接數問題，一般考慮會建立一個線程池，可是會引入可擴展性問題：每一個鏈接或線程創建時，會對公用的數據結構加鎖，修改鏈接或線程的狀態信息。這樣無異於從新引入熱點。併發

爲了不引入新的問題，Thread pool使用線程組，每一個線程組管理組內的鏈接和線程，線程組之間互相不受影響。而且確保每一個線程組內最多有一個活躍的線程鏈接，這樣鏈接和線程創建時，僅對單個線程組內的數據結構加鎖，文中稱之爲分治法。性能

在文章回復中，有一個問題很是重要：線程組的引入，會出現當等待線程組時，請求不能進入而阻塞鏈接，而該問題會經過定時器的方式解決。另外一個問題是：經過限制每一個用戶的鏈接數，而MySQL層經過innodb_thread_concurrency參數控制，來控制併發鏈接數。對於第二個問題，當應用達到必定重量級時，限制用戶鏈接數變得比較困難。假設有幾千臺應用服務器，每一個應用服務器1~2個數據庫鏈接，一樣會出現併發鏈接過多的問題。也就是說經過用戶鏈接數限制，治標不治本。測試

三、《MySQL Thread Pool: Limiting number of concurrent statement executions》

上文回覆中，提出當線程組引入後，SQL語句可能會致使線程組的等待，阻塞大量查詢。本文中針對該問題，提出了經過定時器的方式解決。當SQL查詢執行超過定時器的時間，線程組將會設置爲不可用。

此外，當查詢因爲鎖被阻塞時，線程會等待超時時間，而後處理新的查詢請求，從而保證了線程組的可用。

四、《MySQL Thread Pool: Limiting number of concurrent transactions》

對於事務的併發控制，Thread pool採用優先級隊列的方式解決。爲了不大事務致使線程組不可用，引入了thread_pool_prio_kickup_timer參數，當事務超過參數設置的超時時間時，等待線程組的查詢會被移到高優先級隊列中。爲了不過多的移動，Thread pool限制每一個線程組在10ms內最多移動一次。

經過優先級隊列，能夠很大程度上解決由於事務阻塞，而產生大量查詢超時的問題，還解決了其餘線程組空閒的狀況。

五、《MySQL Thread Pool: When to use?》

Thread pool的原理和實如今以上文章中進行了詳細的解釋，可是何時用呢？本文指出根據threads_running的監控值，來判斷是否使用Thread pool。當threads_running值超出了MySQL的處理能力時，Thread pool將會保護MySQL server。

此外，Thread pool和innodb_thread_concurrency參數一塊兒使用，能夠更好的控制併發。Thread pool主要在Server層，在事務開始以前進行限制，innodb_thread_concurrency在事務處理中進行控制。

特別指出，若是查詢爲短查詢，Thread pool會很是有效。若是查詢爲長查詢，Thread pool會有性能影響。

六、《MySQL Thread Pool vs. Connection Pool》

針對文章2中回覆的第二個問題，本文詳細解釋了Thread pool和Connection pool二者的區別。Thread pool主要是MySQL端採起的線程控制，用於限制MySQL實際處理的SQL併發。而Connection pool是在應用的客戶端來限制，鏈接到MySQL Server的線程數。

在某些狀況下，Connection pool並不是全部的鏈接都有活躍的事務，可是會在MySQL Server中創建大量的鏈接。而經過Thread pool，能夠減小MySQL Server的鏈接數。

七、《MySQL Thread Pool: Optimal configuration》

本文主要介紹Thread pool使用的參數進行詳細的說明，主要包括：thread_pool_size指定線程池大小，默認值爲16；thread_pool_stall_limit執行線程池超時時間，默認值爲6（60ms）；thread_pool_prio_kickup_timer限制優先級隊列移動的超時時間，默認值爲1000（1s）；thread_pool_algorithm指定線程池算法，暫不支持；thread_pool_max_unused_threads查看當前最大未使用的線程數。

在實際使用中，根據數據庫服務器的性能，MySQL Server的使用狀況，以及應用查詢的狀況，調整這些參數，從而達到最佳的性能。