USER MANUALS

プランの定義

Resource Manager を有効にしたら、1 つまたは複数のプランを作成し、その後でそれらのプランにリンクする 1 つまたは複数のルールを作成する必要があります。

プランを定義するには、以下の手順に従って実施してください。

  1. [Plans] タブをクリックします。

  2. [New] をクリックしてプランを作成します。[Create plan] ダイアログで、プランの名前と、必要に応じてその説明を入力します。

Resource Manager: creating a new plan

Resource Manager: 新しいプランの作成

  1. [New restriction] をクリックします。このダイアログで、以下の 2 つを選択します。

    1. Execute when: プランを有効にするタイミングを選択します。以下のオプションがあります。

      1. 常に(Always): 常に有効。

      2. 指定期間中に平均CPU使用量が指定した値以上である場合。この制限は、クエリ開始時と 20 秒ごとに評価されます。たとえば、直前の 30 秒間にサーバーの CPU が非常に高かった場合に、優先度の低いクエリを停止するプランを作成できます。

        最大値: 3600 (秒)。

      重要

      Virtual DataPort では直前の 1 時間の CPU 使用履歴を保存するため、Resource Manager のプランで指定できる最大時間帯は 3600 秒になります。

    1. 上記の条件が満たされた場合に Resource Manager が実行するアクションを選択します。選択したアクションは、 SELECT ステートメントまたは CALL ステートメントに適用され、DDL (CREATE VIEWCREATE REST WEBSERVICE など) または DML (INSERTUPDATE など) には適用されません。

      • Stop query always: ただちにクエリを停止します。

      • Switch query to plan: クエリを別のプランに移動します。

注釈

Switch query to plan アクションは廃止されていて、Denodo Platform の将来のメジャーバージョンで削除されます。

非推奨のすべての機能のリストについては、「 Denodo Platform 8.0 で非推奨となった機能 」を参照してください。

  • Stop query when the maximum execution time has been reached: 最大実行時間に到達するとクエリを停止します。

  • Stop query when the maximum number of returned rows has been reached: 返される行数が最大に到達するとクエリを停止します。

  • 指定した過去の一定期間中にサーバの平均 CPU 使用率が閾値以上になると現在実施中のクエリを直ちに停止します。たとえば、現在のクエリを実施開始後、直前の 60 秒で平均で 90% 超の CPU を使用した場合、当該クエリを停止します。

  • Stop query when the estimated cost condition has been reached: 推定コスト条件に達するとクエリを停止します。クエリを停止するかどうかを決定する条件は、以下の統計に基づきます。

    • total_query_cost: オプティマイザーが選択した実行プランの推定コストの合計。

    • total_datasource_cost: 実行プランに関連するすべてのデータソースの見積もりコストの合計。

    • average_datasource_cost: 実行プランに関連するすべてのデータソースの見積もりコストの平均。

    • any_datasource_cost: 実行プランに関連する任意のデータソースのコスト。

    • any_datasource_provider: プランに含まれる任意のデータソースのプロバイダー。

    • any_datasource_region: プランに含まれる任意のデータソースのリージョン。

    重要

    コスト予測は、実行する個々のクエリやクエリの実行環境に固有の多くの要因によって変化します。一般的に、2 種類のクエリの予測値を比較するとき、コスト予測が低い方のクエリは実行時間が短いと仮定しないようにします。そのため、このアクションでプランを作成する場合、コスト値の取得で参照として使用したクエリとよく似たクエリにのみ適用されるようにルールを設定します。

    以下に例を示します。

    • 「実行プランのコストが 100000 を超える場合にクエリを停止する。」 - total_query_cost > 100000

    • 「実行プランのコストが 100000 を超えるか、データソースの平均コストが 25000 を超える場合にクエリを停止する。」 - total_query_cost > 100000 OR average_datasource_cost > 25000

    • 「関連する任意のデータソースの推定コストが 25000 を超える場合にクエリを停止する。」 - any_datasource_cost > 25000

    • 「Azure または Google Cloud Platform の任意のデータソースを使用する場合はクエリを停止する。」 - any_datasource_provider IN ('Azure', 'Google Cloud Platform')

    • 「オーストラリアのリージョンの Azure、または任意のリージョンの Amazon Web Services から任意のデータソースを使用する場合はクエリを停止する。」 - (any_datasource_provider = 'Azure' AND any_datasource_region = 'australiacentral / Australia Central' ) OR (any_datasource_provider = 'Amazon Web Services')

  • Limit the maximum memory that can be used by the query: クエリで使用できる最大メモリを制限します。クエリの実行中にこの制限に達すると、クエリは停止します。

  • Set the priority of the threads that execute the query: Virtual DataPort サーバーがクエリを実行するために起動するスレッドの優先順位を変更します。1 は最も低い優先順位、10 は最も高い優先順位です。

    スレッドの優先順位を上げると、クエリの実行が速くなります。

    重要

    Virtual DataPort サーバーが Linux 上で動作している場合、このアクションが適用されるのは以下の 2 つの条件が満たされた場合のみです。

    1. Virtual DataPort が root 権限 (root ユーザーアカウントまたは sudo ./vqlserver_startup.sh) で起動する。

    2. Virtual DataPort サーバーの [JVM options] に -XX:ThreadPriorityPolicy=1 が追加されている。

    これらの条件を満たす必要があるのは、Linux では root ユーザーによって起動されたプロセスのみがそのスレッドの優先順位を動的に変更できるからです。

    この注意事項は、Windows 上で動作する Virtual DataPort サーバーには影響しません。なぜなら、Windows では、プロセスがそれ自体のスレッドの優先順位を変更できるからです。

  • Set the maximum number of concurrent queries: ルールの条件を満たすユーザーのグループが実行する同時クエリの最大数を設定します (ルールについては次のセクションを参照)。

    たとえば、「access_interface=JDBC」という条件を使用するルールを作成して、同時クエリの最大数を 30 に制限するプランをこのルールに割り当てたとします。35 個の JDBC クライアントが同時にクエリを実行して、それらがルールリストの上位にある別のルールの条件を満たさない場合、サーバーは 30 個のクエリのみ同時に実行して、残りのクエリをキューに追加します。

    このアクションの値より、[Server Configuration] ダイアログで設定されている同時クエリの最大数の方が優先されます。

    CPU の値を条件とするプラン制限でこのアクションを使用する場合、CPU 条件が真と評価され、アクションが実行されると、そのプランに割り当てられたすべてのクエリに対して同時実行数が設定され、CPU がそのしきい値を下回る場合でも自動的にリセットされないことに注意してください。同時実行数のリセットを行う、CPU しきい値が異なる制限を別に設定する必要があります。たとえば、すべてのクエリにプラン「adjustConcurrency」を割り当てるルールを作成し、このプランに制限「直前の 30 秒で 90% 超の CPU を使用した場合、同時実行数を 20 に制限する」を定義するとします。クエリを実行すると、プラン条件が評価されます。CPU 条件が真であるため、Resource Manager ではプラン「adjustConcurrency」の同時実行数を 20 に設定します。つまり、CPU が 90% を下回る場合でも、すべてのクエリがそのプランに属しているため、どのクエリも同時リクエスト数の制限である 20 を下回ることになります。CPU に基づいて同時実行数を正しく調整するには、同じプランで 2 つの制限を使用します。例: CPU が 0% を超える場合に同時実行数をゼロ (無制限) に設定する制限と、直前の 30 秒に CPU が 90% を超える場合に同時実行数を 20 (または任意の値) に設定する制限。

  • 1 ユーザあたりの最大同時クエリ数を設定する前述の制限と同様、同じユーザーのクエリのみをカウントします。

    たとえば、"access_interface=JDBC " という条件のルールを作成し、ユーザーあたりの最大同時クエリ数を 15 に制限するプランを割り当てるとします。2 人の異なるユーザーが JDBC から同時にそれぞれ 20 のクエリを実行する場合、一方のユーザーの 15 のクエリ、もう一方のユーザーの 15 のクエリで、サーバーは同時に 30 のクエリを実行します。それ以外のクエリはキューに入れられます。

    CPU に基づく条件の制限で使用する場合は、上記で説明した内容がここでも当てはまります。そのため、CPU がしきい値を下回る場合に同時実行数のレベルを修復する制限を追加で使用する必要があることに注意してください。

  • Set the maximum number of queued queries: ルールの条件を満たすユーザーのグループが実行する、キュー内のクエリの最大数を設定します。

    このアクションの値より、[Server Configuration] ダイアログで設定されているキュー内のクエリの最大数の方が優先されます。

    CPU 使用率のレベルに基づく同時実行数の制限に関する上記の説明は、このアクションにも当てはまります。そのため、CPU がしきい値を下回るときにキューに入れるクエリの最大数を修復する制限を追加で使用する必要があることに注意してください。

  • Set automatic simplification of the query to: このクエリの自動簡素化を有効/無効にします。クエリの自動簡素化のプロセスについては、「 クエリの自動簡素化 」を参照してください。

  • Set the maximum number of queries per time unit: ルールの条件を満たすユーザーのグループが実行する時間単位あたり (分あたり、時間あたり、日あたり、または月あたり) のクエリの最大数を設定します。このアクションは、[Execute when] オプションが [Always] の場合のみ使用できます。

  • Add variable values to the execution context: 実行コンテキストに変数値を追加します。[Add] または [Remove] をクリックして、変数名と変数値のペアを追加または削除します。変数値を定義するには、テキスト値にキャストできる任意の式を使用できます。この式では、Resource Manager のルールと同じフィールドセットを使用できます。付録「 Resource Manager: ルールの評価に使用できるフィールド 」には、これらの式で使用できるすべてのフィールドが記載されています。

    このプランが実行中のクエリに適用される場合、ここで定義された変数は実行コンテキストで利用できます。変数値は、以下で読み込むことができます。

  1. [Ok] をクリックして制限を保存し、もう 1 回クリックしてプランを保存します。

プランを 1 つ作成して、複数の制限を設定することができます。以下に例を示します。

  • CPU 使用率が 50% を超える場合にトリガされる制限

  • CPU 使用率が 80% を超える場合にトリガされる制限

Add feedback