/
PostgreSQLメモリ計算機
スペック層PGバージョン

PostgreSQLメモリ計算機

PostgreSQLのメモリ設定計算およびPGTuneに基づくpostgresql.confパラメータを自動生成。shared_buffers、work_mem、effective_cache_size、max_connectionsを最適化します。

クイックプリセット:

ハードウェア構成仕様

ワークロード特性（Web・OLTP・DWH等）に応じた配分プロファイルを選択します

GB
1 GB16 GB64 GB128GB256 GB

利用可能な物理CPUコア数（またはvCPU数）を指定してください

ストレージ（NVMe・SSD・HDD）のI/O特性に応じた最適化プロファイルを選択します

接続
無効
アクティブバックエンド接続数100
基本プロセスオーバーヘッド1000MB
Huge Pages所要量4108
PostgreSQLメモリ最適化推奨構成（postgresql.conf）PostgreSQL 16 • NVMe SSD
# ----------------------------------------------------------------------
# PostgreSQL PostgreSQL 16 Performance Tuning Profile
# Generated by ToolsAA PostgreSQL Memory Calculator & PGTune Engine
# Host RAM: 32 GB | Cores: 8 | Storage: NVMe SSD
# Platform Regime: Linux Bare-Metal / VM | Workload: Web Application / High-Concurrency OLTP
# ----------------------------------------------------------------------

# ----------------------------
# Connectivity & Concurrency
# ----------------------------
max_connections = 100 # Active backend workers
superuser_reserved_connections = 3

# ----------------------------
# Memory & Cache Allocation
# ----------------------------
shared_buffers = 8GB # Hot page buffer pool
effective_cache_size = 24GB # Planner RAM estimate (Shared + OS Cache)
maintenance_work_mem = 1.6GB # Dedicated VACUUM & CREATE INDEX memory
work_mem = 98MB # Per sort/hash node memory
autovacuum_work_mem = -1 # Inherits maintenance_work_mem
huge_pages = try # Requires vm.nr_hugepages in /etc/sysctl.conf
temp_buffers = 16MB # Session-local temporary table memory

# ----------------------------
# Storage I/O & Query Planner
# ----------------------------
random_page_cost = 1.1 # Calibrated for NVMe SSD
seq_page_cost = 1.0 # Sequential disk block scan baseline
effective_io_concurrency = 300 # Prefetch asynchronous disk queues
default_statistics_target = 100 # Planner table sample resolution

# ----------------------------
# Checkpoints & WAL Journaling
# ----------------------------
checkpoint_completion_target = 0.9 # Spread checkpoint I/O over interval
checkpoint_timeout = 15min # Maximum duration between automatic checkpoints
min_wal_size = 4GB # Baseline recycled WAL buffer ring
max_wal_size = 32GB # Soft WAL ceiling before forced checkpoint
wal_buffers = 16MB # Ring buffer for unsaved WAL transactions
wal_compression = on # Lz4 or pglz compression to reduce disk I/O write amplification

# ----------------------------
# Parallel Query Execution
# ----------------------------
max_worker_processes = 8 # Maximum background and parallel workers
max_parallel_workers = 8 # Pool dedicated to parallel executor
max_parallel_workers_per_gather = 2 # Workers per single query plan node
max_parallel_maintenance_workers = 2 # Parallel index creation & VACUUM

# ----------------------------
# PostgreSQL Version-Specific Nuances
# ----------------------------
io_combine_limit = 256kB # PG16+ vectorized disk block read
track_io_timing = on # Monitor block read/write latencies
compute_query_id = on # Built-in query fingerprints for pg_stat_statements
shared_preload_libraries = 'pg_stat_statements' # Core query performance telemetry
クエリプランナ状態
ピーク時推定RAM使用量32.9GB
shared_buffers8GB共有バッファ（RAMの25%推奨）
work_mem98MBクエリ操作ごとの作業メモリ
OOMリスク103% Peak危険

ブラウザ内高速処理

すべての計算処理はブラウザのメモリ内で高速かつ安全に実行されます。

サーバー送信ゼロの安全性

入力データは完全にローカルで保持され、外部サーバーへの通信は一切行われません。

本番環境対応エクスポート

本番システムに即座に適用可能な、最適化された設定フォーマットを出力します。

※算出された設定値は一般的な推奨基準に基づく推定値です。本番環境へ適用する前に、必ず検証環境でワークロードに応じた負荷テストを実施してください。

技術リファレンス・アーキテクチャガイド

PostgreSQL Memory Calculator & PGTune Config ガイド — 技術リファレンス

PostgreSQLのメモリ設定を最適に計算し、PGTune互換のpostgresql.confパラメータを自動生成します。shared_buffers、work_mem、effective_cache_size、max_connectionsなどの重要パラメータを体系的にチューニングします。

PostgreSQL Memory Calculator & PGTune Config ガイド — 技術リファレンス — クライアントサイド完全ローカル実行アーキテクチャ図
PostgreSQL Memory Calculator & PGTune Config ガイド — 技術リファレンス — クライアントサイド完全ローカル実行アーキテクチャ図

主要パラメータと設定項目

shared_buffersメモリサイズ文字列（例: 8GB、16GB）

PostgreSQLが共有データキャッシュとして使用する専用メモリ領域を設定します。Linux環境における推奨黄金比はシステム総RAM容量の25%です。40%を超えて設定すると、Linux OSのページキャッシュとの二重バッファリング（Double-Buffering）が発生し、逆にパフォーマンスが低下します。

初期値: 128MB（PostgreSQL出荷時のデフォルト値）
work_memメモリサイズ文字列（例: 32MB、64MB）

一時ディスクファイルへ書き出す前に、内部ソート処理やハッシュテーブル操作に使用する基準メモリ容量を指定します。極めて重要な点として、このメモリは接続（コネクション）ごとではなく、クエリ内のソート／ハッシュ操作ノードごとに割り当てられます。複数の結合（JOIN）を含む複雑なクエリでは、単一プロセス内でwork_memが同時に複数回確保されます。

初期値: 4MB
effective_cache_sizeメモリサイズ文字列（例: 24GB、48GB）

ディスクキャッシュとして利用可能な総メモリ容量（shared_buffers＋OSカーネルページキャッシュ）の推定値をクエリオプティマイザ（プランナ）に伝えます。物理メモリの割り当ては行いません。標準的な設定値は、データベース専用サーバーでシステム総RAMの75%、他サービスと共用するサーバーで50%です。

初期値: 4GB
maintenance_work_memメモリサイズ文字列（例: 1GB、2GB）

VACUUM、CREATE INDEX、ALTER TABLE ADD FOREIGN KEYなどの保守管理操作で使用する最大メモリ容量を指定します。推奨上限値はmin(2GB, 総RAMの5%)です。値を大きく設定するとインデックス再構築が大幅に高速化されますが、autovacuumワーカーのメモリ消費を適切に制御しないとホストメモリ枯渇を招く恐れがあります。

初期値: 64MB
max_connections整数値（10〜5000）

データベースへの同時直接クライアント接続数の上限を決定します。PostgreSQLは接続ごとに個別のOSプロセスをフォークするため、各接続が約10MBの基本RAMに加え動的なwork_memを消費します。PgBouncer等のコネクションプーラーを用いずに接続数を過大（300以上）に設定すると、深刻なCPUキャッシュスラッシングが発生します。

初期値: 100
checkpoint_completion_target小数・浮動小数点数（0.1〜1.0）

チェックポイント間隔のうち、ダーティな共有バッファページをディスクへ書き出す目標時間の割合を指定します。ベンチマーク上の標準値は0.9（90%）であり、チェックポイント期間全体に書き込みI/Oを均等に分散させて急激なI/Oスパイクやスタッター（瞬間停止）を抑制します。

初期値: 0.9（PostgreSQL 14以降。レガシーバージョンでは0.5）
wal_buffersメモリサイズ文字列（例: 16MB、64MB）

先行書き込みログ（WAL: Write-Ahead Logging）データをディスクに書き出す前に保持するバッファメモリです。通常はshared_buffersの3%（上限16MB）に自動調整されますが、大量データのバルクインジェストなど書き込み負荷が極めて高いワークロードでは64MBへの拡張が推奨されます。

初期値: -1（shared_buffersの3%に自動調整）
random_page_cost小数・浮動小数点数（1.0〜10.0）

シーケンシャルスキャン（seq_page_cost = 1.0）を基準とした、非連続（ランダム）ディスクページ読み出しに対するオプティマイザの推定コストです。NVMe SSDでは1.1、SATA SSDでは1.5に設定します。旧来の回転式HDD向けのデフォルト値4.0のまま放置すると、プランナがインデックススキャンを過大コストと誤認し、不要な全表走査（フルテーブルスキャン）を選択してしまいます。

初期値: 4.0
effective_io_concurrency整数値（0〜1000）

基盤となるストレージサブシステムが同時に処理可能な非同期ディスクI/O操作の数を指定します。NVMe/SATA SSD環境における最適な推奨値は200〜300です。一方、回転式メカニカルハードディスク（HDD）環境では2に留める必要があります。

初期値: 1（Linuxデフォルト値。0でプリフェッチ無効化）
huge_pages列挙型（'on'、'off'、'try'）

shared_buffersの割り当て時にLinuxの2MB HugePages（ヒュージページ）を要求するかどうかを制御します。32GB以上のRAMを搭載したサーバーでHugePagesを有効化すると、トランスレーション・ルックアサイド・バッファ（TLB: Translation Lookaside Buffer）ミスを大幅に削減し、ページテーブルの肥大化を防ぎ、CPUメモリアクセスのオーバーヘッドを最大15%削減できます。

初期値: try

現場のベストプラクティス・実践Tips

複数テーブル結合（JOIN）クエリにおけるwork_mem乗数トラップ

最大メモリ消費量を単に「max_connections × work_mem」で試算してはなりません。4つのハッシュ結合、2つのソート処理、1つのウィンドウ関数を含む複雑なSQLクエリを実行すると、単一のバックエンドプロセス内でwork_memが同時に7回確保されます。仮にmax_connectionsが200でwork_memが64MBの場合、最悪シナリオの消費メモリは12.8GBではなく89GBを超過し、LinuxのOOM Killerによる即座の強制終了（SIGKILL）を招きます。

shared_buffersをRAMの40%以上に設定すると性能が低下する理由

PostgreSQLはデフォルトでダイレクトI/Oを使用せず、OSカーネルキャッシュを経由してページを読み書きします。shared_buffersをRAMの60〜80%に設定すると、同一データページがPostgreSQLの共有バッファとLinuxページキャッシュの両方に重複して常駐する深刻な「二重バッファリング」が発生します。RAMの50〜75%をOSページキャッシュ用に空けておくことで、Linuxがインデックスファイルや一時ファイルを遥かに効率的にキャッシュできるようになります。

Postmaster強制終了を防ぐLinux vm.overcommit_memoryの厳格制御

デフォルトのLinuxはヒューリスティックなメモリオーバーコミット（vm.overcommit_memory = 0）を採用しています。物理RAMとスワップが枯渇した際、LinuxのOOM Killerは最もバッドネススコア（badness score）の高いプロセスを強制終了の標的に選びますが、これはほぼ確実にPostgreSQLのメインプロセス（postmaster）となります。本番環境では、事前に割り当てたHugePagesと併せてvm.overcommit_memory = 2およびvm.overcommit_ratio = 80を設定し、OOMクラッシュを根本から防止してください。

コネクションプーリングの崖: 直接1,000接続がスループットを破壊するメカニズム

PostgreSQLは接続ごとに独立したプロセスを生成するアーキテクチャ（process-per-connection）を採用しているため、1,000個のアクティブな直接接続を実行すると、CPUサイクルの40%以上がOSプロセスのコンテキストスイッチとL1/L2/L3キャッシュラインの無効化に浪費されます。PgBouncerをトランザクションプーリングモードで導入し、pool_size = 2 × CPUコア数 ＋ ディスクスピンドル数（例: 32〜64バックエンド接続）に設定することで、アイドル時のメモリオーバーヘッドをゼロに抑えつつ、クエリスループット全体を300〜500%向上させることができます。

ディスク書き込みストールを防止するチェックポイント頻度のチューニング

PostgreSQLで高頻度の書き込みトランザクションが発生すると、max_wal_sizeのデフォルト値1GBではcheckpoint_timeoutの設定時間を待たずに数秒ごとにチェックポイントが乱発されます。現代的なSSD環境ではmax_wal_sizeを16GBまたは32GBに引き上げ、checkpoint_completion_targetを明示的に0.9に設定してください。これによりディスクI/Oがチェックポイント期間の90%にわたって均等に平滑化され、急激なディスク書き込みボトルネックを回避できます。

よくある落とし穴とトラブルシューティング

⚠️Out of memory: LinuxカーネルのOOM Killerによってpostmasterプロセスが強制終了（Killed process）された

直ちにwork_memを削減するか、max_connectionsを引き下げてください。クライアント接続が無制限にバックエンドメモリを消費しないよう、コネクションプーラー（PgBouncer）を導入します。/etc/sysctl.confでvm.overcommit_memory = 2を設定し、緊急時の安全クッションとして物理RAMの50%以上のスワップ領域を確保してください。

⚠️FATAL: could not attach to shared memory segment: Cannot allocate memory（共有メモリセグメントにアタッチできない）

このエラーは、shared_buffersの設定値がOSカーネルのshmmaxまたはHugePagesの割り当て制限を超過した際に発生します。huge_pages = onを設定している場合は、「grep Huge /proc/meminfo」を実行し、HugePages_Free >= ceil(shared_buffers / 2048kB)を満たしているか確認してください。対処法としてhuge_pages = tryに変更するか、/etc/sysctl.confに「vm.nr_hugepages = [計算値]」を追記して「sysctl -p」を実行します。

⚠️SSD環境であるにもかかわらずPostgreSQLがインデックスを無視し、低速な順次走査（シークエンシャルスキャン）を実行する

デフォルトのrandom_page_costは4.0であり、これはランダムシークが順次読み出しの4倍遅い旧来の回転式ハードディスクを前提に調整された値です。NVMeやSATA SSDでは、ランダムアクセスによる機械的な遅延ペナルティは実質的に存在しません。postgresql.confでrandom_page_costを1.1（NVMe）または1.5（SATA SSD）に設定し、「SELECT pg_reload_conf();」を実行してインデックス走査の優先度を即座に正常化してください。

⚠️5分から15分ごとにクエリのレイテンシスパイク（一時的な応答遅延）が定期的に発生する

チェックポイント時の急激な書き込み処理によって、ダーティバッファが一斉にディスクへフラッシュされることが原因です。PostgreSQLのログに「checkpoints are occurring too frequently」が出力されていないか確認してください。checkpoint_completion_targetを0.9に設定して書き込みI/Oを平滑化し、max_wal_sizeをデフォルトの1GBから16GB以上に引き上げ、さらにcheckpoint_timeoutを15分または30分に延長します。

⚠️多数の「idle in transaction」接続が残留し、CPU使用率が高止まりしている

直接クライアント接続はアイドル状態であってもそれぞれ約10MBの常駐メモリを消費し、トランザクションスナップショットやメモリロックを保持し続けます。PgBouncerをトランザクションプーリングモードで導入してください。また、postgresql.confに「idle_in_transaction_session_timeout = '60s'」を設定し、放置されたクライアントトランザクションを自動的に強制終了させます。

よくある質問 (FAQ)

LinuxのOOM Killer発動を防ぐためのwork_memの適正な計算方法は？▼

work_memは次の計算式を用いて算出します: work_mem = ((総RAM容量 - shared_buffers) × (1 - OS予約比率)) ÷ (max_connections × クエリあたりの同時ソートノード数)。ここでOS予約比率は通常0.20（20%）、同時ソートノード数はOLTP処理で2、OLAP分析処理で4〜8程度を見込みます。work_memは接続単位ではなくソートやハッシュ操作ごとに割り当てられるため、OLTPワークロードではwork_memを16MB〜64MBの範囲に抑えることで、複数テーブル結合クエリによるメモリ枯渇とLinuxのOOM（Out-of-Memory）Killerの発動を確実に防止できます。

RAM容量が16GB、32GB、64GBのサーバーにおける推奨shared_buffers設定値は？▼

Linux環境におけるshared_buffersの推奨設定値は、システム総RAM容量の25%です。具体的には16GBサーバーで4GB、32GBサーバーで8GB、64GBサーバーで16GBとなります。PostgreSQLは最大40%までの設定をサポートしていますが、40%を超えて割り当てても性能向上はほとんど見込めず、OSカーネルのページキャッシュとの二重バッファリングによって深刻なパフォーマンス低下を引き起こすケースが多いため推奨されません。

shared_buffersとeffective_cache_sizeの決定的な違いは何ですか？▼

shared_buffersはPostgreSQLの起動時に実際の物理メモリを確保し、テーブルやインデックスの共有キャッシュページを保持します。一方、effective_cache_sizeは物理メモリを一切確保しません。クエリプランナ（オプティマイザ）が「shared_buffersとOSカーネルページキャッシュの合算でどれだけのデータがキャッシュされているか」を推測するための純粋な参照指標（アドバイザリ値）に過ぎません。標準的な設計では、ホスト総RAMの50%〜75%を目安に設定します。

空きRAMが存在するように見えるにもかかわらず、PostgreSQLがメモリ不足（Out of Memory）でクラッシュするのはなぜですか？▼

バックエンドクエリが要求したメモリ量がカーネルのオーバーコミット上限を超過した場合や、メモリの断片化（フラグメンテーション）によって連続した共有メモリセグメントが確保できなくなった場合に発生します。さらに、Linuxのデフォルトであるメモリオーバーコミット（vm.overcommit_memory = 0）が有効な場合、カーネルは物理的に存在する以上の仮想メモリ割り当てを許可します。プロセスがそれらのページに実際に書き込みを行った瞬間、メモリ不足を検知したOOM Killerがpostmasterプロセスに対して即座にSIGKILLを発行し、データベースクラスタ全体をクラッシュさせます。

PostgreSQLのmax_connectionsはいくつに設定すべきですか？▼

データベースへの直接接続（max_connections）は、理想的には100〜200程度に制限すべきです。PostgreSQLは接続ごとに個別のOSプロセスを割り当てる構造のため、アクティブな直接接続が200〜300を超えると、激しいCPUコンテキストスイッチと内部ロック競合が発生します。数百〜数千の同時クライアント接続を要するアプリケーションでは、PgBouncer等のコネクションプーラーをトランザクションモードで導入し、pool_sizeを「2 × CPUコア数 ＋ スピンドル数」に設定することで、数千のクライアントセッションをわずか20〜50個のアクティブなバックエンドプロセスで効率的に処理できます。

Linux環境のPostgreSQLでHugePagesを有効化すべきですか？▼

はい、32GB以上のRAMを搭載した本番データベースでは常にHugePages（ヒュージページ）を有効化すべきです。標準的なx86_64 Linuxのメモリページサイズは4KBであるため、大容量のshared_buffersを確保すると数百万ものページテーブルエントリが必要となり、ページテーブル自体がメモリを圧迫してTLB（Translation Lookaside Buffer）ミスが頻発します。Linuxの2MB HugePagesを利用することでページテーブルのオーバーヘッドを512分の1に削減でき、クエリスループットが5%〜15%向上するほか、共有メモリ割り当て失敗によるクラッシュを防止できます。

NVMeおよびSATA SSDストレージにおけるrandom_page_costの推奨設定値は？▼

基準となるseq_page_cost（1.0）に対し、NVMe SSDでは1.1、SATA SSDでは1.5に設定します。デフォルト値の4.0は何十年も前の回転式磁気ハードディスク（HDD）向けに定められたものであり、機械的なヘッドのシーク遅延を前提としています。SSDストレージ環境で4.0のまま運用すると、PostgreSQLのクエリプランナがインデックス走査のコストを過大評価し、高速に処理できるはずの検索において不要な全表走査（シーケンシャルスキャン）を誤って選択してしまいます。

maintenance_work_memとautovacuum_work_memの違いは何ですか？▼

maintenance_work_memはCREATE INDEXやVACUUM FULLなどの手動管理コマンドに割り当てるメモリ容量を定義し、一般的に1GB〜2GB程度に設定します。一方、autovacuum_work_memはバックグラウンドで動作する各autovacuumワーカープロセス専用のメモリ上限を指定します。autovacuum_work_memをデフォルトの-1（maintenance_work_memの値を継承）のままにしておくと、autovacuum_max_workers = 3の場合に3つのワーカーが同時に最大6GBのメモリを消費し、ホストメモリを逼迫させる危険があります。autovacuum_work_memを明示的に個別設定（例: 512MB）することで、通常のクエリ処理に影響を与えずに安全な自動バキューム運用が可能になります。

関連開発者ツール

全ツール一覧 →
RAID容量計算（ZFS対応）開発者ツール

RAID 0/1/5/6/10/50/60およびZFS（RAIDZ1/Z2/Z3）構成の実効容量を十進法TB・二進法TiBで正確に計算。パリティ損失、URE（回復不能読み取りエラー）によるリビルド失敗リスク、再構築所要時間、ドライブベイ配置の可視化に対応した高精度ストレージ設計ツールです。

ツールを開く→
ABテスト サンプルサイズ計算開発者ツール

A/Bテストに必要なサンプルサイズ、統計的検定力、所要期間を高精度に計算。最小検出効果（MDE）の逆算、売上等の連続値指標、多群ボンフェローニ補正、サンプル比率の不整合（SRM）検証に対応。

ツールを開く→
PX・REM変換ツール開発者ツール

ルートフォントサイズを基準にPXとREMを即座に相互変換。CSS clamp()流体タイポグラフィ、Tailwindクラス、対照表を自動生成します。

ツールを開く→
HTTPステータスコード確認開発者ツール

HTTPステータスコードの確認、リダイレクトチェーン（多段転送）の追跡、レスポンスヘッダーの解析をリアルタイム実行。1xx〜5xxのエラー原因、RFC仕様、SEO検索評価への影響、復旧手順をブラウザ完結で診断します。

ツールを開く→
正規表現チェッカー＆検証開発者ツール

正規表現のパターン一致、キャプチャグループ、構文トークン解説、置換処理をリアルタイムに検証・デバッグ・最適化します。

ツールを開く→
サブネット計算・CIDR範囲開発者ツール

IPv4サブネットマスク、CIDRネットワーク範囲、利用可能ホストIP、ブロードキャストアドレスを計算。ビット単位バイナリ検証、VLSM計画、クラウドVPC規則に対応。

ツールを開く→