はじめに
利用者からの同時処理数が増え、アクセスが集中する時間帯は、急激に処理の実行時間が長くなることがあります。
本記事では、クエリの多重実行による性能劣化が発生した場合の、トラブルシューティングをご紹介します。
原因
性能劣化の原因は、CPUコア数を超えるクエリの同時実行が考えられます。
[メモリ割当ての動作]
※メモリ割当ての動作イメージは、以下のとおりです。
②CPUコア数を超えたクエリはメモリを割当てることができない。
③メモリ割当てができないQuery17は、キューで待機する。
④Query17は、実行中のQuery1が完了後にメモリが割当てられて、処理を開始する。
対処方法
アクセスが集中する時間帯の処理をさばく設定が必要です。方法としては、ユーザ定義リソースプールを作成し、クエリの初期割当てメモリサイズを小さいサイズで設定します。それにより、同時に処理できる数を増やす事ができます。
対処は以下の手順で行います。
Step1：SQLのワークロードを分析
Step2：パラメータ値の検討
Step3：ユーザ定義リソースプールの作成
Step4：DB接続用のユーザを変更
Step5：経過観察
Step6：ユーザ定義リソースプールの使用状況を確認
Step1：SQLのワークロードを分析
アクセスが集中する時間帯のSQLについて、最大同時実行数やメモリ使用量を分析します。
詳細は、以下の Best Practices をご確認下さい。
Best Practices for Managing Resource Pools
[対象項目]
– Resource Manager Analysis
– Appendix
Step2：パラメータ値の検討
分析結果をもとに、ユーザ定義リソースプールについて、パラメータ値を検討します。
初期割当サイズについて、ユーザ定義リソースプール作成時に考慮すべきパラメータはPLANNEDCONCURRENCY(プールに対して想定されるクエリ実行数)です。
こちらの値を元に、1セッションあたりのメモリの初期割当サイズが決定されます。
[算出式]
メモリの初期割当サイズ = MEMORYSIZE(指定しない場合は MAXMEMORYSIZE*0.95) / PLANNEDCONCURRENCY
※PLANNEDCONCURRENCYのデフォルト値は、1ノード当たりのCPUコア数。
PLANNEDCONCURRENCY をデフォルト値(CPUコア数)から「32」に変更した場合のイメージ
また、ユーザ定義リソースプールは、運用時に様々な種類のSQLが実行されると考えられるため、ロングクエリ用とショートクエリ用のプールを分けて作成することをお勧めします。
各ユーザ定義リソースプール設定時のポイントは以下です。
| パラメータ | ロングクエリ用プール | ショートクエリ用プール |
|---|---|---|
| PLANNEDCONCURRENCY | ロングクエリはメモリを多く使用する可能性が高いため、PLANNEDCONCURRENCYの値を小さくし、メモリの初期割り当てサイズを大きくする。これによりメモリの追加割り当てのオーバーヘッドを抑えることができる。 | ショートクエリはロングクエリに比べて必要なメモリが少ない場合が多いため、PLANNEDCONCURRENCYの値を大きくし、メモリの初期割り当てサイズを小さくする。 |
Step3：ユーザ定義リソースプールの作成
パラメータ値が決定したら、ロングクエリ用とショートクエリ用のユーザ定義リソースプールを作成し、各ユーザに割り当てます。
3-1. ユーザ定義リソースプールを作成します。
ロングクエリ用の例：
|
1 2 |
SQL=> CREATE RESOURCE POOL long_pool MEMORYSIZE '0G' MAXMEMORYSIZE '10G' PLANNEDCONCURRENCY 10; |
ショートクエリ用の例：
|
1 |
SQL=> CREATE RESOURCE POOL short_pool MEMORYSIZE '1G' PLANNEDCONCURRENCY 100; |
3-2. ユーザ定義リソースプールの設定値を確認します。
実行結果の [query_budget_kb] からユーザ定義リソースプールで設定されている初期割り当てサイズを確認出来ます。
|
1 2 3 |
SQL=> SELECT pool_name,memory_size_kb,queueing_threshold_kb, max_memory_size_kb,planned_concurrency,query_budget_kb FROM resource_pool_status WHERE pool_name IN('long_pool','short_pool'); |
[実行結果]
3-3.ユーザに作成したユーザ定義リソースプールを割り当てます。
ロングクエリ用の例：
|
1 2 |
SQL=> CREATE USER long_user RESOURCE POOL long_pool; SQL=> ALTER USER long_user RESOURCE POOL long_pool; |
ショートクエリ用の例：
|
1 2 |
SQL=> CREATE USER short_user RESOURCE POOL short_pool; SQL=> ALTER USER short_user RESOURCE POOL short_pool; |
3-4.ユーザに割り当てられたユーザ定義リソースプールを確認します。
|
1 2 |
SQL=> SELECT user_name,resource_pool FROM users WHERE user_name IN('long_user','short_user'); |
[実行結果]
Step4：DB接続用のユーザを変更
アプリケーションからDBに接続するドライバや接続文字列について、ロングクエリ用とショートクエリ用のユーザをそれぞれ設定します。
Step5：経過観察
アクセス集中時に、 SQLのキュー待ちが発生していないか確認します。
SQL実行中のキュー待ちは、以下のVertica技術サイトより確認可能です。
Step6：ユーザ定義リソースプールの使用状況を確認
ロングクエリ用とショートクエリ用のリソースプールが、SQLの実行時に想定どおりに使用されたことを確認してください。
詳細は、以下の Best Practices をご確認下さい。
Best Practices for Managing Resource Pools
[対象項目]
– Resource Manager Analysis
– Appendix
検証バージョンについて
この記事の内容はVertica 12.0で確認しています。
更新履歴
2022/10/17 本記事を公開
