Mariadb Thread Pool 分析

對于MySQL5.5來說隻有企業版本中含有 Thread Pool，但幸運的是 mariadb 5.1中就已存在該功能，mariadb 5.5 中進行了改進。

    本篇暫且介紹FAQ：後期會放出其工作原理及使用情況。

    适用threadpool場景:查詢相對較短，或者CPU比較吃緊。或者可以通過 threadpool 限制線程數量來達到節省記憶體的目的。

    安裝條件：Linux 核心需高于2.6.9 版本

    在某些場合下 效果可能不是很理想：

    1、突發的工作負載，長時間不活動和很多短期的高活躍連接配接，這個是有可以通過調整等待時間來應對這樣的情況。Thread_pool_idle_timeout

    2、并發很多，且長時間執行的查詢，一個線程執行的時候 都是重新建立，也不會等待threadpool 釋放資源，這種出現在資料倉庫的情景。長時間運作的查詢會阻塞其他查詢的執行，對于擁有阻塞監測或者其他搶占機制 可以固定 阻塞時長

    3、一些簡單的查詢總是很快執行完畢。無論你的機器負載多高，在擁有 threadpool 的時候，query 可能會出現排隊情況，比如select  1；可能會比thread-per-connection消耗更多時間。

FAQ：

    線程池解決的問題：

    1、太多的線程堆棧，幾乎讓CPU的緩存無用，線程池 可以減少CPU占用記憶體空間。

    2、建立過多的線程容易導緻過多的上下文切換，解決辦法是是維持一組低于用戶端連接配接數量，平衡mysql連接配接并保持較高性能。

    3、過多的事務并發執行導緻資源争用，延長熱鎖争用

    線程池如何限控制并發的會話線程和事務來達到最優的性能和吞吐量？

    該線程池使用“分步解決”的方法來限制和平衡并發量，線程池将connections 和threads分開，這樣thread 執行從connections 接受的statement，兩者并沒有固定的綁定在一起。線程池根據配置的已劃分優先級的thread group 來處理連接配接。

    線程池和用戶端連接配接池有什麼差別：

    兩者的職責不是同的：

用戶端連接配接池：處于用戶端一邊，client不會不斷的連接配接或斷開server，它被設計為 緩存空閑的連接配接來被其他的connections 使用。減小建立和拆除connections的開銷。Client pool 對查詢處理能力和後端資料庫的負載時不可見的。相比之下 thread pool 是處在MySQL 這一端的。它們被設計為管理已經建立的 connections 和接受到的query

    線程池在連接配接太多的時候怎麼動态擴充，在連結減少的時候怎麼收縮；線程池本身的開銷怎樣控制；是否能夠利用OS原生的線程池來直接提供服務等一系列問題都是引入線程池需要考慮的。

線程互相等待的問題。如果有長連結和短連結同時存在，那麼短連結可能要等到長連結執行完所有操作，才能被輪到，執行時間不可控.

本文轉自 位鵬飛 51CTO部落格，原文連結：http://blog.51cto.com/weipengfei/1163017，如需轉載請自行聯系原作者