MySQLの一般的な（現在はオンラインでの使用）スレッドスケジューリングアプローチの一つスレッドごとの接続（接続ごとに1つのスレッド）で、サービスへの接続ごとにスレッドを作成するには、サーバー、接続が切断され、スレッドの終了またはthread_cacheを入力してください（スレッドの数に応じて設定をthread_cacheし、現在のシステムがキャッシュを持っている）、1スレッドあたりの接続スケジューリングの利点は単純であり、システムが問題に遭遇しないの前に小さな応答時間を確保することができ、アクティブ長いために、より適しアプリケーションシナリオを接続するが、大量または高い並行性短い接続で、あるスレッドごとの接続は、多数のスレッドをスケジュール/作成する必要があり、コンテキストスイッチの高コストをもたらす、システム性能よう
この問題を解決するために、OracleとMariaDBは、スレッドプールプログラム、プラグインモードとして実装され、現在Oracleのスレッドプールを導入し、唯一のエンタープライズ版に追加された、MariaDBは、バージョン5.5で導入され、我々は密接に社会動態以下されているスレッドプールのコードを、リリースしていません初めてのパフォーマンスthreapool MariaDBをテストし、これらの問題のいくつかを発見した、などと：スレッドプールを利用したい、あなたは、それ以外の場合は、1スレッドあたりの接続に退化し、スレッドプール内のスレッドの数を制御しようとする必要がありますデータスレッドプールスレッドの厳密な制御、デッドロックがスケジュールで発生する可能性がある場合、perconaはさらに優先キューの導入この問題に対する良い解決策によって達成スレッドプール移植MariaDB後スレッドプールのパフォーマンスを最適化する、効果は明らかである試験、我々 AliMySQLのため、この特性ポート
達成プロファイル
1、ワーカースレッド処理部ではなく、接続のスレッドごとの接続に対応する、ステートメントであるスレッドプール、ワーカースレッドは、送信接続するSQLを処理されました、接続が直ちに伝達されません。SQLの第二は、バックワーカースレッドへの送信に接続された他のSQL、したがってより高い効率ワーカースレッドをサービスするために、スレッドの数は、より少ない必要
競合を低減するために、消費者モデル- 2は、本質的にスレッドプールにプロデューサー単一の接続がすべてのSQLを送信するように、スレッドプールは、N群（n-デフォルトCPUコア）、接続IDに応じて異なるグループに割り当てられた接続を介して送信されたSQLに分割されるのグループを処理するワーカースレッドでありますの
SQLがオンになっているトランザクションが、タスクはプライオリティキューで、または通常キューに配置される場合に図3に示すように、各グループは、優先順位キューから、ワーカースレッドの優先順位2つのタスクキュー、すなわち、プライオリティキューと正常キューを有しますキューが（主にロック）できるだけ早く取得したリソースを解放するように、一般的なタスクはこれが実装されるトランザクションは、優先度を開設されていることを確認することができ、取る実行するために効果的な応答時間を短縮することができますから、プライオリティキューが空の場合、タスクの実行を取る、ありませんそして、トランザクションが開かれ、ロックを取得してきたです（AとBが別のグループに割り当てられているスケジュールでデッドロックを避けるため、すぐに実行するためにスケジュールされない場合があり、Bのトランザクションはリリースがリソースをロックし、トランザクションを依存しているが、最初に取得しますスケジューリング）
4、各ワーカースレッドのために、各グループに同じ位置に、あなたはタスクキューが空で発生した場合は、スレッドの呼び出しはイベントがepoll_waitバッチタスク取る
追加のスレッドは、すべての上にチェックするためにしょっちゅうタイマーを作成するスレッドプール、5グループ、見つかった場合は異常なグループ（閉塞/タイムアウト/ワーカースレッドの数が十分ではありません）、タイムリーなウェイクアップスレッド
MySQLの行に MySQLのスレッドshedulerソースコード解析、mariadb 5.5スレッドプールのソースコード解析：私は2つのブログを書いた前に、スケジューリング・プログラム・インターフェースと、スレッドプール実装の詳細を参照することができます
+ ------------------------------- + -------------- +
| 変数名| バリュー|
+ ------------------------------- + -------------- +
| thread_pool_high_prio_mode | 取引|
| thread_pool_high_prio_tickets | 4294967295 |
| thread_pool_idle_timeout | 60 |
| thread_pool_max_threads | 100000 |
| thread_pool_oversubscribe | 3 |
| thread_pool_size | 24 |
| thread_pool_stall_limit | 500 |
+ ------------------------------- + -------------- +
7行セット中の（0.00秒）
スレッドプールのパラメータ> thread_pool_high_prio_modeは
取引/文/なしの3つの値がある
取引（デフォルト）：、プライオリティキューと通常のキューを使用したトランザクションは、文のために開かれている、プライオリティキューを入れ、キューまたは共通入れ
文を：のみ使用しますプライオリティキュー
なし：のみ正常キューと文と本質的に同じ、キューであることを除い
> thread_pool_high_prio_tickets
0から（thread_pool_high_prio_mode =トランザクション）はプライオリティキューモードを開いた4294967295、の範囲は、各CIは、最大thread_pool_high_prio_ticketsに接続されていませんプライオリティキューに、その後、通常のキューに、デフォルトは4294967295です
thread_pool_idle_timeout>
ワーカースレッドの最大アイドル時間、秒単位で、制限後に終了します、デフォルト60
>はthread_pool_max_threads
スレッドプール内のスレッドの最大数、ワーカースレッドの合計数のすべてのグループを制限を超えた後に多くのスレッドを作成するために続けることができない、デフォルト100000
> thread_pool_oversubscribe
グループの過負荷制限内のスレッドの数を、とき超スレッドカウントのグループ 制限時間の後、ワーカースレッドを作成し続けデフォルト3、遅延されます
> thread_pool_size
サーバーが自動的に計算を開始し、グループのスレッドプール、CPUコアのデフォルトの数
> thread_pool_stall_limit
ミリ秒単位でタイマースレッド検出間隔を、デフォルトの500
-------------------------------------------------- -------------------------------------------------- -------------------------------------------
スレッドプールは、WebアプリケーションやDBサービス、高い同時要求が話題を中心に、常に開いていないかどうか、サーバーアプリケーションのために、コア機能MySQL5.6 Enterprise Editionのです。アプリケーションが接続を確立するために最初から、データベース操作は、アプリケーション全体が小さいオーバーヘッドではない開始、CPU部門は、それをユーザ認証に続いて特定のスレッドスタックを与えるコンテキスト情報を確立するために、要求の最終完了プロセスの第二のレベルで呼び出すことができるリソースを解放しながら、同時アクセス要求の数が多いとき、接続を閉じ、リソース使用率が得られ、連続作成やリソースの解放、といくつかは、サービスの品質を低下させる、低いです。スレッドプールは、一般的な技術である要求が到着したとき、事前に作成されたスレッドの特定の数によって、配信サービスを提供するために、スレッドプールのスレッドは、要求の終了後に、スレッドは、他の要求にサービスを提供するために行ってきました。このように、スレッドとメモリのオブジェクトを作成し、資源利用の効率を改善するために、競争力のあるコンテキストの切り替えとリソースを削減、同時実行サーバーの程度を軽減、リリース頻繁に避けます。すべてのサービスのスレッドプールの本質は、資源効率のビットであり、ほぼ同じ方法を実現します。本論文では実現MySQLのスレッドプールの原理を示します。
MySQLのスレッドプールは、I / Oの多重化の実施例です。I / Oの多重化については、http://blog.csdn.net/stubborn_cow/article/details/50247269を何を参照してくださいされます
MySQL5.6の出現する前に、MySQLは、接続を処理する方法は、つまり、各データベース接続のためには、MySQL-Serverは、スレッドを破壊し、要求の終了後に、別のスレッドのサービスを作成するワンコネクション・スレッド単位です。その後、再び接続要求、及び破壊の終了後に接続を作成します。このようにして、高い同時実行では、頻繁にスレッドの作成と放出を引き起こします。もちろん、スレッド・キャッシュは、私たちは頻繁に作成し、問題の解放を避けるために、次の使用のために、スレッドをキャッシュすることができますが、接続の高い数の問題を解決することはできません。接続サージ、サービススレッドの同じ数を作成する必要が生じ、高い同時実行スレッドの数と一の接続・パー・スレッドモードは、（CPUキャッシュのヒット率が低下する）の切り替え、より多くのコンテキストをその高いメモリ消費量を意味し、よりサービスジッタが生じリソースの競合、。ワンスレッドごとの接続モードに関しては、接続、スレッドプールの実装に対応するスレッドは、最小単位は、スレッドの文（ステートメント）、スレッドが複数の要求の接続を処理することができます。このように、インスタントサージサーバーの原因のジッタを避けるために、（スレッドプールサイズの合理的なセット）の下に接続の数を、ハードウェア資源の完全利用を確保します。
スケジューリング方式
のMySQL-Serverは、無スレッド、ワンスレッドを含まない接続管理の3種類、サポートごとの接続およびプール・スレッドを。無スレッドんメインスレッドを使用して接続を表し、追加のスレッドを作成しないでください、このアプローチは、主にデバッグのために使用されている。一つのスレッドごとの接続スレッドプールの前に、最も一般的な方法を出現させる、各接続は、サービスのスレッドを作成します。本明細書で説明するようにプールのスレッドは、スレッドプールモードです。関数へのポインタのセットを介してのMySQL-Serverは、同時に3つの接続管理をサポートし、以下のように、特定の実施形態について、関数ポインタは、接続管理thread_handlingパラメータ制御により、特定のコールバック関数に設定されています。
（<= SCHEDULER_ONE_THREAD_PER_CONNECTION thread_handling）IF
one_thread_per_connection_scheduler（thread_scheduler、
＆MAX_CONNECTIONS、
＆connection_count）を、
そうでなければ（thread_handling == SCHEDULER_NO_THREADS）IF
（thread_scheduler）one_thread_scheduler;
他の
pool_of_threads_scheduler（thread_scheduler、＆MAX_CONNECTIONS、＆connection_count）、
接続管理プロセス
1.ポートのポーリングを介してMySQLを監視接続要求
2.接続が受信された後、インターフェースコールが受け入れ、通信ソケット作成
等3.初期化THDインスタンスを、VIOオブジェクト、
実施形態thread_handling記載の組、スケジューラインスタンス初期化関数ポインタはTHD
5コールスケジューラ機能特定add_connection新しい接続
以下をコードはscheduler_functionsスレッドプールの実装テンプレートおよびテンプレートコールバック関数を示し、これは、接続管理の種々の中核です。
scheduler_functions構造体
{
UINTのMAX_THREADS;
UINT * connection_count。
ULONG * max_connectionsを。
BOOL（* INIT）（無効）。
BOOL（* init_new_connection_thread）（無効）。
無効（* add_connection）（THDの*のTHD）;
無効（* thd_wait_begin）（THDの*のTHD、int型のwait_type）。
無効（* thd_wait_end）（THDの*のTHD）;
無効（* post_kill_notification）（THDの*のTHD）;
BOOL（* end_thread）（THDの*のTHD、ブールcache_thread）。
無効（*エンド）（無効）。
}。
静的scheduler_functions tp_scheduler_functions =
{
0、// MAX_THREADS
NULL、
NULL、
tp_init、// INIT
NULL、// init_new_connection_thread
tp_add_connection、// add_connection
tp_wait_begin、// thd_wait_begin
tp_wait_end、// thd_wait_end
tp_post_kill_notification、post_kill_notification //
NULL、// end_thread
tp_end //終了
};
スレッドプールパラメータ
1.thread_handlingを：スレッドプールモデルを示しています。
2.thread_pool_sizeは：スレッドプールグループの数は、一般にCPUコアの現在の数に設定されていることを示します。理想的には、アクティブなワーカーのグループは、CPUの完全な利用を実現します。
3.thread_pool_stall_limit：タイマスレッドが定期的にグループ「停滞」パラメータは、区間検出を示しているかどうかをチェックします。
4.thread_pool_idle_timeout：作業者は自動的にアイドル期間後に出口の比較的低いレベルを維持し、要求を満たす場合には、スレッドプール内のワーカースレッドを確実にするであろう。
5.thread_pool_oversubscribe：このパラメータは、CPUコアにスレッド「OC」の数を制御するために使用されます。自由なパラメータ設定は、スレッド数を聞きます。
6.threadpool_high_prio_mode：優先モードは、キューを表します。
達成するためのスレッドプール
上ではどのようにMySQLの-Serverの接続管理説明し、このセクションで説明する実装フレームワークは、スレッドプールのほか、キーのインターフェイスに焦点を当てています。図1
各ボックスは緑色の基を表し、グループの数はthread_pool_sizeパラメータによって決定されます。各グループには、優先順位キューおよび正常キュー、リスナー・スレッドと罹患thread_pool_oversubscribeを提供しながら、ワーカースレッドのワークロードの数によって決定されるワーカースレッド、リスナー・スレッドとワーカースレッドを動的に変換することができ、複数を含むが含まれています。また、全体のスレッドプールスレッドタイマ監視グループ、グループを防ぐために、そこにある「停滞。」
キーインタフェース
1. tp_add_connection [処理新しい接続]
1）を作成し、接続オブジェクト
2）なthread_id％GROUP_COUNTグループどの接続するに応じて決定されるために割り当てられた
3）キューグループに接続に対応する
現在アクティブなスレッドの数が0である場合、作成された4）ワーカースレッド
2 worker_main [ワーカー]
1）取得要求呼get_event
要求、呼処理handle_eventがある場合2）
3）はそうでない場合、キューが終了を終了しない要求されていないことを示しています。
3. get_event【取得要求]
1）接続要求取得
2）、存在する場合、終了、直ちに返す
グループケース内には、リスナーがない場合、スレッドがブロックされた待機中のリスナー・スレッドに変換される）3を
、次いで、リスナーが存在する場合4）スレッドは、キューの先頭を待っている
））5指定した時間（thread_pool_idle_timeoutをスリープ状態にスレッドを
、スレッドの終了をタイムアウトする、6）あなたはまだ目を覚ますことができない場合は、出口の終わりを
7）それ以外の場合は、キュー接続リクエストが来示し、1つのジャンプ
注：接続要求を取得する前に、よりアクティブなスレッドの現在の数かどうかを決定する
thread_pool_oversubscribe + 1、超えた場合は、休止状態にスレッドします。
4. handle_event [処理要求]
1）ログイン認証接続かどうかを判定し、そうでない場合、ログイン認証
2）に関連する情報は、例えばTHD
3）ネットワークパケットを取得し、分析依頼
4）呼処理要求do_command関数がループ
5）THDを取得ソケットハンドルの例は、ハンドルがリストファイルディスクリプタにリスナーか否かを判断する
れていない場合）6、呼関連epoll_ctl
7）端
5.listener [リスナスレッドは】
1）グループのイベントがepoll_wait関連ブロッキングをリッスンするソケットの呼び出し待機
要求は、遮断からの回復来る場合2）
3接続の優先度に応じて、通常キューまたはプライオリティキューに決定される）
タスクキューが空であるか否かを判断する）4
、キューが空の場合、リスナーは、ワーカースレッドに変換される）5
グループ内のアクティブなスレッドが存在しない場合は6）、その後、スレッドを覚ます
注：このイベントがepoll_waitは、接続に耳を傾け、その後、グループ内のすべてのソケット接続に耳を傾け、そして
キューをプッシュする要求、ワーカースレッドがキューからタスクを取得し、その後、実行しました。
6. timer_thread [監視スレッド]
1）そこには、リスナー・スレッドがありません、そして最近の出来事はio_eventしていない場合
2）ウェイクを作成したり、ワーカースレッドを作成します
処理要求が最新のグループではなく、キューが要求がある場合は3）、
4）グループが失速、ウェイクアップを持っているか、スレッドの作成を表し
注：タイマーの役割は、グループでのストール状態を避けるためです
7.tp_wait_beginを[プロセスが待機状態に入ります]
1）アクティブなスレッドから1を引いた数が、いくつかのスレッドを待って、プラスワン
のアクティブなスレッドの数がゼロであり、タスクキューが空ではないか、またはリスニングスレッドが存在しない場合は2）、その後、
スレッド3）ウェイクを作成したり、
注意：スレッドがありますwaiting_threadsいわゆる空のアイドルスレッド、スレッドが待機していない
アイドル状態のスレッドがタスクを処理する準備ができたスレッドであり、待機中のスレッドがロックを待機しているので、それがある、またはIOオペレーションを待つ
ように扱うことができないなどのタスクのためのスレッド。
8.tp_wait_end [スタンバイ状態のプロセスの終了]
1）接続待機状態が偽に設定されている
2）アクティブなスレッドの数、プラス1、マイナス待機中のスレッドの数
、スレッドプールと接続プール
接続プーリングは通常、それは顧客にすべてのDB要求を終了するには、これらの接続サービスを使用して、特定の事前に作成した接続を作成するためのアプリケーション（??クライアント）を意味し、クライアント側で実装されています。ある瞬間の接続数は、要求の数がアイドルDB未満の場合、要求は、無料接続処理を待って、キューに入れることが必要です。これにより、要求の平均応答時間を短縮すること、頻繁な接続を回避し、解放するために作成された多重接続プールによって接続することができ、そしてリクエストがビジーである、要求がキューイングされ、アプリケーションは、DBの衝撃を緩衝することができます。スレッドプールの実装サーバ側、接続にサービスを提供するスレッドの1たっあたりのスレッドを実施形態に関して一定量を作成するために、サービス・スレッドDB要求、すなわち、あるスレッドが複数に対応することができるステートメントスレッドプールとサービスの最小単位2つのアクティブな接続。スレッドプールでは、サービススレッドサーバー側の数をある程度制御することができ、競争とスレッドコンテキストの切り替えがもたらすシステムリソースの消費量を削減するだけでなく、高並行性の問題を回避するには、接続の高い数のために発生します。接続プーリングとスレッドプールは互いに補完、要求の平均応答時間を増やし、プール作成および接続の解除を接続することにより低減することができ、そしてウェルDB接続数のアプリケーションを制御することができるが、このように、アプリケーション全体のクラスタのサイズへの接続の数を制御することができません接続の高い数で、その結果、それが十分安定したサービスを提供するサーバー側を確実にするために、スレッドプールによって接続された高番号に対応することができます。示され、各ウェブサーバ端末2は、排他的に、DBサーバが実際にプールに接続されていない労働者を接続するための3つの、それぞれの接続のプールを維持するが、他の接続と共有することができます。それだけで3デシベルサーバグループ、各グループにのみ労働者、労働者が2の接続のための各要求を処理するものとします。
図2（図プールフレームプールネジ接続）
スレッドプールの最適化
1.プライオリティキューを
基に、複数の接続を処理するが、複数のピアに接続されていないからです。例えば、一部は第1の送信要求に接続され、そして対応するトランザクションに接続されたいくつかが開かれており、保持部ロックリソース。リソースのロック競合を削減するためには、前者よりも後者は、できるだけ早くロックリソースの解放を達成するために、明確に優先されるべきです。そのため、内部のグループでは、すでにプライオリティキューに開始した接続要求のロックを保持して、プライオリティキューを追加することができ、作業キューのスレッドが最初の優先度のタスクの実行を取得します。
2.大規模なクエリ処理は
、グループに接続されているシナリオは、大きなクエリあると仮定グループ内のワーカースレッドの数はすぐに後続の接続要求のthread_pool_oversubscribeパラメータの値に達するだろう、その後、それは（時間内に応答しません処理するために、これ以上の接続）、グループは場所ストールを取った今回。以前の分析が知っていることで、タイマースレッドは、定期的に状況を確認し、要求を処理するための新しいワーカースレッドを作成します。クエリは、この時点での長いサービス要求から来る場合、すべてのグループのホストは、ライブハングアップにつながる過負荷が原因である可能性がありとき、この問題に直面しています。この場合、スレッド・プール自体無力、ソースが悪いSQL、SQLによって複雑にしてもよいし、緊急時の処理であってもよいようにSQLまたはSQL水位制限フィルタ手段のような他の方法を通じて、実施計画に率先していなかったので。しかし、タスクをダンプする別の状況があります。多くは、下流の下流引か通常、ダンプ・コマンドデータによって、データベース内の元のデータに依存し、それは大きなクエリと考えることができるように、このダンプタスクは通常、時間がかかります。ダンプ・タスクがグループに集中し、そしてすぐに応答することはできません他の通常のサービス要求につながる場合、これは、許容できないため、データベースや無加圧、スレッドプールポリシーを使用すると、タイムリーにするためには、要求に応答しない結果だったという理由だけでこの問題を解決するために、我々はグループの累積値に含まれていないスレッドダンプthread_pool_oversubscribeのタスクは、この問題を避けるためにします。