# IO:WALWrite
<a name="wait-event.iowalwrite"></a>



**Topics**
+ [サポート対象エンジンバージョン](#wait-event.iowalwrite.context.supported)
+ [Context](#wait-event.iowalwrite.context)
+ [待機時間が増加する原因の可能性](#wait-event.iowalwrite.causes)
+ [アクション](#wait-event.iowalwrite.actions)

## サポート対象エンジンバージョン
<a name="wait-event.iowalwrite.context.supported"></a>

この待機イベント情報は、RDS for PostgreSQL 10 以降のすべてのバージョンでサポートされています。

## Context
<a name="wait-event.iowalwrite.context"></a>

先行書き込みログデータを生成しているデータベース内のアクティビティは、最初に WAL バッファをいっぱいにし、次に非同期でディスクに書き込みます。待機イベント `IO:WALWrite` は、トランザクションの COMMIT 呼び出しを解放できるように、WAL データのディスクへの書き込みが完了するまで SQL セッションの待機中に生成されます。

## 待機時間が増加する原因の可能性
<a name="wait-event.iowalwrite.causes"></a>

この待機イベントが頻繁に発生する場合は、ワークロードが実行する更新の種類とその頻度を確認する必要があります。特に、次のタイプのアクティビティを確認します。

**高負荷の DML アクティビティ**  
データベーステーブルのデータは、すぐに変更されるわけではありません。あるテーブルへの挿入は、別のクライアントからの同じテーブルへの挿入または更新を待つ必要がある場合があります。データ操作言語 (DML) のステートメントによってデータ値 (INSERT、UPDATE、DELETE、COMMIT、ROLLBACK TRANSACTION) を変更したことで競合が発生し、先行書き込みログファイルがバッファのフラッシュを待つ可能性があります。この状況は、以下の Amazon RDS Performance Insights メトリクスにも表れており、高負荷の DML アクティビティを示しています。  
+  `tup_inserted`
+ `tup_updated`
+ `tup_deleted`
+ `xact_rollback`
+ `xact_commit`
これらのメトリクスの詳細については、「[Amazon RDS for PostgreSQL の Performance Insights カウンター](USER_PerfInsights_Counters.md#USER_PerfInsights_Counters.PostgreSQL)」を参照してください。

**チェックポイントアクティビティの頻度**  
チェックポイントが頻繁に発生すると、WAL ファイルの数が増えます。RDS for PostgreSQL では、ページ全体の書き込みは常に「オン」になっています。ページ全体への書き込みは、データ損失の防止に役立ちます。ただし、チェックポイントが頻繁に行われると、システム全体のパフォーマンスの問題が発生することがあります。これは、特に 高負荷の DML アクティビティのシステムに当てはまります。場合によっては、`postgresql.log` に「チェックポイントが頻繁に発生しています」というエラーメッセージが表示されることがあります。  
チェックポイントをチューニングする際には、異常なシャットダウンが発生した場合に予想される復旧時間と、パフォーマンスとのバランスを慎重に取ることをお勧めします。

## アクション
<a name="wait-event.iowalwrite.actions"></a>

この待機イベントの数を削減するには、次のアクションをお勧めします。

**Topics**
+ [コミットの回数を減らす](#wait-event.iowalwrite.actions.problem)
+ [チェックポイントのモニタリング](#wait-event.iowalwrite.actions.monitor)
+ [IO のスケールアップ](#wait-event.iowalwrite.actions.scale-io)
+ [専用ログボリューム (DLV)](#wait-event.iowalwrite.actions.dlv)

### コミットの回数を減らす
<a name="wait-event.iowalwrite.actions.problem"></a>

コミット数を減らすには、ステートメントをトランザクションブロックにまとめることができます。Amazon RDS Performance Insights を使用して、実行されているクエリの種類を確認してください。また、大規模なメンテナンスオペレーションをオフピークの時間帯に移動することもできます。例えば、インデックスを作成したり、稼働時間外に `pg_repack` オペレーションを使用したりします。

### チェックポイントのモニタリング
<a name="wait-event.iowalwrite.actions.monitor"></a>

RDS for PostgreSQL DB インスタンスがチェックポイント用に WAL ファイルに書き込む頻度をモニタリングできるパラメータが 2 つあります。
+ `log_checkpoints` – このパラメータはデフォルトで「オン」になっています。これにより、チェックポイントごとにメッセージが PostgreSQL ログに送信されます。これらのログメッセージには、書き込まれたバッファの数、書き込みにかかった時間、特定のチェックポイントで追加、削除、またはリサイクルされた WAL ファイルの数が含まれます。

  このパラメータについての詳細は、PostgreSQL ドキュメントの「[エラー報告とログ記録](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-CHECKPOINTS)」を参照してください。
+ `checkpoint_warning` – このパラメータは、チェックポイント頻度のしきい値 (秒単位) を設定します。この値を超えると、警告が表示されます。デフォルトでは、このパラメータは RDS for PostgreSQL では設定されていません。このパラメータの値を設定すると、RDS for PostgreSQL DB インスタンスのデータベース変更が WAL ファイルのサイズが処理できない速度で書き込まれたときに警告を受け取ることができます。例えば、このパラメータを 30 に設定したとします。RDS for PostgreSQL インスタンスが 30 秒に 1 回以上の頻度で変更を書き込む必要がある場合、「チェックポイントが頻繁に発生しています」という警告が PostgreSQL ログに送信されます。これは、`max_wal_size` 値を増やす必要があることを示している可能性があります。

  詳細については、PostgreSQL ドキュメントの「[ログ先行書き込み](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-CHECKPOINTS)」を参照してください。

### IO のスケールアップ
<a name="wait-event.iowalwrite.actions.scale-io"></a>

このタイプの入出力 (IO) 待機イベントは、1 秒あたりの入出力オペレーション (IOPS) をスケーリングして IO を高速化することで修正できます。CPU をスケーリングするよりも IO をスケーリングする方が望ましいです。CPU をスケーリングすると、処理量が増えることで IO ボトルネックがさらに悪化するため、IO の競合がさらに増える可能性があります。一般的に、スケーリングを実行する前にワークロードのチューニングを検討することをお勧めします。

### 専用ログボリューム (DLV)
<a name="wait-event.iowalwrite.actions.dlv"></a>

Amazon RDS コンソール、AWS CLI、または Amazon RDS API を使用して、プロビジョンド IOPS (PIOPS) ストレージを使用する DB インスタンスの専用ログボリューム (DLV) を使用できます。DLV は、PostgreSQL データベーストランザクションログを、データベーステーブルを含むボリュームとは別のストレージボリュームに移動します。詳細については、「[専用ログボリューム (DLV)](CHAP_Storage.md#CHAP_Storage.dlv)」を参照してください。