Amazon Redshift のメンテナンス後、クエリの実行時間が増加する原因を教えてください。

簡単な説明

バージョンアップグレード中、Amazon Redshift はクエリキャッシュとコンパイルキャッシュをクリアします。アップグレード後に初回クエリを実行する際は、コンパイル時間が長くなります。ただし、Amazon Redshift がキャッシュを再構築するにつれて、パフォーマンスは徐々に向上します。

Amazon Redshift はメンテナンス時のアクションにおいて、すべてのクラスターバージョンを変更するとは限りません。バージョン変更を識別するには、SYS_QUERY_HISTORY テーブルの redshift_version 列を参照します。

Amazon Redshift におけるキャッシュの種類に関する詳細については、「結果キャッシュ」および「コンパイル済みコード」を参照してください。クエリパフォーマンスの詳細については、「クエリパフォーマンスに影響する要因」を参照してください。

解決策

メンテナンス前と後のクエリパフォーマンスを分析する

メンテナンスの前後に実行されたクエリを特定します。クエリモニターコンソールまたは SYS_QUERY_HISTORY システムビューを使用します。

直近 20 件のユーザークエリを特定するには、次のクエリを実行します。

SELECT * FROM sys_query_history
WHERE user_id>1
ORDER BY start_time desc
limit 20;

出力の user_query_hash 列を参照し、同じクエリテキストを含む各クエリを比較します。または、generic_query_hash を参照し、類似したクエリテキストが含まれるものの、クエリリテラルが異なる各クエリを比較します。

直近 7 日間に特定のクエリを実行した各時刻を表示するには、次のクエリを実行します。

SELECT * FROM sys_query_history
WHERE user_query_hash = 'ExampleText'
ORDER BY start_time desc;

注: ExampleText をクエリハッシュ値に置き換えてください。

出力に表示される、複数の実行における compile_time 値を比較します。メンテナンスの直後に実行したクエリのコンパイル時間は、長くなる場合があります。

コンパイル時間を短縮するには、主要なクエリをメンテナンス後に実行するようスケジュールするか、重要なクエリをピーク時以外にウォームアップします。

注: クエリ実行エンジンがコンパイルするコードは、接続プロトコルが Java Database Connectivity (JDBC) か Microsoft Open Database Connectivity (ODBC) かで異なります。異なるプロトコルを使用する、2 つのクライアントが存在する場合、各クライアントでコードをコンパイルするための初回コストが発生します。ただし、同じプロトコルを使用するクライアントは、キャッシュされたコードを共有します。JDBC を使用してクラスターに接続し、クエリを実行すると、Amazon Redshift は JDBC 接続のキャッシュのみを保存します。ODBC を使用するクライアントで同じクエリを実行した場合、Amazon Redshift は ODBC 接続用に追加のキャッシュを生成します。

問題のトラブルシューティング

メンテナンス前後でクエリのコンパイル結果がほぼ同一であっても、コンパイルとは無関係なパフォーマンスの問題が発生するケースがあります。Query and Database Monitoring コンソールでメトリクスの異常な急増を監視します。問題の原因を特定するには、コンパイル時間を比較します。

急増は起こっていないにもかかわらず、問題が解消されない場合は、サポートケースを作成してください。

関連情報

SVL_COMPILE