メインコンテンツまでスキップ

Monitor and manage big queries

大規模なクエリの監視と管理

このトピックでは、StarRocksクラスターにおいて大規模なクエリを監視および管理する方法について説明します。

大規模なクエリには、多数の行をスキャンするクエリやCPUおよびメモリリソースを占有するクエリが含まれます。これらのクエリは、制限がない場合にはクラスターリソースを消耗し、システムを過負荷にさせる可能性があります。この問題に対処するため、StarRocksでは大規模なクエリを監視および管理するための一連の手段を提供しており、クエリがクラスターリソースを独占することを防止しています。

StarRocksにおける大規模なクエリの処理の全体的な考え方は次のとおりです。

  1. リソースグループとクエリキューを使用して、大規模なクエリへの自動的な予防措置を設定します。
  2. 大規模なクエリをリアルタイムで監視し、予防措置をバイパスするクエリを終了します。
  3. オーディットログおよびBig Queryログを分析し、以前に設定した予防機構を微調整します。

この機能はv3.0以降でサポートされています。

大規模なクエリへの予防措置の設定​

StarRocksは、リソースグループとクエリキューの2つの予防ツールを提供しています。リソースグループを使用して大規模なクエリの実行を停止することができます。一方、クエリキューは、並行性の閾値またはリソース制限が達成されたときに、システムの過負荷を防ぐために、着信クエリをキューに入れるのに役立ちます。

リソースグループを使用して大規模なクエリをフィルタリング​

リソースグループを使用して、大規模なクエリを自動的に特定し、終了することができます。リソースグループを作成する際に、クエリに許可されるCPU時間、メモリ使用量、またはスキャン行数の上限を指定することができます。リソースグループにヒットするすべてのクエリのうち、より多くのリソースを必要とするクエリは拒否され、エラーが返されます。詳細については、リソース分離を参照してください。

リソースグループを作成する前に、リソースグループ機能に依存するパイプラインエンジンを有効にするため、以下のステートメントを実行する必要があります。

SET GLOBAL enable_pipeline_engine = true;

次の例では、CPU時間の上限を100秒、スキャン行数の上限を100000、メモリ使用量の上限を1073741824バイト（1GB）とするリソースグループbigQueryを作成しています。

CREATE RESOURCE GROUP bigQuery
TO 
    (db='sr_hub')
WITH (
    'cpu_core_limit' = '10',
    'mem_limit' = '20%',
    'big_query_cpu_second_limit' = '100',
    'big_query_scan_rows_limit' = '100000',
    'big_query_mem_limit' = '1073741824'
);

クエリの必要リソースがいずれかの制限を超える場合、クエリは実行されず、エラーが返されます。次の例は、クエリがスキャン行数の制限を超える場合に返されるエラーメッセージを示しています。

ERROR 1064 (HY000): exceed big query scan_rows limit: current is 4 but limit is 1

リソースグループの設定を初めて行う場合は、通常のクエリの実行を妨げないように比較的高い制限を設定することをお勧めします。大規模なクエリのパターンをよりよく把握した後でこれらの制限を微調整することができます。

クエリキューを使用してシステムの過負荷を緩和する​

クエリキューは、クラスターリソースの占有が事前に指定した閾値を超えるとき、システムの過負荷の悪化を緩和するために設計されています。最大の並行性、メモリ使用量、およびCPU使用量のための閾値を設定することができます。クエリキューは、これらのいずれかの閾値が達成されると、着信クエリを自動的にキューに入れます。保留中のクエリは、キュー内で実行を待機するか、指定したリソースの閾値が達成されるとキャンセルされます。詳細については、クエリキューを参照してください。

次のステートメントを実行して、SELECTクエリに対してクエリキューを有効にします。

SET GLOBAL enable_query_queue_select = true;

クエリキュー機能が有効になった後、クエリキューをトリガーするためのルールを定義できます。

  • クエリキューをトリガーするための並行性の閾値を指定します。次の例では、並行性の閾値を100に設定しています。

    SET GLOBAL query_queue_concurrency_limit = 100;

  • クエリキューをトリガーするためのメモリ使用率の閾値を指定します。次の例では、メモリ使用率の閾値を0.9に設定しています。

    SET GLOBAL query_queue_mem_used_pct_limit = 0.9;

  • クエリキューをトリガーするためのCPU使用率の閾値を指定します。次の例では、CPU使用率の閾値を800（CPU使用率×1000）に設定しています。

    SET GLOBAL query_queue_cpu_used_permille_limit = 800;

さらに、キュー内の各保留中のクエリの最大待機時間とキューの最大長を設定することで、これらのキュー内のクエリの処理方法を決定できます。

  • クエリキューの最大長を指定します。この閾値に達すると、着信クエリは拒否されます。次の例では、クエリキューの長さを100に設定しています。

    SET GLOBAL query_queue_max_queued_queries = 100;

  • キュー内の保留中のクエリの最大待機時間を指定します。この閾値に達すると、対応するクエリは拒否されます。次の例では、最大の待機時間を480秒に設定しています。

    SET GLOBAL query_queue_pending_timeout_second = 480;

クエリが保留中かどうかは、SHOW PROCESSLISTを使用して確認できます。

mysql> SHOW PROCESSLIST;
+------+------+---------------------+-------+---------+---------------------+------+-------+-------------------+-----------+
| Id   | User | Host                | Db    | Command | ConnectionStartTime | Time | State | Info              | IsPending |
+------+------+---------------------+-------+---------+---------------------+------+-------+-------------------+-----------+
|    2 | root | xxx.xx.xxx.xx:xxxxx |       | Query   | 2022-11-24 18:08:29 |    0 | OK    | SHOW PROCESSLIST  | false     |
+------+------+---------------------+-------+---------+---------------------+------+-------+-------------------+-----------+

IsPendingがtrueの場合、対応するクエリはクエリキューに保留中です。

リアルタイムで大規模なクエリを監視する​

v3.0以降、StarRocksでは、クラスターで現在処理中のクエリとそれが占有するリソースを表示することがサポートされています。これにより、大規模なクエリが予防機構をバイパスして予期しないシステムの過負荷を引き起こす場合に、クラスターを監視することができます。

MySQLクライアントを使用して監視する​

  1. SHOW PROCを使用して、現在処理中のクエリ（current_queries）を表示できます。

    SHOW PROC '/current_queries';

    StarRocksは、各クエリのクエリID（QueryId）、接続ID（ConnectionId）、およびクエリが占有するリソースの消費状況（スキャンデータのサイズ（ScanBytes）、処理済み行数（ProcessRows）、CPU時間（CPUCostSeconds）、メモリ使用量（MemoryUsageBytes）、実行時間（ExecTime））を返します。

    mysql> SHOW PROC '/current_queries';
    +--------------------------------------+--------------+------------+------+-----------+----------------+----------------+------------------+----------+
    | QueryId                              | ConnectionId | Database   | User | ScanBytes | ProcessRows    | CPUCostSeconds | MemoryUsageBytes | ExecTime |
    +--------------------------------------+--------------+------------+------+-----------+----------------+----------------+------------------+----------+
    | 7c56495f-ae8b-11ed-8ebf-00163e00accc | 4            | tpcds_100g | root | 37.88 MB  | 1075769 Rows   | 11.13 Seconds  | 146.70 MB        | 3804     |
    | 7d543160-ae8b-11ed-8ebf-00163e00accc | 6            | tpcds_100g | root | 13.02 GB  | 487873176 Rows | 81.23 Seconds  | 6.37 GB          | 2090     |
    +--------------------------------------+--------------+------------+------+-----------+----------------+----------------+------------------+----------+
    2 rows in set (0.01 sec)

  2. クエリIDを指定して、各BEノードでのクエリのリソース消費状況をさらに確認できます。

    SHOW PROC '/current_queries/<QueryId>/hosts';

    StarRocksは、各BEノードでのクエリのスキャンデータのサイズ（ScanBytes）、スキャン行数（ScanRows）、CPU時間（CPUCostSeconds）、およびメモリ使用量（MemUsageBytes）を返します。

    mysql> show proc '/current_queries/7c56495f-ae8b-11ed-8ebf-00163e00accc/hosts';
    +--------------------+-----------+-------------+----------------+---------------+
    | Host               | ScanBytes | ScanRows    | CpuCostSeconds | MemUsageBytes |
    +--------------------+-----------+-------------+----------------+---------------+
    | 172.26.34.185:8060 | 11.61 MB  | 356252 Rows | 52.93 Seconds  | 51.14 MB      |
    | 172.26.34.186:8060 | 14.66 MB  | 362646 Rows | 52.89 Seconds  | 50.44 MB      |
    | 172.26.34.187:8060 | 11.60 MB  | 356871 Rows | 52.91 Seconds  | 48.95 MB      |
    +--------------------+-----------+-------------+----------------+---------------+
    3 rows in set (0.00 sec)

FEコンソールを使用して監視する​

MySQLクライアントのほかにも、FEコンソールを使用して視覚化されたインタラクティブなモニタリングを行うこともできます。

  1. 次のURLを使用して、FEコンソールにブラウザでアクセスします。

    http://<fe_IP>:<fe_http_port>/system?path=//current_queries

    FE console 1
    システム情報ページで、現在処理中のクエリとそのリソース消費状況を表示できます。

  2. クエリのQueryIDをクリックします。

    FE console 2
    表示されるページで、ノードごとの詳細なリソース消費状況を確認できます。

手動で大規模なクエリを終了する​

予防措置が設定されたにもかかわらず、大規模なクエリがバイパスしてシステムの可用性に脅威を与える場合は、KILLステートメントで対応する接続IDを指定して、クエリを手動で終了することができます。

KILL QUERY <ConnectionId>;

大規模なクエリの分析​

v3.0以降、StarRocksはBig Query Logsをサポートしており、これはfe/log/fe.big_query.logというファイルに格納されます。StarRocksの監査ログと比較して、Big Query Logsは次の3つの追加フィールドを表示します。

  • bigQueryLogCPUSecondThreshold
  • bigQueryLogScanBytesThreshold
  • bigQueryLogScanRowsThreshold

これらの3つのフィールドは、クエリが大規模なクエリであるかどうかを決定するために定義したリソース消費の閾値に対応しています。

Big Query Logsを有効にするには、次のステートメントを実行します。

SET GLOBAL enable_big_query_log = true;

Big Query Logsが有効になった後、Big Query Logsをトリガーするためのルールを定義できます。

  • Big Query LogsをトリガーするためのCPU時間の閾値を指定します。次の例では、CPU時間の閾値を600秒に設定しています。

    SET GLOBAL big_query_log_cpu_second_threshold = 600;

  • Big Query Logsをトリガーするためのスキャンデータサイズの閾値を指定します。次の例では、スキャンデータサイズの閾値を10737418240バイト（10GB）に設定しています。

    SET GLOBAL big_query_log_scan_bytes_threshold = 10737418240;

  • Big Query Logsをトリガーするためのスキャン行数の閾値を指定します。次の例では、スキャン行数の閾値を1500000000に設定しています。

    SET GLOBAL big_query_log_scan_rows_threshold = 1500000000;

予防措置の微調整​

リアルタイムのモニタリングおよびBig Query Logsから得られる統計情報に基づいて、クラスターでバイパスされた大規模なクエリ（または誤って大規模なクエリと診断された通常のクエリ）のパターンを分析し、リソースグループおよびクエリキューの設定を最適化できます。

大規模なクエリの特定のSQLパターンが顕著になり、このSQLパターンを恒久的に禁止したい場合は、このパターンをSQLブラックリストに追加することができます。StarRocksは、SQLブラックリストで指定されたパターンに一致するすべてのクエリを拒否し、エラーを返します。詳細については、SQLブラックリストの管理を参照してください。

SQLブラックリストを有効にするには、次のステートメントを実行します。

ADMIN SET FRONTEND CONFIG ("enable_sql_blacklist" = "true");

その後、ADD SQLBLACKLISTを使用して、SQLパターンを表す正規表現をSQLブラックリストに追加できます。

次の例では、COUNT(DISTINCT)をSQLブラックリストに追加します。

ADD SQLBLACKLIST "SELECT COUNT(DISTINCT .+) FROM .+";