スマートスタイル TECH BLOG

MySQL 8.0 リソースグループについて

MySQL 8.0からリソースグループが導入されましたので、検証してみたいと思います。

リソースグループ
https://dev.mysql.com/doc/refman/8.0/en/resource-groups.html

リソースグループとは

MySQLスレッドが使用できるサーバリソースに制限をかける仕組みとなります。

リソースグループは長時間実行されるトランザクションのリソースを制限したり、異なる処理をCPUのコアに割当ててスループットを安定させるといった意図で利用します。

今のところ制御できるのは個別のCPUコアへのスレッドの割当、スレッドごとのCPU利用優先度の指定です。

リソースグループの作成

まずは、リソースグループを作成します。

CREATE RESOURCE GROUP
https://dev.mysql.com/doc/refman/8.0/en/create-resource-group.html

実行のためには、RESOURCE_GROUP_ADMIN 権限が必要です。

CREATE RESOURCE GROUPの構文は以下のとおりです。

以下は作成例となります。
Batchというリソースグループを作成しています。

TYPEとは、適用できるTHREAD_PRIORITYの違いです。

THREAD_PRIORITYとは、その名の通り適用するスレッドの処理の優先度を決める値です。
-20から19までの値を取ることができ、マイナス方向に優先度が高くなります(Linuxのnice値と同じです)
TYPE=USERは 0から19 までの優先度を割り当てる事ができ、TYPE=SYSTEMは -20から0 までの優先度を割り当てる事ができます。

THREAD_PRIORITYのデフォルトはUSER/SYSTEMかかわらず0です。

なおTHREAD_PRIORITYを設定するためには、事前にCAP_SYS_NICEケイパビリティの設定が必須です。

その他の制限については、以下のURLをご確認ください。

Limitations
https://dev.mysql.com/doc/refman/8.0/en/resource-groups.html

弊社検証時には、ケイパビリティを設定しない状態でTHREAD_PRIORITYを0以外に設定するとWarningが出力されるようでした。

VCPUは使用するCPUコアのスレッド番号です。
0-2のように範囲で指定することも可能ですし、1,3-5のように、CSV形式で個別に指定も可能です。

ENABLE、DISABLEは、RESOURCE GROUPの作成時点でグループを有効にするかどうかです(デフォルトはENABLE)。
ENABLEにすると、スレッドへのグループ割当が可能となり、DISABLEにすると、スレッドへのグループ割当が出来ない状態となります。

リソースグループ の確認

INFORMATION_SCHEMA.RESOURCE_GROUPSで登録済みのリソースグループを確認します。
すでに2つのデフォルトのリソースグループが登録されています。
先程作成したBatchも確認する事ができます。

リソースグループの割当

作成し、有効化されたリソースグループは、それだけでは効果を発揮しません。
実行されたユーザースレッドへの割当が必要です。

SET RESOURCE GROUP
https://dev.mysql.com/doc/refman/8.0/en/set-resource-group.html

SET RESOURCE GROUPの実行には RESOURCE_GROUP_ADMIN/RESOURCE_GROUP_USER 動的権限のいずれかが必要です。

以下では、現在の接続スレッドにリソースグループを適用します。

以下ではThread Idを指定して適用しています。

注意点として混同しやすいのが、Thread IdはConnection Idとは異なるものである点です。
例えば、以下で確認できるのはConnection Idです。

Thread IdはConnection Idを基に検索できます。

検証

sysbenchのoltp_common.luaをカスタムして、簡単な検証を行いました。

/usr/share/sysbench/oltp_common.lua

上記では、resgroupパラメータを追加し、sysbenchの接続時に有効化する処理を追加しました。

sysbenchのパラメータは以下の通りです。

bench.cnf

sysbenchは以下のように実行します。

BatchリソースグループはVCPU=0としていますので、0番目のコアしか使用しないはずです。
sysbenchを実行すると、その様子が確認できます。

意図したとおりに動作しました。

リソースグループの定義変更

リソースグループは、割当中であっても定義を変更する事ができます。
定義変更はリソースグループに所属している接続中のスレッドに即時反映されます

ALTER RESOURCE GROUP
https://dev.mysql.com/doc/refman/8.0/en/alter-resource-group.html

定義変更には、 RESOURCE_GROUP_ADMIN 動的権限が必要です。
今度は、VCPU = 1に定義を変更してみます。

sysbenchを実行すると、1のコアに負荷が偏っている事が確認できました。

すでにユーザーに割り当てられているリソースグループを無効化するには以下のコマンドを実行します。

無効化したリソースグループに所属していたスレッドは、デフォルトのリソースグループに変更されます。
無効化したリソースグループを再度SETしようとするとエラーが発生しますので、ご注意ください。

またリソースグループを有効化する事は可能ですが、一度リソースグループが変更されたスレッドは、再度SETコマンドを実行しないと、以前割り当てていたリソースグループに移動しません。

リソースグループの削除

不要なリソースグループは削除します。

DROP RESOURCE GROUP
https://dev.mysql.com/doc/refman/8.0/en/drop-resource-group.html

スレッドによって利用中のリソースグループは削除や無効化をすることができません。

その場合、FORCE句をつけて実行することで削除が可能です。

無効化の際と同様に、利用中のスレッドはデフォルトリソースグループに移動します。

THREAD_PRIORITYの検証

THREAD_PRIORITYが異なる2つのリソースグループを作成し、それぞれのリソースグループを適用したsysbenchを並列で実行した時に
どのような影響があるか検証しました。

以下のsysbenchはほぼ同時に実行しています。

HIGH_PRIOグループの処理は通常時のTPS/QPSとなりました。

一方、LOW_PRIOグループの処理は、非常に遅くなりました。

LOW_PRIOの処理は接続時の処理も、HIGH_PRIOグループの影響でなかなか完了しなかったために、HIGH_PRIOグループよりも、その後のメインの処理完了が遅くなりましたが、HIGH_PRIOグループの処理が完了した時点で通常時のパフォーマンスに戻っている様子が確認できました。

まとめ

スレッドが使用するリソースをMySQLのレベルで細かく制御できることは、安定稼働のために役立つものと思います。
現在は比較的シンプルな制御のみですが、今後機能が拡充されていくことを期待したいと思います。

長時間バッチが実行されてリソースが専有されてしまうといった点でお困りの方はぜひMySQL 8.0を導入して、リソースグループを使ってみてはいかがでしょうか。


MySQL

 

Return Top