DBインサイド|PostgreSQLArchitecture-1.Process,Memory

エクセンは、創設以来着実に蓄積してきたITシステムのパフォーマンス管理経験と研究能力に基づいて、専門的で差別化されたコンサルティングサービスを提供しています。DBMSの専門家エクセンで新たに披露される「DBインサイド」は、さまざまなDBMSと技術について素早くお知らせする予定です。多くの関心と応援お願いします。

「DBインサイド」の最初のスタートはPostgreSQLで開いてみましょう。PostgreSQLはオープンソースで、オブジェクトリレーショナルDBMSです。RDBとNoSQLの両方をサポートし、最近クラウド環境で注目されているDBの一つです。

主なプロセス

PostgreSQLは、postmasterとpostgresと呼ばれるServerプロセスを介して接続を作成してユーザー要求を受け取ります。これらの要求はさまざまなバックグラウンドプロセスによって処理されます。

この記事では、これらのサーバープロセスと重要な役割を果たす主要なバックグラウンドプロセスについて説明します。

📌このセクションで説明されているパラメータはpostgresql.confファイルで設定できます。パラメータに関する詳細な説明は

参考資料) Configuration File : postgresql.confを参照してください。

postmaster: Supervisor Daemon Process

PostgreSQLサーバーを起動/停止するための必須プロセスであり、最初に起動されるプロセスです。

postmasterプロセスはShared Memory領域を割り当て、さまざまなバックグラウンドプロセスを開始します。
postmaster プロセスは、クライアントからの接続要求を待機します。Clientから接続要求が発生すると、postmasterはClient用のpostgresプロセスを生成します。
最上位プロセスとして、子プロセスの異常動作の有無をチェックし、問題発生時に再起動する役割も行います。

postgres 28152     1  0 Nov05 ?        00:00:06 /usr/pgsql-13/bin/postmaster -D /var/lib/pgsql/13/data/
postgres 28154 28152  0 Nov05 ?        00:00:00 postgres: logger
postgres 28156 28152  0 Nov05 ?        00:00:00 postgres: checkpointer
postgres 28157 28152  0 Nov05 ?        00:00:09 postgres: background writer
postgres 28158 28152  0 Nov05 ?        00:00:10 postgres: walwriter
postgres 28159 28152  0 Nov05 ?        00:00:04 postgres: autovacuum launcher
postgres 28160 28152  0 Nov05 ?        00:00:09 postgres: stats collector
postgres 28161 28152  0 Nov05 ?        00:00:00 postgres: logical replication launcher

# pstree -p 28152         >> postmaster の pid(28152)
postmaster(28152)-+-postmaster(28154) 
                  |-postmaster(28156)
                  |-postmaster(28157)
                  |-postmaster(28158)
                  |-postmaster(28159)
                  |-postmaster(28160)
                  `-postmaster(28161)

postgres: Backend Process

Client が要求した SQL と Command を処理するプロセスで、Client との接続が切断されると終了します。
postmasterプロセスによって開始され、Clientとは1：1の関係です。
max_connections (Default:100) 数値だけクライアントが同時に接続できます。

ユーティリティプロセス（バックグラウンドプロセス）

PostgreSQLのバックグラウンドプロセスにはバージョン固有の違いがありますが、これらのうち最も重要な2つの必須プロセス（BG Writer、WAL Writer）と5つのオプションプロセスについて扱いましょう。

BG Writer

OracleのDBWRプロセスに似ており、Shared BufferのDirty Blockをディスクに書き込むプロセスです。
BG Writer はbgwriter_delay (200 ms) サイクルで最大bgwriter_lru_maxpages (100 Pages) をディスクに書き込みます。
定期的にBG WriterがDirty Blockをディスクに記録しておくと、Checkpoint発生時にFlushする必要があるDirty Blockの量を減らすことができ、安定したI/Oを維持できます。

WAL (Write Ahead Log/Xlog) Writer

WAL Bufferを定期的にチェックして、未記録のトランザクションレコードをすべてディスク（WALファイル）に書き込むプロセス。
WAL Writerは、トランザクションCommitまたはログファイルスペースがすべて満たされたときにWAL Bufferをディスク（WALファイル）に書き出し、WALファイルはデータベースの回復に使用されます。

📌WALの重要な概念は、データファイルの変更がトランザクションログに書き込まれた後に行われるべきです。

Checkpointer

Checkpointを実行するプロセスとしてPostgreSQL 9.2バージョンに追加されました。
PostgreSQL 9.1バージョン以下ではBG Writerが定期的にCheckpointを実行しましたが、9.2バージョンからCheckpointerプロセスが追加され、その機能がBG Writerから分離されました。
PostgreSQL Serverのダウンやクラッシュなどの問題が発生した場合は、最後のCheckpointレコードを確認して修復操作を開始してください。

Checkpointの発生条件は以下の通りです。

1. 以前の Checkpoint 発生からcheckpoint_timeout (5 分) の時間が経過した場合

2. WALファイルのサイズがmax_wal_sizeを超える場合

3. smart または fast モードで Database Server をシャットダウンする場合

4. pg_basebackup または pg_start_backup でバックアップを開始する場合

5. superユーザーによってcheckpoint Commandを実行した場合

📌 ただし、以前のチェックポイント以降に記録されたWALがないと、checkpoint_timeoutを超えても新しいチェックポイントは発生しません。

Archiver

Oracleのアーカイブプロセス（ARCH）と同様に、アーカイブを実行するプロセスです。
Archivingは、WALセグメントが切り替えられたときにWALファイルをArchive領域にコピーする機能であり、コピーされたWALファイルをArchiveファイルと呼ばれます。
Archive領域のパスはarchive_commandに設定され、コピーの代わりにscpコマンドまたはファイルバックアップツールを設定して他のホストに転送できます。
そのファイルはPITR（Point In Time Recovery）です。つまり、データベースを特定の時点の特定の状態に復元するために使用されます。

Stats Collector

PostgreSQL の Database 統計情報を収集するプロセスです。
Session情報（pg_stat_activity）やテーブル統計情報（pg_stat_all_tables）などのDBMS使用統計を収集して、pg_catalogに情報を更新します。
Optimizer は、最適な Query 実行計画を生成するためにその情報を参照します。
Serverが完全にシャットダウンすると、統計情報のコピーがpg_statサブディレクトリに保存されるため、Serverを再起動しても統計が保持される可能性があります。

Autovacuum Launcher

Autovacuumを実行/管理するプロセス。
Autovacuum Workersと呼ばれる複数のプロセスで構成されたDaemonプロセスで、このプロセスによってvacuumの実行が自動化されます。
Autovacuum Launcher プロセスは Autovacuum Workers プロセスを定期的に呼び出し、vacuum および vacuum analyze を実行します。
autovacuum_naptime（1分）ごとに、Autovacuum LauncherプロセスはDatabaseを確認し、autovacuum_max_workers（3つ）のAutovauum Workersプロセスを呼び出します。

📌PostgreSQLでは、RowをUpdateする場合、そのRowを物理的に変更せずに新しい領域を割り当てて使用するため、変更前のRow空間は再利用または消えません。この領域を整理する作業（VACUUM）が必ず必要であり、定期的に行うことをお勧めします。

ロガー

エラーメッセージをログファイルに書き込むプロセス。
Utilityプロセス、Backendプロセス、およびPostmaster Daemonアクティビティに関する情報を記録し、すべてのプロセス情報は$ PGDATA / pg_logの下に保存されます。

メモリの分類

PostgreSQLは、サーバーの起動時にパブリックメモリスペースであるShared Memoryによって割り当てられ、Backendプロセス用のLocal Memoryも割り当てます。

Shared Memoryは、データブロックやトランザクションログなどの情報をキャッシュするためのスペースで、PostgreSQL Serverのすべてのプロセスによって共有される領域です。また、Process、Lock、globalの統計情報もその領域にあります。

これとは別に、Backendプロセスごとに割り当てられて共有できないLocal Memoryという領域も存在し、その領域はSort、Vacuumなどの要求を処理するための作業領域です。

Shared Memory

Shared Memoryはすべてのプロセスが共有して使用し、OracleのSGA領域と似ています。Shared Memoryのコンポーネントのうち、代表的な4つの領域について学びましょう。

Shared Buffer

OracleのBuffer Cacheに似ており、データとデータの変更をブロック単位でキャッシュしてI / Oを迅速に処理するための領域です。
postgresql.confのshared_buffersパラメータ値でサイズを設定できます。Default 値は 128 MB で、1 GB 以上の RAM を搭載したサーバーの場合は、システムメモリの 25% を推奨します。
Shared Buffer に記録される単位は block_size (Default 8K) 単位です。

📌PostgreSQLではPageという用語を主に使用しますが、Blockと混用して使用することもあります。両方の用語の違いは、存在する場所に基づいて分類することもできますが、この記事ではすべて同じ意味で使用します。

WAL Buffer (Write Ahead Log Buffer)

Session が実行するトランザクションの変更ログをキャッシュする領域に、リカバリ操作時にデータを再構成できる領域です。
postgresql.confのwal_buffersパラメータ値でサイズを設定できます。Default値は-1で、shared_buffersの1/32と同じ値で指定します。

Clog Buffer (Commit Log Buffer)

各トランザクションの状態（in_progress、committed、aborted）情報をキャッシュするスペースで、すべてのトランザクションの状態があり、完了したかどうかを確認できる領域です。
別々にサイズを設定できるパラメータはなく、Databaseエンジンによって自動的に管理されます。

ロックスペース

Shared Memory レルムのうち Lock に関連する内容を保持するレルムとして、PostgreSQL インスタンスで使用するすべてのタイプの Lock 情報を保存します。（ロック情報はすべてのバックグラウンドプロセスとユーザープロセスによって共有されます。）
ユーザーが特定のテーブルにアクセスしている場合は、特定のトランザクションがそのテーブルを削除または変更（DDL）しないようにアクティビティを追跡する必要があります。このアクティビティに関する情報を保存するスペースは、Lock Spaceです。

📌Lock Spaceで保持できるLockの数はmax_locks_per_transaction *（max_connections + max_prepared_transactions）です。

Local Memory (Process Memory)

個々のBackendプロセスが割り当てられて使用されるスペースで、OracleのPGAに似ています。その領域の数値は個々のスペースのサイズを意味するため、Connection全体の数値を考慮して設定する必要があります。

また、デフォルトでは、ローカルメモリはセッション単位で割り当てられますが、トランザクション単位で任意に調整できます。

-- セッション単位 work メモリ調整
SET work_mem = '16MB';

-- トランザクション単位のメモリ調整
SET LOCAL work_mem = '16MB';

-- 設定 reset
RESET work_mem

Maintenance Work Memory

メンテナンス操作に使用されるメモリで、maintenance_work_memのデフォルト値は64 MBです。
Vacuum関連タスク、インデックス生成、テーブル変更、Foreign Key追加などのタスクに使用されるスペースです。
関連タスクのパフォーマンスを向上させるには、その領域のサイズを大きくする必要があります。

Temp Buffer

Temporaryテーブルに使用されるスペースで、temp_buffersのデフォルト値は8MBです。
Tempテーブルを使用する場合にのみ割り当てられる領域であり、Session単位で割り当てられる非共有メモリ領域であるため、過度のTempテーブルを使用すると問題になる可能性があります。
その領域はTempファイルとは関係ありません。(Work Memoryを参照)

Work Memory

過剰なSort / Hash操作が発生したため、Tempファイルを使用する前に使用されるスペースで、work_memのデフォルト値は4MBです。
他のLocal Memoryと同じように、複数のSessionで同時に過剰なSort / Hash操作を実行すると問題になる可能性があります。

📌ソート作業（Sort）にはORDER BY、DISTINCT、MERGE JOINなどがあり、Hash OperationにはHASH JOIN、HASH AGGREGATION、IN SUBQUERYなどがあります。

Catalog Cache

System Catalogメタデータを使用するときに使用するスペースです。セッションがメタデータを照会することが頻繁であり、ディスクから読み取ると速度が低下する可能性があるため、個々のメモリに存在します。

Optimizer & Executor

実行した Query に対する最適な実行計画を樹立し、実行計画による実行を担当するメモリ空間です。