スレッドのコンカレンシーについて説明する

  • 5 分

すべてのクライアント接続には独自のスレッドがあり、クエリはそのスレッド内で実行されます。 各スレッドは 1 つのコアで実行されます。 コンカレンシーとは、同時に実行できるスレッドの数のことです。 既定では、InnoDB ストレージ エンジンは必要な数のスレッドを同時に実行します。

InnoDB では、複数のサーバー パラメーターを使用してスレッド コンカレンシーが管理されます。 同時スレッドの数は、次の 2 つのパラメーターによって調整されます。

  • innodb_thread_concurrency
  • innodb_thread_sleep_delay（InnoDBスレッドスリープ遅延）

innodb_thread_concurrencyの既定値は 0 です。つまり、InnoDB では同時に実行されるスレッドの数が制限されません。 通常は、一度に実行できる同時スレッドの数を制限する必要がない限り、このパラメーターを変更しないことをお勧めします。

データベースのワークロードが特に高い場合や、コンカレンシーが原因でパフォーマンスが低下していると思われる場合には、同時に実行されるスレッドの数に制限を設定できます。 開始点として、 innodb_thread_concurrency を同じ数または使用可能なコア数の 2 倍に設定します。 各クエリは 1 つのコアでのみ実行可能ですが、実行時間は非常に高速になります。

innodb_thread_concurrencyが制限 に 達したためにスレッドを実行できない場合、 innodb_thread_sleep_delay は、再度実行を試みる前にスレッドが待機するマイクロ秒数を定義します。 既定値は 10,000 マイクロ秒です。 2 回目の実行ができない場合、スレッドはスレッド キューに配置されます。 innodb_thread_sleep_delayの値は、ほとんどのワークロードで正しくなり、非常に多数の非常に小さなクエリを実行した場合にのみ、この値が大きくなりすぎて待機時間が発生する可能性があります。 ただし、値を変更する前に 、innodb_adaptive_max_sleep_delayの設定を検討してください。

innodb_adaptive_max_sleep_delay を使用すると、InnoDB は現在のワークロードに応じて innodb_thread_sleep_delay 値を調整できます。 innodb_adaptive_max_sleep_delayの既定値は 15,000 マイクロ秒です。 スリープ遅延は、この最大値を上限として上下に調整されます。

ヒント

適切なハードウェアと MySQL バージョン 8.0 以降で実行している場合は、コンカレンシー パラメーターを変更する必要はないでしょう。 最新バージョンの MySQL で実行していない場合は、コンカレンシー パラメーターをチューニングする 前に 最新バージョンにアップグレードしてください。

注意

オンプレミスのハードウェアで実行している場合、コンカレンシーのボトルネックを解決するために新しいハードウェアを購入することは困難です。 これらのシナリオでは、データをシャード化することをお勧めします。

Azure Database for MySQL では、コンピューティング レベルを簡単かつコスト効率よくアップグレードできます。

実行時間の長いクエリの場合、 innodb_concurrency_tickets パラメーターは "チケット" の数を定義します。また、作業量は、それ以上コンカレンシー チェックを行わずに実行できます。 実行時間の長いクエリが多数ある場合は、必要に応じてこの値を調整できます。 ただし、ほとんどのワークロードでは、この値を変更する必要はありません。

最後に、 innodb_commit_concurrency パラメーターは、同時にコミットできるスレッドの数を定義します。 同時に実行できるスレッドの数を制限するように innodb_thread_concurrency 値を設定した場合、 innodb_commit_concurrency を小さい値に調整すると、さらに役立つ場合があります。 既定値は 0 です。つまり、任意の数のスレッドを同時にコミットできます。

これらのパラメーターはすべて、Azure portal、 サーバー パラメーター、または Azure CLI を使用して表示および変更できます。

MySQL Workbench からは、作成されたスレッドの数、接続されているスレッドの数、実行中のスレッドの数を確認できます。

MySQL Workbench のクライアント接続を示すスクリーンショット。

MySQL Workbench でクライアント接続を表示するには:

  1. 既存の名前付き接続を使用するか、新しい接続を作成して MySQL サーバーに接続します。
  2. MySQL Workbench がサーバーに接続し、[ クエリ] タブを開きます。
  3. [ 管理 ] タブを選択します。
  4. [ 管理] で、[ クライアント接続] を選択します。 次のメトリックが表示されます。
    1. 接続されているスレッド
    2. 実行中のスレッド
    3. 作成されたスレッド
    4. キャッシュされたスレッド
    5. 合計接続数
    6. 接続の制限
    7. 中止されたクライアント
    8. 中止された接続

クライアント接続の制限

MySQL では通常、必要な数のクライアント接続に対応できます。 ただし、実行されている各クエリで接続が多すぎると、 すべての クエリが完了するまでの実行時間が遅くなる可能性があります。 これは Thundering Herd (雷鳴の群れ) と呼ばれる問題です。既存の接続を妥当な時間内で実行できずにいる間に、新しい接続が追加されてくることで発生します。

Azure Database for MySQL では、サーバーへの接続数を制限できます。 この番号は、接続制限として MySQL Workbench に表示され、max_connectionsと呼ばれるサーバー パラメーターの下の Azure Database for MySQL のパラメーターでもあります。 接続数がこの制限に達すると、接続数が減るまで、サーバーはそれ以上のユーザーに接続しなくなります。 これは、サーバーが過負荷になり、クエリの実行時間が長くなりすぎるのを防ぐための手段です。

max_connections値を変更するには、Azure portal に移動し、Azure Database for MySQL サーバーに移動して、[サーバー パラメーター] を選択します。 検索バーに 「max_connections 」と入力して、 max_connections 値を表示または編集します。

max_connections使用可能な CPU コアの 1 倍、2 倍、または 4 倍に設定します。 1 秒あたりのトランザクション数が増えなくなるまで、 max_connections の数を 2 倍にします。 待機時間が長くなり始めたら、接続数によってパフォーマンスが制限されていないということになります。