メインコンテンツまでスキップ
バージョン: Stable-3.3

リソースグループ

このトピックでは、StarRocks のリソースグループ機能について説明します。

resource group

この機能を使用すると、短いクエリ、アドホッククエリ、ETL ジョブなど、複数のワークロードを単一のクラスターで同時に実行でき、複数のクラスターを展開するための追加コストを削減できます。技術的な観点から見ると、実行エンジンはユーザーの指定に従って同時実行ワークロードをスケジュールし、それらの間の干渉を隔離します。

リソースグループのロードマップ:

  • v2.2 以降、StarRocks はクエリのリソース消費を制限し、同じクラスター内のテナント間でのリソースの隔離と効率的な使用を実現します。
  • StarRocks v2.3 では、大規模クエリのリソース消費をさらに制限し、過大なクエリ要求によってクラスターリソースが枯渇するのを防ぎ、システムの安定性を保証します。
  • StarRocks v2.5 はデータロード(INSERT)の計算リソース消費を制限します。
  • v3.3.5 以降、StarRocks は CPU リソースに対する厳しい制限を課すことをサポートします。
Internal TableExternal TableBig Query RestrictionINSERT INTOBroker LoadRoutine Load, Stream Load, Schema ChangeCPU Hard Limit
2.2×××××x
2.3×××x
2.5××x
3.1 & 3.2×x
3.3.5 and later×

用語

このセクションでは、リソースグループ機能を使用する前に理解しておくべき用語について説明します。

リソースグループ

各リソースグループは、特定の BE からの計算リソースのセットです。クラスターの各 BE を複数のリソースグループに分割できます。クエリがリソースグループに割り当てられると、StarRocks は指定されたリソースクォータに基づいてリソースグループに CPU とメモリリソースを割り当てます。

BE 上のリソースグループに対して CPU とメモリのリソースクォータを指定するには、次のパラメータを使用します:

パラメータ説明値の範囲デフォルト
cpu_weightBE ノード上のこのリソースグループの CPU スケジューリング重み。(0, avg_be_cpu_cores] (0 より大きい場合に有効)0
exclusive_cpu_coresこのリソースグループの CPU ハード隔離パラメータ。(0, min_be_cpu_cores - 1] (0 より大きい場合に有効)0
mem_limit現在の BE ノード上でこのリソースグループがクエリに利用できるメモリの割合。(0, 1] (必須)-
spill_mem_limit_thresholdディスクへのスピリングをトリガーするメモリ使用量のしきい値。(0, 1]1.0
concurrency_limitこのリソースグループ内の同時クエリの最大数。整数 (0 より大きい場合に有効)0
big_query_cpu_second_limit各 BE ノードでの大規模クエリタスクの最大 CPU 時間(秒)。整数 (0 より大きい場合に有効)0
big_query_scan_rows_limit各 BE ノードで大規模クエリタスクがスキャンできる最大行数。整数 (0 より大きい場合に有効)0
big_query_mem_limit各 BE ノードで大規模クエリタスクが使用できる最大メモリ。整数 (0 より大きい場合に有効)0

CPU リソースパラメータ

cpu_weight

このパラメータは、単一の BE ノード上のリソースグループの CPU スケジューリング重みを指定し、このグループからのタスクに割り当てられる CPU 時間の相対的なシェアを決定します。v3.3.5 より前は、cpu_core_limit と呼ばれていました。

その値の範囲は (0, avg_be_cpu_cores] で、avg_be_cpu_cores はすべての BE ノードにおける CPU コアの平均数です。このパラメータは 0 より大きい場合にのみ有効です。cpu_weight または exclusive_cpu_cores のいずれかが 0 より大きくなければなりませんが、両方ではありません。

注意

例えば、3 つのリソースグループ rg1、rg2、rg3 がそれぞれ cpu_weight 値 2、6、8 を持っているとします。完全に負荷がかかった BE ノードでは、これらのグループはそれぞれ 12.5%、37.5%、50% の CPU 時間を受け取ります。ノードが完全に負荷がかかっていない場合、rg1 と rg2 が負荷を受けている間、rg3 がアイドル状態であると、rg1 と rg2 はそれぞれ 25% と 75% の CPU 時間を受け取ります。

exclusive_cpu_cores

このパラメータは、リソースグループの CPU ハードリミットを定義します。これには 2 つの意味があります:

  • 専用: exclusive_cpu_cores CPU コアをこのリソースグループ専用に予約し、アイドル状態でも他のグループには利用できません。
  • クォータ: このリソースグループがこれらの予約された CPU コアのみを使用するように制限し、他のグループから利用可能な CPU リソースを使用できないようにします。

値の範囲は (0, min_be_cpu_cores - 1] で、min_be_cpu_cores はすべての BE ノードにおける CPU コアの最小数です。0 より大きい場合にのみ有効です。cpu_weight または exclusive_cpu_cores のいずれかのみが 0 より大きく設定できます。

  • exclusive_cpu_cores が 0 より大きいリソースグループは専用リソースグループと呼ばれ、それに割り当てられた CPU コアは専用コアと呼ばれます。他のグループは共有リソースグループと呼ばれ、共有コアで実行されます。
  • すべてのリソースグループにおける exclusive_cpu_cores の合計数は min_be_cpu_cores - 1 を超えてはなりません。上限は、少なくとも 1 つの共有コアを利用可能にするために設定されています。

exclusive_cpu_corescpu_weight の関係:

cpu_weight または exclusive_cpu_cores のいずれか一方のみが一度にアクティブにできます。専用リソースグループは、cpu_weight を介して CPU 時間のシェアを要求することなく、独自の予約された専用コアで動作します。

共有リソースグループが専用リソースグループから専用コアを借用できるかどうかを BE 設定 enable_resource_group_cpu_borrowing を使用して設定できます。デフォルトでは true に設定されており、専用グループがアイドル状態のときに共有グループが CPU リソースを借用できます。

この設定を動的に変更するには、次のコマンドを使用します:

UPDATE information_schema.be_configs SET VALUE = "false" WHERE NAME = "enable_resource_group_cpu_borrowing";

メモリリソースパラメータ

mem_limit

現在の BE ノードでリソースグループが利用できるメモリ(クエリプール)の割合を指定します。値の範囲は (0,1] です。

spill_mem_limit_threshold

ディスクへのスピリングをトリガーするメモリ使用量のしきい値を定義します。値の範囲は (0,1] で、デフォルトは 1(非アクティブ)です。v3.1.7 で導入されました。

  • 自動スピリングが有効(spill_modeauto に設定)で、リソースグループが無効な場合、クエリのメモリ使用量が query_mem_limit の 80% を超えると、システムは中間結果をディスクにスピルします。
  • リソースグループが有効な場合、次の条件でスピリングが発生します:
    • グループ内のすべてのクエリのメモリ使用量の合計が current BE memory limit * mem_limit * spill_mem_limit_threshold を超える場合、または
    • 現在のクエリのメモリ使用量が query_mem_limit の 80% を超える場合。

クエリ同時実行パラメータ

concurrency_limit

システムの過負荷を防ぐために、リソースグループ内の同時クエリの最大数を定義します。0 より大きい場合にのみ有効で、デフォルト値は 0 です。

大規模クエリリソースパラメータ

大規模クエリに対して特定のリソース制限を設定するには、次のパラメータを使用します:

big_query_cpu_second_limit

各 BE ノードで大規模クエリタスクが使用できる最大 CPU 時間(秒)を指定します。並列タスクによって使用された実際の CPU 時間の合計です。0 より大きい場合にのみ有効で、デフォルト値は 0 です。

big_query_scan_rows_limit

各 BE ノードで大規模クエリタスクがスキャンできる行数の制限を設定します。0 より大きい場合にのみ有効で、デフォルト値は 0 です。

big_query_mem_limit

各 BE ノードで大規模クエリタスクが使用できる最大メモリをバイト単位で定義します。0 より大きい場合にのみ有効で、デフォルト値は 0 です。

注意

リソースグループ内で実行されているクエリが上記の大規模クエリ制限を超えた場合、クエリはエラーで終了します。エラーメッセージは FE ノードの fe.audit.logErrorCode 列でも確認できます。

タイプ(v3.3.5 以降廃止)

v3.3.5 より前は、StarRocks はリソースグループの typeshort_query に設定することを許可していました。ただし、パラメータ type は廃止され、exclusive_cpu_cores に置き換えられました。このタイプの既存のリソースグループについては、システムは v3.3.5 にアップグレード後に exclusive_cpu_cores 値が cpu_weight に等しい専用リソースグループに自動的に変換します。

システム定義のリソースグループ

各 StarRocks インスタンスには、default_wgdefault_mv_wg の 2 つのシステム定義リソースグループがあります。システム定義のリソースグループの構成を ALTER RESOURCE GROUP コマンドを使用して変更できますが、クラシファイアを定義したり、システム定義のリソースグループを削除したりすることはできません。

default_wg

default_wg は、リソースグループの管理下にあるが、クラシファイアに一致しない通常のクエリに割り当てられます。default_wg のデフォルトのリソース制限は次のとおりです:

  • cpu_core_limit: 1(v2.3.7 以前の場合)または BE の CPU コア数(v2.3.7 より後のバージョンの場合)。
  • mem_limit: 100%。
  • concurrency_limit: 0。
  • big_query_cpu_second_limit: 0。
  • big_query_scan_rows_limit: 0。
  • big_query_mem_limit: 0。
  • spill_mem_limit_threshold: 1。
default_mv_wg

default_mv_wg は、マテリアライズドビュー作成時にプロパティ resource_group にリソースグループが割り当てられていない場合、非同期マテリアライズドビューのリフレッシュタスクに割り当てられます。default_mv_wg のデフォルトのリソース制限は次のとおりです:

  • cpu_core_limit: 1。
  • mem_limit: 80%。
  • concurrency_limit: 0。
  • spill_mem_limit_threshold: 80%。

クラシファイア(分類器)

各クラシファイアは、クエリのプロパティに一致する 1 つ以上の条件を保持します。StarRocks は、各クエリに最も一致するクラシファイアを条件に基づいて特定し、クエリの実行に必要なリソースを割り当てます。

クラシファイアは次の条件をサポートします:

  • user: ユーザーの名前。
  • role: ユーザーの役割。
  • query_type: クエリのタイプ。SELECTINSERT(v2.5 からサポート)がサポートされています。INSERT INTO または BROKER LOAD タスクが query_typeinsert として持つリソースグループにヒットすると、BE ノードはタスクのために指定された CPU リソースを予約します。
  • source_ip: クエリが開始された CIDR ブロック。
  • db: クエリがアクセスするデータベース。カンマ , で区切られた文字列で指定できます。
  • plan_cpu_cost_range: クエリの推定 CPU コスト範囲。形式は (DOUBLE, DOUBLE] です。デフォルト値は NULL で、そのような制限がないことを示します。fe.audit.logPlanCpuCost 列は、クエリの CPU コストに対するシステムの推定値を表します。このパラメータは v3.1.4 以降でサポートされています。
  • plan_mem_cost_range: クエリのシステム推定メモリコスト範囲。形式は (DOUBLE, DOUBLE] です。デフォルト値は NULL で、そのような制限がないことを示します。fe.audit.logPlanMemCost 列は、クエリのメモリコストに対するシステムの推定値を表します。このパラメータは v3.1.4 以降でサポートされています。

クラシファイアは、クラシファイアの条件の 1 つまたはすべてがクエリの情報と一致する場合にのみクエリに一致します。複数のクラシファイアがクエリに一致する場合、StarRocks はクエリと各クラシファイアの一致度を計算し、一致度が最も高いクラシファイアを特定します。

注意

クエリが属するリソースグループは、FE ノードの fe.audit.logResourceGroup 列で確認するか、クエリのリソースグループを表示する で説明されているように EXPLAIN VERBOSE <query> を実行して確認できます。

StarRocks は、クエリとクラシファイアの一致度を次のルールを使用して計算します:

  • クラシファイアがクエリと同じ user 値を持つ場合、クラシファイアの一致度は 1 増加します。
  • クラシファイアがクエリと同じ role 値を持つ場合、クラシファイアの一致度は 1 増加します。
  • クラシファイアがクエリと同じ query_type 値を持つ場合、クラシファイアの一致度は 1 増加し、次の計算から得られる数値も加算されます:1/クラシファイア内の query_type フィールドの数。
  • クラシファイアがクエリと同じ source_ip 値を持つ場合、クラシファイアの一致度は 1 増加し、次の計算から得られる数値も加算されます:(32 - cidr_prefix)/64。
  • クラシファイアがクエリと同じ db 値を持つ場合、クラシファイアの一致度は 10 増加します。
  • クエリの CPU コストが plan_cpu_cost_range 内に収まる場合、クラシファイアの一致度は 1 増加します。
  • クエリのメモリコストが plan_mem_cost_range 内に収まる場合、クラシファイアの一致度は 1 増加します。

複数のクラシファイアがクエリに一致する場合、条件の数が多いクラシファイアがより高い一致度を持ちます。

-- クラシファイア B はクラシファイア A よりも多くの条件を持っています。したがって、クラシファイア B はクラシファイア A よりも高い一致度を持ちます。

クラシファイア A (user='Alice')

クラシファイア B (user='Alice', source_ip = '192.168.1.0/24')

複数の一致するクラシファイアが同じ条件数を持つ場合、条件がより正確に記述されているクラシファイアがより高い一致度を持ちます。

-- クラシファイア B に指定された CIDR ブロックは、クラシファイア A よりも範囲が小さいです。したがって、クラシファイア B はクラシファイア A よりも高い一致度を持ちます。
クラシファイア A (user='Alice', source_ip = '192.168.1.0/16')
クラシファイア B (user='Alice', source_ip = '192.168.1.0/24')

-- クラシファイア C はクラシファイア D よりも指定されたクエリタイプが少ないです。したがって、クラシファイア C はクラシファイア D よりも高い一致度を持ちます。
クラシファイア C (user='Alice', query_type in ('select'))
クラシファイア D (user='Alice', query_type in ('insert','select'))

複数のクラシファイアが同じ一致度を持つ場合、クラシファイアのうちの 1 つがランダムに選択されます。

-- クエリが同時に db1 と db2 をクエリし、クラシファイア E と F がヒットしたクラシファイアの中で最も高い一致度を持つ場合、E と F のいずれかがランダムに選択されます。
クラシファイア E (db='db1')
クラシファイア F (db='db2')

計算リソースの分離

リソースグループとクラシファイアを設定することで、クエリ間の計算リソースを分離できます。

リソースグループの有効化

リソースグループを使用するには、StarRocks クラスターで Pipeline Engine を有効にする必要があります:

-- 現在のセッションで Pipeline Engine を有効にします。
SET enable_pipeline_engine = true;
-- グローバルに Pipeline Engine を有効にします。
SET GLOBAL enable_pipeline_engine = true;

注意

v3.1.0 以降、リソースグループはデフォルトで有効になっており、セッション変数 enable_resource_group は廃止されました。

リソースグループとクラシファイアの作成

次のステートメントを実行して、リソースグループを作成し、クラシファイアと関連付け、リソースグループに計算リソースを割り当てます:

CREATE RESOURCE GROUP <group_name> 
TO (
user='string',
role='string',
query_type in ('select'),
source_ip='cidr'
) --クラシファイアを作成します。複数のクラシファイアを作成する場合は、クラシファイアをカンマ(`,`)で区切ります。
WITH (
"{ cpu_weight | exclusive_cpu_cores }" = "INT",
"mem_limit" = "m%",
"concurrency_limit" = "INT",
"type" = "str" --リソースグループのタイプ。値を normal に設定します。
);

例:

CREATE RESOURCE GROUP rg1
TO
(user='rg1_user1', role='rg1_role1', query_type in ('select'), source_ip='192.168.x.x/24'),
(user='rg1_user2', query_type in ('select'), source_ip='192.168.x.x/24'),
(user='rg1_user3', source_ip='192.168.x.x/24'),
(user='rg1_user4'),
(db='db1')
WITH (
'exclusive_cpu_cores' = '10',
'mem_limit' = '20%',
'big_query_cpu_second_limit' = '100',
'big_query_scan_rows_limit' = '100000',
'big_query_mem_limit' = '1073741824'
);

リソースグループの指定(オプション)

現在のセッションに対して、default_wgdefault_mv_wg を含むリソースグループを直接指定できます。

SET resource_group = 'group_name';

リソースグループとクラシファイアの表示

次のステートメントを実行して、すべてのリソースグループとクラシファイアをクエリします:

SHOW RESOURCE GROUPS ALL;

次のステートメントを実行して、ログインしているユーザーのリソースグループとクラシファイアをクエリします:

SHOW RESOURCE GROUPS;

次のステートメントを実行して、指定されたリソースグループとそのクラシファイアをクエリします:

SHOW RESOURCE GROUP group_name;

例:

mysql> SHOW RESOURCE GROUPS ALL;
+---------------+-------+------------+---------------------+-----------+----------------------------+---------------------------+---------------------+-------------------+---------------------------+----------------------------------------+
| name | id | cpu_weight | exclusive_cpu_cores | mem_limit | big_query_cpu_second_limit | big_query_scan_rows_limit | big_query_mem_limit | concurrency_limit | spill_mem_limit_threshold | classifiers |
+---------------+-------+------------+---------------------+-----------+----------------------------+---------------------------+---------------------+-------------------+---------------------------+----------------------------------------+
| default_mv_wg | 3 | 1 | 0 | 80.0% | 0 | 0 | 0 | null | 80% | (id=0, weight=0.0) |
| default_wg | 2 | 1 | 0 | 100.0% | 0 | 0 | 0 | null | 100% | (id=0, weight=0.0) |
| rge1 | 15015 | 0 | 6 | 90.0% | 0 | 0 | 0 | null | 100% | (id=15016, weight=1.0, user=rg1_user) |
| rgs1 | 15017 | 8 | 0 | 90.0% | 0 | 0 | 0 | null | 100% | (id=15018, weight=1.0, user=rgs1_user) |
| rgs2 | 15019 | 8 | 0 | 90.0% | 0 | 0 | 0 | null | 100% | (id=15020, weight=1.0, user=rgs2_user) |
+---------------+-------+------------+---------------------+-----------+----------------------------+---------------------------+---------------------+-------------------+---------------------------+----------------------------------------+

注意

上記の例では、weight は一致度を示します。

リソースグループのすべてのフィールドをクエリするには、廃止されたフィールドを含めて、上記の 3 つのコマンドに VERBOSE キーワードを追加することで、typemax_cpu_cores などの廃止されたフィールドを含むすべてのフィールドを表示できます。

SHOW VERBOSE RESOURCE GROUPS ALL;
SHOW VERBOSE RESOURCE GROUPS;
SHOW VERBOSE RESOURCE GROUP group_name;

リソースグループとクラシファイアの管理

各リソースグループのリソースクォータを変更できます。また、リソースグループからクラシファイアを追加または削除できます。

既存のリソースグループのリソースクォータを変更するには、次のステートメントを実行します:

ALTER RESOURCE GROUP group_name WITH (
'cpu_core_limit' = 'INT',
'mem_limit' = 'm%'
);

リソースグループを削除するには、次のステートメントを実行します:

DROP RESOURCE GROUP group_name;

リソースグループにクラシファイアを追加するには、次のステートメントを実行します:

ALTER RESOURCE GROUP <group_name> ADD (user='string', role='string', query_type in ('select'), source_ip='cidr');

リソースグループからクラシファイアを削除するには、次のステートメントを実行します:

ALTER RESOURCE GROUP <group_name> DROP (CLASSIFIER_ID_1, CLASSIFIER_ID_2, ...);

リソースグループのすべてのクラシファイアを削除するには、次のステートメントを実行します:

ALTER RESOURCE GROUP <group_name> DROP ALL;

リソースグループの観察

クエリのリソースグループを表示する

まだ実行されていないクエリについては、EXPLAIN VERBOSE <query> によって返される RESOURCE GROUP フィールドからクエリに一致するリソースグループを表示できます。

クエリが実行中の場合、SHOW PROC '/current_queries' および SHOW PROC '/global_current_queries' によって返される ResourceGroup フィールドからクエリがヒットしたリソースグループを確認できます。

クエリが完了した後、FE ノードの fe.audit.log ファイルの ResourceGroup フィールドを確認することで、クエリが一致したリソースグループを表示できます。

  • クエリがリソースグループの管理下にない場合、列の値は空の文字列 "" です。
  • クエリがリソースグループの管理下にあるが、クラシファイアに一致しない場合、列の値は空の文字列 "" です。ただし、このクエリはデフォルトのリソースグループ default_wg に割り当てられます。

リソースグループの監視

リソースグループの監視とアラートを設定できます。

リソースグループ関連の FE および BE メトリクスは次のとおりです。以下のすべてのメトリクスには、対応するリソースグループを示す name ラベルがあります。

FE メトリクス

次の FE メトリクスは、現在の FE ノード内の統計のみを提供します:

メトリクス単位タイプ説明
starrocks_fe_query_resource_groupCount瞬時値このリソースグループで歴史的に実行されたクエリの数(現在実行中のものを含む)。
starrocks_fe_query_resource_group_latencyms瞬時値このリソースグループのクエリ遅延パーセンタイル。ラベル type は、mean75_quantile95_quantile98_quantile99_quantile999_quantile を含む特定のパーセンタイルを示します。
starrocks_fe_query_resource_group_errCount瞬時値このリソースグループでエラーが発生したクエリの数。
starrocks_fe_resource_group_query_queue_totalCount瞬時値このリソースグループで歴史的にキューに入れられたクエリの総数(現在実行中のものを含む)。このメトリクスは v3.1.4 以降でサポートされています。クエリキューが有効な場合にのみ有効です。
starrocks_fe_resource_group_query_queue_pendingCount瞬時値このリソースグループのキューに現在あるクエリの数。このメトリクスは v3.1.4 以降でサポートされています。クエリキューが有効な場合にのみ有効です。
starrocks_fe_resource_group_query_queue_timeoutCount瞬時値このリソースグループでキューに入れられている間にタイムアウトしたクエリの数。このメトリクスは v3.1.4 以降でサポートされています。クエリキューが有効な場合にのみ有効です。

BE メトリクス

メトリクス単位タイプ説明
resource_group_running_queriesCount瞬時値このリソースグループで現在実行中のクエリの数。
resource_group_total_queriesCount瞬時値このリソースグループで歴史的に実行されたクエリの数(現在実行中のものを含む)。
resource_group_bigquery_countCount瞬時値このリソースグループで大規模クエリ制限をトリガーしたクエリの数。
resource_group_concurrency_overflow_countCount瞬時値このリソースグループで concurrency_limit 制限をトリガーしたクエリの数。
resource_group_mem_limit_bytesBytes瞬時値このリソースグループのメモリ制限。
resource_group_mem_inuse_bytesBytes瞬時値このリソースグループで現在使用中のメモリ。
resource_group_cpu_limit_ratioPercentage瞬時値このリソースグループの cpu_core_limit がすべてのリソースグループの合計 cpu_core_limit に対する割合。
resource_group_inuse_cpu_coresCount平均このリソースグループで使用中の CPU コアの推定数。この値はおおよその推定値です。これは、2 回の連続したメトリック収集からの統計に基づいて計算された平均値を表します。このメトリクスは v3.1.4 以降でサポートされています。
resource_group_cpu_use_ratioPercentage平均廃止 このリソースグループが使用した Pipeline スレッドタイムスライスの割合が、すべてのリソースグループで使用された Pipeline スレッドタイムスライスの合計に対する割合。これは、2 回の連続したメトリック収集からの統計に基づいて計算された平均値を表します。
resource_group_connector_scan_use_ratioPercentage平均廃止 このリソースグループが使用した外部テーブルスキャンスレッドタイムスライスの割合が、すべてのリソースグループで使用された Pipeline スレッドタイムスライスの合計に対する割合。これは、2 回の連続したメトリック収集からの統計に基づいて計算された平均値を表します。
resource_group_scan_use_ratioPercentage平均廃止 このリソースグループが使用した内部テーブルスキャンスレッドタイムスライスの割合が、すべてのリソースグループで使用された Pipeline スレッドタイムスライスの合計に対する割合。これは、2 回の連続したメトリック収集からの統計に基づいて計算された平均値を表します。

リソースグループ使用情報の表示

v3.1.4 以降、StarRocks は SQL ステートメント SHOW USAGE RESOURCE GROUPS をサポートしており、BE 全体で各リソースグループの使用情報を表示するために使用されます。各フィールドの説明は次のとおりです:

  • Name: リソースグループの名前。
  • Id: リソースグループの ID。
  • Backend: BE の IP または FQDN。
  • BEInUseCpuCores: この BE でこのリソースグループが現在使用している CPU コアの数。この値はおおよその推定値です。
  • BEInUseMemBytes: この BE でこのリソースグループが現在使用しているメモリバイト数。
  • BERunningQueries: この BE でこのリソースグループからのクエリがまだ実行中の数。

注意事項:

  • BE は report_resource_usage_interval_ms で指定された間隔で、このリソース使用情報を Leader FE に定期的に報告します。デフォルトでは 1 秒に設定されています。
  • 結果には、BEInUseCpuCores/BEInUseMemBytes/BERunningQueries のいずれかが正の数である行のみが表示されます。つまり、リソースグループが BE でアクティブにリソースを使用している場合にのみ情報が表示されます。

例:

MySQL [(none)]> SHOW USAGE RESOURCE GROUPS;
+------------+----+-----------+-----------------+-----------------+------------------+
| Name | Id | Backend | BEInUseCpuCores | BEInUseMemBytes | BERunningQueries |
+------------+----+-----------+-----------------+-----------------+------------------+
| default_wg | 0 | 127.0.0.1 | 0.100 | 1 | 5 |
+------------+----+-----------+-----------------+-----------------+------------------+
| default_wg | 0 | 127.0.0.2 | 0.200 | 2 | 6 |
+------------+----+-----------+-----------------+-----------------+------------------+
| wg1 | 0 | 127.0.0.1 | 0.300 | 3 | 7 |
+------------+----+-----------+-----------------+-----------------+------------------+
| wg2 | 0 | 127.0.0.1 | 0.400 | 4 | 8 |
+------------+----+-----------+-----------------+-----------------+------------------+

専用および共有リソースグループのスレッド情報の表示

クエリの実行には主に 3 つのスレッドプールが関与します:pip_execpip_scan、および pip_con_scan

  • 専用リソースグループは、専用のスレッドプールで実行され、それに割り当てられた専用 CPU コアにバインドされます。
  • 共有リソースグループは、共有スレッドプールで実行され、残りの共有 CPU コアにバインドされます。

これらの 3 つのプールのスレッドは、{ pip_exec | pip_scan | pip_con_scan }_{ com | <resource_group_id> } という命名規則に従います。ここで、com は共有スレッドプールを指し、<resource_group_id> は専用リソースグループの ID を指します。

各 BE スレッドにバインドされた CPU 情報は、システム定義ビュー information_schema.be_threads を通じて表示できます。フィールド BE_IDNAME、および BOUND_CPUS は、それぞれ BE の ID、スレッドの名前、およびそのスレッドにバインドされた CPU コアの数を表します。

select * from information_schema.be_threads where name like '%pip_exec%';
select * from information_schema.be_threads where name like '%pip_scan%';
select * from information_schema.be_threads where name like '%pip_con_scan%';

例:

select BE_ID, NAME, FINISHED_TASKS, BOUND_CPUS from information_schema.be_threads where name like '%pip_exec_com%' and be_id = 10223;
+-------+--------------+----------------+------------+
| BE_ID | NAME | FINISHED_TASKS | BOUND_CPUS |
+-------+--------------+----------------+------------+
| 10223 | pip_exec_com | 2091295 | 10 |
| 10223 | pip_exec_com | 2088025 | 10 |
| 10223 | pip_exec_com | 1637603 | 6 |
| 10223 | pip_exec_com | 1641260 | 6 |
| 10223 | pip_exec_com | 1634197 | 6 |
| 10223 | pip_exec_com | 1633804 | 6 |
| 10223 | pip_exec_com | 1638184 | 6 |
| 10223 | pip_exec_com | 1636374 | 6 |
| 10223 | pip_exec_com | 2095951 | 10 |
| 10223 | pip_exec_com | 2095248 | 10 |
| 10223 | pip_exec_com | 2098745 | 10 |
| 10223 | pip_exec_com | 2085338 | 10 |
| 10223 | pip_exec_com | 2101221 | 10 |
| 10223 | pip_exec_com | 2093901 | 10 |
| 10223 | pip_exec_com | 2092364 | 10 |
| 10223 | pip_exec_com | 2091366 | 10 |
+-------+--------------+----------------+------------+