postgresql.confのメモリ設定を決める方法｜shared_buffersとwork

postgresql.confのメモリ設定を決める方法｜shared_buffersとwork_memの見積もりと反映手順

この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

ＨＯＭＥ＞ Linux技術リナックスマスター.JP（Linuxマスター.JP）＞ Linuxtips ＞データーベース管理＞ postgresql.confのメモリ設定を決める方法｜shared_buffersとwork_memの見積もりと反映手順

「PostgreSQLをLinuxにインストールしたのに、クエリが遅い。設定を確認すると shared_buffers が 128MB のまま。適切な値はどう決めればいいのか？」

インストール直後の postgresql.conf は、古い低スペック環境でも起動できるよう極めて保守的なデフォルト値になっています。実務のLinuxサーバーでそのまま使うと、DBが必要なページをディスクから毎回読み込む状態が続き、クエリのたびにI/Oが走ってパフォーマンスが頭打ちになります。

この記事では、postgresql.conf で調整すべき主要なメモリパラメータ（shared_buffers・work_mem・effective_cache_size・maintenance_work_mem）の見積もり計算式と、設定を反映する手順を実機の出力例とあわせて解説します。
動作確認環境：RHEL 9.4 / Ubuntu 24.04 LTS（PostgreSQL 16）

この記事のポイント

・shared_buffers は「搭載RAM ÷ 4」が実務の出発点（デフォルト128MBは小さすぎる）
・work_mem は接続数とクエリの複雑さで倍増するため、計算式で保守的に見積もる
・shared_buffers の変更には再起動が必要、work_mem はリロードだけで反映できる
・設定後は SHOW 文または pg_settings ビューで反映を必ず確認する

「このままじゃマズい」と感じていませんか？

参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。

姓・名・メールの3つだけ／30秒／解除は3秒／詳細はこちら

なぜデフォルトのpostgresql.confのままではパフォーマンスが出ないのか

PostgreSQLのデフォルト設定が保守的な理由は、OSやハードウェアへの依存を最小限に抑えるためです。パッケージをインストールした直後の postgresql.conf の主要メモリパラメータは次のとおりです。

# デフォルト値を確認する # Ubuntu/Debian: /etc/postgresql/16/main/postgresql.conf # RHEL/Rocky Linux: /var/lib/pgsql/16/data/postgresql.conf $ grep -E '^#?(shared_buffers|work_mem|effective_cache_size|maintenance_work_mem)' /etc/postgresql/16/main/postgresql.conf #shared_buffers = 128MB # min 128kB #work_mem = 4MB # min 64kB #maintenance_work_mem = 64MB # min 1MB #effective_cache_size = 4GB

shared_buffers = 128MB は PostgreSQL が自分のバッファキャッシュとして確保するメモリ量です。16GBのRAMを積んだサーバーで 128MB のままにしておくと、DBは必要なページをこのわずかな領域に収めようとしてキャッシュミスが多発し、ディスクI/Oが増え続けます。

また work_mem = 4MB は、ソートやハッシュ結合の中間作業に使われるメモリです。これが小さいと、ソートの途中でディスクに一時ファイルを書き出す「スピルト」が起きて急激に遅くなります。

postgresql.confで調整が必要なメモリ関連パラメータ4つ

1. shared_buffers — DBキャッシュの中核

PostgreSQL が確保する共有バッファキャッシュのサイズです。読み込んだテーブルページやインデックスページを保持し、同じページへの再アクセスをディスクI/Oなしに処理します。

・推奨値：搭載RAM の 25%（RAM 16GB → 4GB）
・上限の目安：40% 程度まで。それ以上にするとOS側のページキャッシュが圧迫される
・反映方法：PostgreSQL の再起動が必要（pg_reload_conf では反映されない）

2. work_mem — ソート・結合の作業メモリ

ORDER BY・GROUP BY・DISTINCT・ハッシュ結合などの作業に使われる、セッションローカルのメモリです。

・推奨値：RAM × 10% ÷ max_connections を出発点にする（後述の計算式を参照）
・注意点：1クエリ内に複数のソートノードがある場合、work_mem × ノード数の合計が消費される
・反映方法：pg_reload_conf() で反映可能（再起動不要）

3. effective_cache_size — クエリプランナーへのヒント

実際にメモリを確保するパラメータではありません。OSのページキャッシュ込みで「何GBのデータをRAMで捌けるか」をプランナーに教えるヒント値です。この値が大きいほどプランナーはインデックススキャンを好む傾向があります。

・推奨値：RAM の 60～75%（RAM 16GB → 10～12GB）
・反映方法：pg_reload_conf() で反映可能

4. maintenance_work_mem — VACUUM・インデックス構築の作業メモリ

VACUUM・ANALYZE・CREATE INDEX・ALTER TABLE のような保守作業が使う作業メモリです。同時に複数の保守作業が走る環境でない限り、消費は1セッション分だけなので、work_mem より大きめに設定しても安全です。

・推奨値：256MB～1GB（RAM 16GB なら 512MB～1GB）
・反映方法：pg_reload_conf() で反映可能

shared_buffersの設定値を計算して反映する手順

1. サーバーの搭載RAMを確認する

$ free -h total used free shared buff/cache available Mem: 15Gi 4.2Gi 8.9Gi 106Mi 2.3Gi 11Gi Swap: 1.0Gi 0B 1.0Gi

total 列の Mem 行が搭載RAM量です。この例では約 16GB（15.xGi と表示）ですので、shared_buffers の推奨値は 4GB です。

2. postgresql.confのshared_buffersを書き換える

作業前に設定ファイルをバックアップし、行頭の # を外して値を変更します。

# 作業前にバックアップを取る sudo cp /etc/postgresql/16/main/postgresql.conf /etc/postgresql/16/main/postgresql.conf.bak.$(date +%Y%m%d) # viで編集する sudo vi /etc/postgresql/16/main/postgresql.conf

変更箇所（行頭の # を外し、128MB を 4GB に書き換える）：

# 変更前（コメントアウトされている） #shared_buffers = 128MB # 変更後（# を外して値を変更する） shared_buffers = 4GB

3. PostgreSQLを再起動して反映する

shared_buffers はカーネルの共有メモリ領域を変更するため、pg_reload_conf では反映されず、サービスの再起動が必要です。

# PostgreSQLを再起動（RHEL 9 / Rocky Linux: サービス名に末尾バージョンが付く） sudo systemctl restart postgresql-16 # Ubuntu 24.04 の場合 sudo systemctl restart postgresql # 起動を確認する sudo systemctl status postgresql-16 # * postgresql-16.service - PostgreSQL 16 Database Server # Active: active (running) since ...

Active: active (running) が確認できれば起動成功です。

postgresql.conf のチューニングは、Linuxサーバー上でDBを安定運用するための実務スキルです。設定の根拠と反映手順を体系的に身につけたい方は、現役サーバー管理者が直接指導するハンズオンセミナーで最短ルートを。

2日間ハンズオンで実務レベルへ＞＞ Linux Master Pro Seminarの詳細を見る

work_memの設定値を計算して反映する手順

1. work_memが倍増する仕組みを理解する

work_mem は「1つのソート処理あたり」に割り当てられるメモリです。1つのSQLクエリの中に ORDER BY・GROUP BY・ハッシュ結合が含まれていれば、1接続でwork_mem × 複数ノード分が消費される可能性があります。並列クエリが動いていればさらに倍になります。

計算式の出発点は次のとおりです。

work_mem（MB）≒ 搭載RAM（MB）× 0.10 ÷ max_connections

RAM 16GB・max_connections 100 の場合：
16,384MB × 0.10 ÷ 100 ＝ 約16MB

これを出発点として、集計クエリが多いOLAP用途なら32MB～64MB まで上げ、小規模なOLTPサービスなら 8MB に抑えることも選択肢です。

2. postgresql.confのwork_mem・effective_cache_size・maintenance_work_memをまとめて変更する

# postgresql.conf を編集して3つをまとめて変更する # 変更前（いずれもコメントアウト状態） #work_mem = 4MB #maintenance_work_mem = 64MB #effective_cache_size = 4GB # 変更後（RAM 16GB の例） work_mem = 16MB maintenance_work_mem = 512MB effective_cache_size = 12GB

3. pg_reload_confでリロードして反映する（再起動不要）

work_mem・maintenance_work_mem・effective_cache_size は postgresql.conf を書き換えた後、サービスを再起動せずに反映できます。


# OSコマンドでリロード（再起動不要）
sudo systemctl reload postgresql-16

# または psql から pg_reload_conf() を実行する
psql -U postgres -c "SELECT pg_reload_conf();"

 pg_reload_conf
----------------
 t
(1 row)

戻り値が t（true）であればリロード成功です。

設定値の確認方法（SHOW文・pg_settingsビュー）

1. SHOW文で個別に確認する


psql -U postgres

postgres=# SHOW shared_buffers;
 shared_buffers
----------------
 4GB
(1 row)

postgres=# SHOW work_mem;
 work_mem
----------
 16MB
(1 row)

2. pg_settingsビューで4つをまとめて確認する


postgres=# SELECT name, setting, unit, context
  FROM pg_settings
  WHERE name IN (
    'shared_buffers',
    'work_mem',
    'effective_cache_size',
    'maintenance_work_mem'
  )
  ORDER BY name;

         name          | setting |  unit  |  context
-----------------------+---------+--------+-----------
 effective_cache_size  | 1572864 | 8kB    | user
 maintenance_work_mem  | 524288  | kB     | user
 shared_buffers        | 524288  | 8kB    | postmaster
 work_mem              | 16384   | kB     | user
(4 rows)

context 列が postmaster のパラメータは再起動が必要、user は pg_reload_conf で反映できることを示しています。shared_buffers が postmaster になっていることを確認しておきましょう。

RAMごとの設定値早見表

サーバーのRAM量別の推奨値をまとめます。いずれも初期値であり、実際のワークロードに合わせて調整してください。

パラメータ	RAM 8GB	RAM 16GB	RAM 32GB	反映方法
shared_buffers	2GB	4GB	8GB	再起動
work_mem	8MB	16MB	32MB	リロード
effective_cache_size	6GB	12GB	24GB	リロード
maintenance_work_mem	256MB	512MB	1GB	リロード

よくあるトラブルと対処法

「cannot allocate memory」エラーでPostgreSQLが起動しない場合

shared_buffers を大きくし過ぎると、起動時に共有メモリの確保に失敗してエラーになることがあります。

# journalctlでエラーを確認する sudo journalctl -xeu postgresql-16 --no-pager | tail -30 # 出力例（shared_buffersが大きすぎる場合） FATAL: could not create shared memory segment: Cannot allocate memory DETAIL: Failed system call was shmget(key=5432001, size=4299161600, 03600).

対処法：
・shared_buffers を RAM の 25% に戻す（40% 以上は避ける）
・sysctl kernel.shmmax を確認し、shared_buffers より大きい値か確認する
・スワップ領域が不足している場合はスワップを追加する

変更後もSHOWで古い値が返ってくる場合

shared_buffers を変更したのに SHOW shared_buffers が 128MB のままの場合は、shared_buffers の変更には pg_reload_conf ではなく再起動が必要なのに、リロードしか実行していないケースがほとんどです。

# shared_buffers は再起動が必要。systemctl restart で反映させる sudo systemctl restart postgresql-16 # 再起動後に再確認する psql -U postgres -c "SHOW shared_buffers;" shared_buffers ---------------- 4GB (1 row)

また、postgresql.conf の変更行に # が残ったままコメント状態になっているケースも多いです。vi で再確認して、行頭の # が外れているかを確認してください。

本記事のまとめ

postgresql.conf のメモリチューニングで変更するパラメータと要点をまとめます。

パラメータ	目的	計算式の目安	反映方法
shared_buffers	DB共有バッファキャッシュ	RAM ÷ 4（25%）	systemctl restart
work_mem	ソート・ハッシュ結合の作業領域	RAM × 10% ÷ max_connections	pg_reload_conf
effective_cache_size	プランナーへのキャッシュヒント	RAM × 60～75%	pg_reload_conf
maintenance_work_mem	VACUUM・INDEX構築の作業領域	256MB～1GB	pg_reload_conf

変更後は SHOW パラメータ名 または pg_settings ビューで必ず反映を確認し、pg_stat_bgwriter や pg_stat_database でキャッシュヒット率をモニタリングする習慣をつけると、さらに精度の高いチューニングが行えます。

postgresql.confの設定が固まったら、次はLinuxサーバー運用の「型」を体系的に身につけませんか？

DBチューニングも含め、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒）＞＞図解60P'Linux入門マニュアル'を受け取る

※ 「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。