# RDS for PostgreSQL プロセス
<a name="PostgreSQL.Tuning.concepts.processes"></a>

RDS for PostgreSQL では複数のプロセスを使用します。

**Topics**
+ [Postmaster プロセス](#PostgreSQL.Tuning.concepts.postmaster)
+ [バックエンドプロセス](#PostgreSQL.Tuning.concepts.backend)
+ [バックグラウンドプロセス](#PostgreSQL.Tuning.concepts.vacuum)

## Postmaster プロセス
<a name="PostgreSQL.Tuning.concepts.postmaster"></a>

*Postmaster プロセス*は、RDS for PostgreSQL を起動したときに初期のプロセスがスタートされます。Postmaster プロセスには、主に次のようなロールがあります。
+ バックグラウンドプロセスのフォークとモニタリング
+ クライアントプロセスから認証要求を受信し、データベースが要求を処理する前に認証する

## バックエンドプロセス
<a name="PostgreSQL.Tuning.concepts.backend"></a>

Postmaster がクライアント要求を認証する場合、Postmaster は新しいバックエンドプロセスをフォークします。これは postgres プロセスとも呼ばれます。1 つのクライアントプロセスが 1 つのバックエンドプロセスに接続されます。クライアントプロセスとバックエンドプロセスは、Postmaster プロセスの介入なしに直接通信します。

## バックグラウンドプロセス
<a name="PostgreSQL.Tuning.concepts.vacuum"></a>

Postmaster プロセスは、異なるバックエンドタスクを実行するいくつかのプロセスをフォークします。より重要なものとしては、以下のとおりです。
+ WALライター

  RDS for PostgreSQL は WAL (ログ先行書き込み) バッファのデータをログファイルに書き込みます。ログ先行書き込みの原理は、データベースがそれらの変更を説明するログレコードをディスクに書き込むまで、データベースがデータファイルに変更を書き込むことができないということです。WAL メカニズムはディスク I/O を削減し、RDS for PostgreSQL が障害後にデータベースを回復するためにログを使用できるようにします。
+ バックグラウンドライター

  このプロセスは、メモリバッファからデータファイルにダーティ (変更された) ページを定期的に書き込みます。バックエンドプロセスがメモリ上でページを変更すると、ページがダーティになります。
+ オートバキュームデーモン

  最新のデーモンには以下の構成要素があります。
  + オートバキュームランチャー
  + オートバキュームワーカープロセス

  オートバキュームをオンにすると、多数の挿入、更新、または削除されたタプルがあるテーブルを確認します。デーモンには、次のようなロールがあります。
  + 更新または削除された行によって占有されているディスク領域をリカバリまたは再利用する
  + プランナーで使用する統計情報を更新する
  + トランザクション ID のラップアラウンドによる古いデータの損失からの保護

  オートバキューム機能は、`VACUUM`と`ANALYZE`コマンドの実行を自動化するもので、`VACUUM`にはスタンダードとフルのバリエーションがあります。スタンダードバキュームは、他のデータベースオペレーションと並行して実行されます。 `VACUUM FULL`は、作業中のテーブルを排他的にロックする必要があります。そのため、同じテーブルにアクセスするオペレーションと並行して実行することはできません。`VACUUM`は相当量の I/O トラフィックを作成し、他のアクティブなセッションのパフォーマンスが低下する原因となることがあります。