PostgreSQL 18 アーキテクチャ入門：プロセス構成とメモリの仕組み



PostgreSQLをLinuxサーバー上に構築し、安定して運用するためには、データベース内部でどのようなプロセスが起動し、メモリがどのように消費されているかを正確に把握しておく必要があります。パラメータの調整やパフォーマンス低下への対応、障害発生時の切り分けは、すべてアーキテクチャの理解が前提となります。

1. PostgreSQLの全体像とプロセス駆動モデル#

1.1 プロセス分岐（fork）モデルの特徴とマルチスレッドとの違い#

リレーショナルデータベースのアーキテクチャには、マルチスレッドモデルを採用するもの（MySQLやSQL Serverなど）と、マルチプロセスモデルを採用するものがあります。PostgreSQLは伝統的にマルチプロセスモデル（プロセス駆動型アーキテクチャ）を一貫して採用しています。

マルチプロセスモデルでは、データベースの起動時にまず単一の親プロセス（Postmaster）が立ち上がります。外部からクライアントの接続要求が届くたびに、OSのシステムコールであるfork()を発行し、その接続専用の独立した子プロセス（バックエンドプロセス）を生成します。

この設計には以下の特徴があります。

• 堅牢性とメモリ保護：各バックエンドプロセスはOSによって独立した仮想アドレス空間が割り当てられます。仮に特定のセッションで重篤なエラーやメモリアクセス違反が発生しても、その影響はそのプロセス内にとどまり、データベース全体がクラッシュする事態を防止できます。
• コンテキストスイッチの負荷：スレッドと異なり、プロセス切り替えにはOSレベルの重いコンテキストスイッチを伴います。そのため、数千件規模の同時接続を直接受け付ける運用には向いておらず、コネクションプーラー（PgBouncer等）の併用が前提となります。

1.2 クライアント接続フローとバックエンドプロセスの生成#

クライアント（Webアプリケーションやpsqlコマンド等）がPostgreSQLに接続を開始してからクエリを実行するまでの流れは以下の順序で進行します。

1. ポート監視：親プロセスが指定されたポート（標準はTCP 5432）で接続要求を待ち受けます。
2. 認証処理：接続要求を受信すると、pg_hba.confに定義された認証規則に基づいてクライアントのIPアドレス、ユーザー名、パスワード（SCRAM-SHA-256等）を検証します。
3. プロセスの分岐（fork）：認証が成立すると、親プロセスが自身を複製して新しいバックエンドプロセスを起動し、ソケットの制御権を渡します。
4. クエリの実行：生成されたバックエンドプロセスは、クライアントからのSQL文を受信し、構文解析（パーサー）、書き換え（リライタ）、実行計画の策定（オプティマイザ）、そして実行エンジンでのデータ取得を担当します。

2. プロセス構成の整理：各プロセスの責務#

2.1 主プロセス（Postmaster）とバックエンドプロセス#

PostgreSQLを構成するプロセス群は、大きく「主プロセス」「バックエンドプロセス」「バックグラウンドプロセス」の3系統に分類されます。

• 主プロセス（Postmaster）：システム起動時にPID 1相当として動作する統括プロセスです。共有メモリ領域を初期化して確保し、常駐バックグラウンドプロセス群を起動します。その後はポート5432の監視と、異常終了した子プロセスの検知・再起動を担当します。実行バイナリ名はpostgresです。
• バックエンドプロセス（Backend Process）：クライアント接続ごとに1対1で対応する作業プロセスです。クライアントから送られたSQL文を処理し、結果セットを返却します。セッションが切断されると、このプロセスは役目を終えて終了します。

2.2 主要バックグラウンドプロセス一覧#

PostgreSQLがデータの整合性や高速な書き込み、自動メンテナンスを維持するために、Postmasterの配下で常駐動作している補助プロセス群が存在します。

3. メモリ構造の二大領域：共有メモリ vs ローカルメモリ#

PostgreSQLのメモリ空間は、すべてのプロセスから参照可能な共有メモリ領域（Shared Memory Area）と、個別のバックエンドプロセスのみが利用するローカルメモリ領域（Local Memory Area）に二分されます。この構造の違いを把握することが、サーバーダウンを防ぐサイジングの第一歩となります。

3.1 共有メモリ領域（Shared Memory Area）の役割#

共有メモリは、Postmasterプロセスの起動時にOSからまとめて割り当てられる領域です。すべてのバックエンドプロセスおよび補助プロセスが共通してアクセスします。

• データバッファ（shared_buffers）：テーブルやインデックスの実データブロック（標準8KB）をメモリ上にキャッシュしておく最重要領域です。読み取り要求があった場合、まずこの領域を検索し、ヒットすればディスクI/Oを発生させずに高速返却します。一般にサーバー搭載物理RAMの25パーセント程度を目安に設定します。
• WALバッファ（wal_buffers）：トランザクションの変更履歴ログをディスクに書き出す前に一時保管するバッファです。コミット時またはバッファ満杯時にディスクへフラッシュされます。
• ロック管理・プロセス間通信領域：テーブルロックや行ロックの情報を保持するLock Table、コミット状態を管理するCLOG（pg_xact）などが配置されます。

3.2 ローカルメモリ領域（Local Memory Area）とメモリ枯渇のメカニズム#

ローカルメモリは、各バックエンドプロセスが必要に応じてオンデマンドでOSから確保する一時的なメモリ領域です。接続が終了するか、クエリの特定工程が完了すると解放されます。

• work_mem：ORDER BYによるソート処理や、ハッシュ結合（Hash Join）、ビットマップ走査などの実行時に使用されます。初期値は通常4MB程度です。
• maintenance_work_mem：VACUUM、CREATE INDEX、外部キー制約の追加などのメンテナンス作業専用のメモリです。日常クエリ用のwork_memよりも大きめの値（64MB〜1GB程度）を設定します。
• temp_buffers：セッション内で作成された一時テーブル（TEMPORARY TABLE）のデータブロックをキャッシュする領域です。

3.3 LinuxカーネルパラメータとOOM Killer対策（overcommit設計）#

Linuxカーネルのメモリ管理には、物理メモリ以上の仮想メモリをプロセスへ楽観的に割り当てる「メモリオーバーコミット（Overcommit）」機能が存在します。デフォルト（vm.overcommit_memory = 0）では、実際に書き込みが発生して物理メモリが完全に枯渇した瞬間に、カーネルが最もメモリを消費しているプロセスを「OOM Killer」によって強制終了（SIGKILL）します。

データベースサーバーにおいて、Postmaster親プロセスやバックエンドプロセスがOOM Killerに殺されると、PostgreSQLはデータ不整合を防ぐために全接続を強制遮断して緊急クラッシュリカバリモード（REDOログの再適用）に突入し、数分から数十分のサービス全停止を引き起こします。

# /etc/sysctl.d/99-postgresql.conf への推奨追記設定
vm.overcommit_memory = 2
vm.overcommit_ratio = 80

# 設定の即時反映
$ sudo sysctl -p /etc/sysctl.d/99-postgresql.conf

3.4 Huge Pages（ヒュージページ）の採用メリットと設定実務#

Linuxの標準メモリアーキテクチャでは、メモリは「4KB」単位のページで管理されます。しかし、shared_buffers に8GBや32GBといった大容量メモリを割り当てた場合、CPU内部のページテーブル（TLB: Translation Lookaside Buffer）のエントリ数が膨大になり、TLBミスヒットによるCPUオーバーヘッドや、ページテーブル自体による数十MB〜数百MBのメモリ無駄消費が発生します。

Huge Pages（2MB単位の巨大ページ） を有効化することで、ページ管理エントリ数を1/512に削減し、CPUのメモリアクセス性能を大幅に改善できます。

# 1. 必要なヒュージページ数の算出（例：shared_buffersが1GBの場合、約550ページ）
$ grep -i hugepage /proc/meminfo

# 2. カーネルパラメータでヒュージページを常時予約
# /etc/sysctl.d/99-hugepages.conf
vm.nr_hugepages = 600

# 3. postgresql.conf での有効化
huge_pages = on  # 'try'（試行）ではなく 'on' で明示確保を強制

huge_pages = on を設定しておくと、PostgreSQL起動時にヒュージページが十分に確保できない場合に起動エラーとなるため、意図せず4KBページで稼働してしまう「サイレントな性能低下」を確実に防止できます。

4. 実機で確認するPostgreSQLアーキテクチャ（AlmaLinux 10）#

理論として整理したプロセスツリーとメモリ設定が、実際のAlmaLinux 10環境上でどのように表現されているかをコマンドを用いて実機確認します。

4.1 psコマンドによるプロセスツリーの確認#

システム上でPostgreSQLが稼働している状態で、psコマンドに--forestオプションを付与して実行すると、Postmaster親プロセスと子プロセスの親子関係が視覚的に確認できます。

$ ps -ef --forest | grep -E 'postgres|UID'
UID          PID    PPID  C STIME TTY          TIME CMD
postgres    2571       1  0 00:44 ?        00:00:00 /usr/pgsql-18/bin/postgres -D /var/lib/pgsql/18/data
postgres    2572    2571  0 00:44 ?        00:00:00  \_ postgres: logger 
postgres    2573    2571  0 00:44 ?        00:00:00  \_ postgres: checkpointer 
postgres    2574    2571  0 00:44 ?        00:00:00  \_ postgres: background writer 
postgres    2576    2571  0 00:44 ?        00:00:00  \_ postgres: walwriter 
postgres    2577    2571  0 00:44 ?        00:00:00  \_ postgres: autovacuum launcher 
postgres    2578    2571  0 00:44 ?        00:00:00  \_ postgres: logical replication launcher 

出力ログから以下の事実が確認できます。

• 親プロセス（PID 2571）はPPIDが1（systemd）であり、/usr/pgsql-18/bin/postgres -D /var/lib/pgsql/18/dataとして起動しています。
• その配下に、PPID 2571を持つ子プロセスとしてlogger、checkpointer、background writer、walwriter、autovacuum launcher、logical replication launcherが階層状に紐付いています。

4.2 内部ビュー pg_stat_activity とパラメータの照合#

次に、psqlインターフェースから内部ビューpg_stat_activityを検索し、PostgreSQL自身が認識しているプロセス一覧と主要メモリパラメータを取得します。

$ sudo -u postgres /usr/pgsql-18/bin/psql

-- メモリパラメータの現在値照合
SHOW shared_buffers;
--  shared_buffers 
-- ----------------
--  128MB

SHOW work_mem;
--  work_mem 
-- ----------
--  4MB

SHOW maintenance_work_mem;
--  maintenance_work_mem 
-- ----------------------
--  64MB

-- 稼働中のバックエンド種別の確認
SELECT pid, backend_type FROM pg_stat_activity ORDER BY pid;
/*
 pid  |         backend_type         
------+------------------------------
 2573 | checkpointer
 2574 | background writer
 2576 | walwriter
 2577 | autovacuum launcher
 2578 | logical replication launcher
 2642 | client backend
(6 行)
*/

PID 2642として表示されているclient backendが、現在psqlを実行しているクライアント接続専用のバックエンドプロセスです。OSのpsコマンドの出力と内部ビューの情報が正確に一致していることが実証されます。

4.3 work_mem不足によるディスク一時ファイル（Temporary File）の出力検証#

各バックエンドプロセスがクエリを実行する際、work_memが不足すると何が起きるかを実機でシミュレーションします。

PostgreSQLでは、ソートやハッシュ結合に必要なデータ量が work_mem の上限を超過した場合、メモリ内ソート（quicksort）を諦め、ディスク上の pgsql_tmp/ ディレクトリに一時ファイル（Temporary File）を書き出して外部マージソート（External Merge Sort）を実行します。ディスクI/Oが発生するため、クエリ応答速度は数十倍から数百倍に急落します。

-- セッションパラメータの変更
bench_db=# SET log_temp_files = 0;
bench_db=# SET work_mem = '64kB';

-- ソート実行計画の採取
bench_db=# EXPLAIN ANALYZE SELECT generate_series(1, 100000) ORDER BY 1 DESC;
                                                    QUERY PLAN                                                    
------------------------------------------------------------------------------------------------------------------
 Sort  (cost=12543.00..12793.00 rows=100000 width=4) (actual time=24.112..31.845 rows=100000 loops=1)
   Sort Key: (generate_series(1, 100000)) DESC
   Sort Method: external merge  Disk: 1768kB
   ->  ProjectSet  (cost=0.00..5002.00 rows=100000 width=4) (actual time=0.004..6.211 rows=100000 loops=1)
         ->  Result  (cost=0.00..0.01 rows=1 width=0) (actual time=0.001..0.001 rows=1 loops=1)
 Planning Time: 0.045 ms
 Execution Time: 35.120 ms
(7 行)

実行計画の Sort Method に着目してください。external merge Disk: 1768kB と表示されており、メモリに収まらず約1.8MBのディスク書き込みが発生したことが分かります。サーバーログ（postgresql-*.log）にも以下のように明確に出力されます。

2026-09-09 20:45:12.418 JST [2642] LOG:  一時ファイル: パス"base/pgsql_tmp/pgsql_tmp2642.0", サイズ 1810432 バイト
2026-09-09 20:45:12.419 JST [2642] STATEMENT:  EXPLAIN ANALYZE SELECT generate_series(1, 100000) ORDER BY 1 DESC;

本番環境では、log_temp_files を適切な閾値（例：10MB）に設定し、一時ファイルを大量消費している重いクエリを検知して work_mem の見直しやインデックス付与（ソート回避）を行うのが運用チューニングの鉄則です。

5. データの整合性を保つ仕組み：WALとチェックポイント#

5.1 なぜWAL（Write-Ahead Logging）が必要なのか#

リレーショナルデータベースにおいて、トランザクションのコミット要求があるたびにディスク上のデータファイル（テーブルやインデックスの実体）へ直接書き込みを行うと、ディスクヘッドのランダムアクセスが頻発してスループットが極端に低下します。

そこでPostgreSQLは、WAL（Write-Ahead Logging: 先行書き込みログ）という仕組みを採用しています。更新処理が発生した際、データ本体をディスクに直接書き込むのではなく、まず以下の手順を踏みます。

1. 共有メモリ上のバッファページを更新します（この状態のページをダーティページと呼びます）。
2. 同時に、どのような変更を加えたかという差分履歴（REDOログレコード）をWALバッファに追記します。
3. クライアントからCOMMITが発行されると、WALバッファにたまっているログレコードのみをディスク上のWALファイル（pg_wal/ディレクトリ配下）へシーケンシャル（連続）書き込みし、fsyncを発行して物理フラッシュします。
4. WALの物理フラッシュが完了した時点で、クライアントへ「コミット成功」を通知します。

シーケンシャルアクセスはランダムアクセスに比べて極めて高速であるため、高いトランザクション性能を維持しながら、ACID特性の耐久性（Durability）を保証できます。万一この直後にサーバーの電源が落ちても、再起動時にWALログを読み出してダーティページを再現（REDO）できるため、コミット済みデータが失われることはありません。

5.2 チェックポイントの動作シーケンス#

WALファイルに追記を続けるだけでは、ディスク容量がいずれ枯渇し、障害発生時のクラッシュリカバリ時間も長大化してしまいます。そこで、メモリ上に滞留しているダーティページを実際のデータファイルへまとめて反映させる定期処理がチェックポイント（Checkpoint）です。

チェックポイントの処理シーケンスは以下の通りです。

1. 契機の検知：設定された時間（checkpoint_timeout、標準5分）が経過するか、書き込まれたWALログの総量が上限（max_wal_size、標準1GB）に達すると、Checkpointerプロセスが動作を開始します。
2. ディスク書き出し：共有バッファ内の全ダーティページをディスク上のデータファイル（base/ディレクトリ配下）へフラッシュし、fsyncを実行します。
3. 制御ファイルの更新：クラスタの制御情報ファイル（global/pg_control）に、「このチェックポイント位置（LSN: ログシーケンス番号）までデータファイルへの同期が完了した」という情報を記録します。
4. 古いWALの再利用：チェックポイント完了地点より過去の古いWALセグメントはリカバリに不要となるため、削除または次回の書き込み用としてリサイクル（名前変更）されます。

# pg_controldata による制御情報の確認
$ sudo -u postgres pg_controldata /var/lib/pgsql/data | grep -E 'チェックポイント|状態'
データベースクラスタの状態:                  運用中
最終チェックポイント位置:                    0/14EFA28
最終チェックポイントのREDO位置:              0/14EFA28
最終チェックポイントのREDO WALファイル:      000000010000000000000001
最終チェックポイント時刻:                    2026年09月09日 00時44分24秒

pg_controldataコマンドで確認できる「最終チェックポイントのREDO位置」が、万一障害が起きた際にロールフォワード（リカバリ）を開始すべき基点を示しています。

6. 実務トラブルシューティング事例集（3大障害シナリオと解決策）#

アーキテクチャの基本構造を理解したところで、実務運用において頻発する代表的なメモリ・プロセス関連の障害シナリオ3選と、その原因特定手順および恒久対策を整理します。

6.1 シナリオ1：OOM Killer発動によるPostgreSQL強制終了とクラッシュリカバリ#

物理メモリの枯渇により、LinuxカーネルのOOM（Out of Memory）KillerがPostgreSQLのバックエンドプロセスを強制終了（SIGKILL）させる障害です。1つのバックエンドプロセスがSIGKILLで停止すると、共有メモリ領域が不整合状態に陥る可能性があるため、主プロセス（Postmaster）はデータ保護のために他の全バックエンドを直ちに強制終了し、自動的にクラッシュリカバリモードへ遷移します。

2026-09-09 21:15:30 JST [12345] LOG:  server process (PID 12890) was terminated by signal 9: Killed
2026-09-09 21:15:30 JST [12345] DETAIL:  Failed process was running: SELECT * FROM large_table ORDER BY payload;
2026-09-09 21:15:30 JST [12345] LOG:  terminating any other active server processes
2026-09-09 21:15:30 JST [12345] LOG:  all server processes terminated; reinitializing
2026-09-09 21:15:32 JST [13001] LOG:  database system was not properly shut down; automatic recovery in progress
2026-09-09 21:15:32 JST [13001] LOG:  redo starts at 0/1A2B3C4
2026-09-09 21:15:34 JST [13001] LOG:  redo done at 0/1A2D000 system usage: CPU: user: 0.05 s, system: 0.02 s, elapsed: 2.10 s
2026-09-09 21:15:34 JST [12345] LOG:  database system is ready to accept connections

原因：work_mem × 同時複雑クエリ数の掛け算により、OSの空き物理メモリ＋スワップ領域を超過したことが主因です。また、Linuxのデフォルト挙動であるメモリのオーバーコミット（物理メモリ以上の仮想メモリ割り当てを許可する仕様）が拍車をかけます。

6.2 シナリオ2：共有メモリ（shared_buffers）過大設定によるサービス起動失敗#

サーバー増強時などにshared_buffersを過剰に大きな値（物理メモリと同等以上、あるいはOSの許容共有メモリ上限以上）に設定してしまい、PostgreSQLサービスが起動できなくなる障害です。

$ sudo systemctl start postgresql-18
Job for postgresql-18.service failed because the control process exited with error code.

$ sudo journalctl -u postgresql-18 -n 20 --no-pager
Sep 09 21:20:10 alma-db01 postmaster[14100]: 2026-09-09 21:20:10 JST [14100] FATAL:  could not map anonymous shared memory: Cannot allocate memory
Sep 09 21:20:10 alma-db01 postmaster[14100]: 2026-09-09 21:20:10 JST [14100] HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages.
Sep 09 21:20:10 alma-db01 postmaster[14100]: 2026-09-09 21:20:10 JST [14100] LOG:  database system is shut down

原因：shared_buffersはPostgreSQLの起動時に一括してOSから匿名共有メモリ（mmap）として確保されます。搭載メモリ8GBのサーバーに対して誤ってshared_buffers = 16GBと指定した場合や、Huge Pages（ヒュージページ）の設定不足によりメモリマッピングが拒否された場合に発生します。

対策：実物理メモリの25%（8GB環境なら2GB、16GB環境なら4GB）を上限の目安としてpostgresql.confを修正し、再起動します。巨大なメモリ環境で25%超を割り当てる場合は、OSのHuge Pages（vm.nr_hugepages）を正しくサイジングした上で段階的に引き上げます。

6.3 シナリオ3：チェックポイントスパイク（急激なディスクI/O集中）と平滑化チューニング#

大量の更新・挿入トランザクションが集中した際、突発的にディスクI/O使用率が100%に張り付き、Webアプリケーション側のレスポンスが数百ミリ秒から数秒に急悪化する現象です。通称「チェックポイントスパイク（Checkpoint Spike）」と呼ばれます。

2026-09-09 21:30:00 JST [11000] LOG:  checkpoint starting: time
2026-09-09 21:30:15 JST [11000] LOG:  checkpoint complete: wrote 45200 buffers (27.6%); 0 WAL file(s) added, 12 removed, 8 recycled; write=14.210 s, sync=0.812 s, total=15.022 s; sync files=180, longest=0.320 s, average=0.004 s; distance=393216 kB, estimate=410000 kB
2026-09-09 21:31:05 JST [11000] LOG:  checkpoints are occurring too frequently (35 seconds apart)
2026-09-09 21:31:05 JST [11000] HINT:  Consider increasing the configuration parameter "max_wal_size".

原因と平滑化メカニズム：チェックポイントが発生すると、共有バッファ上の全ダーティページをストレージへフラッシュする必要があります。この書き出し処理を短時間で急激に行うと、ディスク帯域を使い果たしてバックエンドプロセスの通常読み書きを阻害します。

7. 実務チートシート：メモリサイジング計算式とリアルタイム診断クエリ集#

本番システムのインフラ構築および運用フェーズで即座に活用できる、メモリサイジングの黄金比計算式と、プロセス稼働状況を把握するための実務用診断クエリをまとめました。

7.1 本番環境メモリサイジング黄金比計算シート#

サーバー搭載の物理RAM容量に応じた、推奨初期設定値の算出式です。DB専用サーバー（Webサーバー等と相乗りしない構成）を前提としています。

7.2 プロセス・メモリ状態のリアルタイム診断クエリ一覧#

実務でDB性能低下や不審なリソース消費を検知した際、psqlから即座に実行できるトラブル診断クエリです。

SELECT
    pid,
    usename,
    client_addr,
    application_name,
    state,
    wait_event_type,
    wait_event,
    now() - query_start AS duration,
    query
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY duration DESC;

-- 共有バッファ内におけるテーブル別キャッシュ占有状況を集計
SELECT
    c.relname,
    pg_size_pretty(count(*) * 8192) as buffered_bytes,
    round(100.0 * count(*) / (SELECT setting FROM pg_settings WHERE name='shared_buffers')::integer, 2) AS buffer_percent
FROM pg_buffercache b
JOIN pg_class c ON b.relfilenode = pg_relation_filenode(c.oid)
JOIN pg_database d ON (b.reldatabase = d.oid AND d.datname = current_database())
GROUP BY c.relname
ORDER BY count(*) DESC
LIMIT 10;

8. 理解度確認演習問題（全2問・解答解説付き）#

9. まとめと次回予告#

次回は第2回「【AlmaLinux 10】AppStream vs PGDG公式RPM 比較検証と初期構築」を解説します。OS標準のリポジトリから導入する手順と、PostgreSQLコミュニティ公式リポジトリから導入する手順の決定的な違い、パス構造の相違点、そして将来のバージョンアップを見据えた選定基準を実機検証で整理します。

リンク