Amazon Redshift リーダーノードで CPU 使用率が高くなっているのはなぜですか?

簡単な説明

Amazon Redshift クラスターのリーダーノードは、データベースオペレーションを実行するための実行計画を解析および作成しています。リーダーノードは、そのデータをクライアントに返す前に、クエリの最終処理とデータのマージまたはソートも実行しています。データベース操作の複雑さやリソースの消費量によっては、クラスターのリーダーノードの CPU 使用率が急増する可能性があります。

特に、リーダーノードの CPU 使用率は次の理由で急増する可能性があります。

• データベース接続の増加
• クエリのコンパイルと再コンパイル
• 同時接続の数が多い
• WLM で実行されている同時クエリの数が多い
• リーダーノードのみの関数とカタログクエリ

注: リーダーノードを占有する特定のプロセスをチェックすることはできません。STV_RECENTS テーブルを使用して、特定の時刻に実行されているクエリをチェックします。

解決方法

データベース接続の増加

クライアントサーバーは、リーダーノードを介して Amazon Redshift クラスターと通信しています。データベース接続の数が増えた場合、それらの接続を処理するために CPU 使用率が増加します。Amazon CloudWatch メトリクスをチェックして、DatabaseConnections の制限を超過していないことを確認してください。

クエリのコンパイルと再コンパイル

Amazon Redshift は、クエリ実行プランごとにコードを生成およびコンパイルします。クエリのコンパイルと再コンパイルは、リソースを大量に消費するオペレーションであり、これによりリーダーノードの CPU 使用率が高くなる可能性があります。ただし、クエリのコンパイルまたは再コンパイルオペレーションが完了すると、CPU のパフォーマンスは正常に戻ります。

Amazon Redshift はコンパイルされたコードをキャッシュすることにも留意してください。クエリが送信されると、Amazon Redshift は使用可能なセグメントをすべて再利用し、残りのセグメントを再コンパイルします。その結果、このプロセスは、リーダーノードの高い CPU 使用率の原因となる可能性があります。

注: Amazon Redshift クラスターの再起動後、結果のキャッシュがクリアされても、コンパイルされたセグメントは保持されます。クエリが以前にキャッシュされていた場合、Amazon Redshift はクエリを実行しません。パッチが適用されると、すべてのキャッシュが削除されます。

各クエリセグメントのコンパイル時間 (秒) とセグメントの実行場所を確認するには、以下の SVL_COMPILE システムビューを使用します。

select userid,xid,pid,query,segment,locus,starttime, endtime,
datediff(second,starttime,endtime) as TimetoCompile,compile from svl_compile;

同時接続の数が多い

接続数が多くなると、Amazon Redshift クラスターの同時実行数が増加し、トランザクションが増加する可能性があります。トランザクションが増加すると、リーダーノードの CPU 使用率が高くなる可能性があります。

同時接続数を確認するには、次のクエリを実行します。

select s.process as process_id,
c.remotehost || ':' || c.remoteport as remote_address,
s.user_name as username,
s.starttime as session_start_time,
s.db_name,
i.starttime as current_query_time,
i.text as query 
from stv_sessions s
left join pg_user u on u.usename = s.user_name
left join stl_connection_log c
on c.pid = s.process
and c.event = 'authenticated'
left join stv_inflight i 
          on u.usesysid = i.userid
          and s.process = i.pid
where username <> 'rdsdb'
order by session_start_time desc;

次に、PG_TERMINATE_BACKEND を使用して、アクティブなセッションをすべて閉じます。

WLM で実行されている同時クエリの数が多い

すべてのクライアント接続は、リーダーノードを介して処理されます。データをクライアントサーバーに返す前に、Amazon Redshift のリーダーノードはクエリを解析、最適化、コンパイルします。また、リーダーノードはタスクをコンピューティングノードに分散し、最終的なソートまたは集約を実行します。同時に実行するクエリの数が多いと、リーダーノードレベルで CPU 使用率が高くなる可能性があります。さらに、一部のデータベースオペレーションは、リーダーノードレベルでのみ適用できます。例えば、LIMIT 句を含むクエリでは、データが再分配される前にリーダーノードが制限を受けるため、CPU の消費量が多くなる可能性があります。

同時に実行されるクエリの数と CPU 使用率の相関関係があるかどうかを確認するには、最初に Amazon CloudWatch で WLMRunningQueries と CPUutilization メトリクスをチェックします。

その後、次のように、高い CPU を消費しているクエリを確認します。

SELECT userid, query, xid, aborted,
ROUND(query_cpu_time::decimal,3),
query_execution_time,
segment_execution_time,
substring(querytxt,1,250)
FROM stl_query
JOIN
(SELECT query,
query_cpu_time,
query_execution_time,
segment_execution_time
FROM svl_query_metrics_summary
ORDER BY 2 DESC) a USING (query)
WHERE userid>1
AND starttime BETWEEN '2019-12-02 22:00:00' and '2019-12-05 23:59:59'
ORDER BY 5 DESC;

出力を確認して、どのクエリがリーダーノードと CPU 使用率を増加させるその他の異常値クエリによって処理されているかをチェックします。

注: クエリのクエリパフォーマンスを調整するのがベストプラクティスです。コンピューティングノードを追加するのではなく、リーダーノードの容量を増やし、大規模なノードタイプを選択することを検討してください。

リーダーノードのみの関数とカタログクエリ

Amazon Redshift は、リーダーノードでサポートされている特定の SQL 関数を実装します。リーダーノード関数を含む複雑なクエリがあり、カタログクエリが過負荷になっている場合、CPU 使用率がリーダーノードで急増する可能性があります。詳細については、「リーダーノードでサポートされる SQL 関数」を参照してください。

カタログテーブル (リーダーノードでのみ実行) を参照するステップを特定するには、次のように EXPLAIN プランを確認します。

explain select * from pg_class;
                           QUERY PLAN                          
----------------------------------------------------------------
 LD Seq Scan on pg_class  (cost=0.00..24.57 rows=557 width=243)

出力の LD プレフィックスを確認します。この例では、「LD Seq Scan on pg_class (cost=0.00..24.57 rows=557 width=243)」に LD プレフィックスが表示されています。LD プレフィックスは、クエリがリーダーノード上で排他的に実行されていることを示します。これにより、CPU 使用率が急増する可能性があります。

---