Amazon RDS for PostgreSQL インスタンスをバージョン 11 以降にアップグレードすると、5 分ごとに書き込みレイテンシーが急増するのはなぜですか?

解決策

Amazon RDS for PostgreSQL インスタンスがアイドル状態の場合、Amazon CloudWatch メトリクスの書き込みレイテンシーが 5 分ごとに急増していることに気付くかもしれません。これは、PostgreSQL バージョン 11 以降にアップグレードした後に、拡張モニタリングメトリクスの書き込みの合計容量が約 64 MB に急増することと相関しています。アップグレード後、wal_segment_size パラメータの値は 64 MB になります。バージョン 10 以前のバージョンでは、wal_segment_size の値は 16 MB なので、これらの増加は目立たない場合があります。詳細については、Amazon RDS - ドキュメント履歴の 2018 年 9 月 7 日の更新を参照してください。

Amazon RDS for PostgreSQL の archive_timeout は 5 分に設定されています。この設定では、アーカイブプロセスが 5 分ごとに先書きログ (WAL) セグメントをコピーして Amazon Simple Storage Service (Amazon S3) にアーカイブします。アイドル状態のシステムでは通常、このコピープロセスが唯一の I/O 操作であるため、CloudWatch グラフではこの操作が目に付く可能性があります。ただし、負荷の多いシステムではこのパターンが見られない場合があります。たとえば、db.t3.small インスタンスで次のワークロードを 30 分間実行するとします。この例は、20 GB の Amazon Elastic Block Store (Amazon EBS) ボリュームを持つ RDS for PostgreSQL インスタンス上の負荷の高いシステムをシミュレートしています。

#pgbench --host=$HOST --username=$USER --port=$PORT --protocol=simple  --progress=2  --client=1 --jobs=1 $DB -T 1800
#pgbench --initialize --fillfactor=90 --scale=100  --port=$PORT --host=$HOST --username=$USER $DB

このワークロードでは、CloudWatch 書き込みレイテンシーメトリクスに急増は見られません。

しかし、次のようなユースケースがあるとします。

• 完了までに 10 ミリ秒かかる I/O リクエストが 1 つあり、さらに、それぞれ 1 ミリ秒かかる 9 個の I/O リクエストがあります。これらのリクエストの平均レイテンシーは次のように計算されます。
  平均レイテンシー = (10 + (9\ * 1))/10 = 1.9 ミリ秒
• 完了までに 10 ミリ秒かかる I/O リクエストがあり、ほかの I/O リクエストはありません。この場合の平均レイテンシーは次のように計算されます。
  平均レイテンシー = 10/1 = 10 ミリ秒

どちらのユースケースにも、完了するまでに 10 ミリ秒かかる同じ I/O リクエストが含まれます。ただし、平均レイテンシーを計算すると、遅いリクエストが目立ちます。これは、2 番目のユースケースでは、低速なリクエストと一緒に実行される I/O リクエストが少ないためです。ブロックサイズが大きいためにアイドル状態のシステムに低速な I/O リクエストが 1 つある場合、レイテンシーはこのリクエストのみから計算されます。それそれのブロックサイズが小さい複数の I/O リクエストがある、負荷の高いシステムでは、平均レイテンシーはこれらすべてのリクエストから計算されます。

このような場合、アイドル状態の Amazon RDS for PostgreSQL システムでは、5 分ごとに書き込みレイテンシーが急増することがあります。データベースインスタンスが負荷の高いワークロードを実行している場合、これらの増加は発生しない可能性があります。

**例:**2 つの t2.small Amazon Elastic Compute Cloud (Amazon EC2) インスタンスがあり、それぞれに 8 つの gp2 ボリュームがあるとします。

crontab で以下のコマンドを実行します。このコマンドにより、最初の Amazon EC2 インスタンスで、5 分ごとにブロックサイズが 64 MB である 64 MB のファイルが作成されます。

*/5 * * * * dd if=/dev/zero of=/tmp/big_file.txt bs=64MB count=1 oflag=dsync ; rm -rf /tmp/big_file.txt

**注:**コマンド内の big_file.txt を自分のファイルの名前に置き換えます。

また、crontab で以下のコマンドを実行します。このコマンドは、2 番目の Amazon EC2 インスタンスで、それぞれ 8 KB のブロックサイズの 100 個のファイルを 1 分ごとに作成します。

* * * * * for i in {1..100} ; do dd if=/dev/zero of=/tmp/small_file.txt bs=8k count=100 oflag=dsync ; rm -rf /tmp/small_file.txt ; done

**注:**コマンド内の small_file.txt を自分のファイルの名前に置き換えます。

CloudWatch では、2 番目の EC2 インスタンスの方が最初の EC2 インスタンスよりも書き込みレイテンシーの急上昇が大きいことに気付くかもしれません。

関連情報

PostgreSQL を使用するためのベストプラクティス