共有バッファとして確保されたメモリサイズの確認（Linux）

PostgreSQL の共有バッファ

PostgreSQL では、テーブルやインデックスのデータは「共有バッファ」と呼ばれるメモリ領域にキャッシュされます。この仕組みにより、ディスクアクセスを減らし、高速なデータ処理が可能になります。

共有バッファのサイズは、PostgreSQL の設定パラメータ shared_buffers で指定します。PostgreSQL は起動時に、shared_buffers に指定されたサイズ分のメモリを確保し、共有バッファとして使用できるようにします。そのため、PostgreSQL を起動しただけで、設定したサイズ分のメモリがシステムから予約されるイメージです。

shared_buffers の詳細については、公式ドキュメントも合わせて参照してください。

【 PostgreSQL 17.0文書 - 19.4. 資源の消費 - 】
https://www.postgresql.jp/document/17/html/runtime-config-resource.html#GUC-SHARED-BUFFERS

Linux で共有バッファとして確保されたメモリサイズを確認する方法

通常、Linuxシステムでメモリ使用量を確認する際は、top コマンドや free コマンド、ps コマンドを使用します。しかし、これらのコマンドでは、実際に利用中のメモリ量しか確認できません。つまり、確保されているものの、実際にはまだ使用されていないメモリ領域については、top コマンドなどでは確認できないということです。

このような「確保されているが、まだ利用されていないメモリ領域」を知りたい場合は、/proc/meminfo の「Committed_AS」を確認します。

/proc/meminfo の Commited_AS について

Committed_AS は、カーネルがアプリケーション（プロセス）に対して「提供することを約束した仮想メモリの合計サイズ」を示しています。実際に物理メモリとして割り当てられているかどうかに関わらず、全てのアプリケーションが確保を要求した量を把握できます。

実際に検証して確認

では、いつものように実際に検証して確認します。

検証に利用した環境

検証に利用した環境は以下となります。

• RockyLinux 9.6
• PostgreSQL 17.5

PostgreSQL を起動して Commited_AS を確認

まずは、PostgreSQL 起動前の状態を確認します。

# メモリの利用状況を確認（PostgreSQL 起動前）
$ free -g
               total        used        free      shared  buff/cache   available
Mem:              15           0          13           0           1          14
Swap:              1           0           1

$ grep Committed_AS /proc/meminfo
Committed_AS:     193368 kB

上気の通り、PostgreSQL 起動前にはメモリの使用量は 1 GB 未満であることを確認できました。
次に PostgreSQL を起動して、メモリの利用状況が変動するかを確認します。

# PostgreSQL の起動
$ pg_ctl start
waiting for server to start....2025-07-11 08:13:02.805 UTC [40367] LOG:  redirecting log output to logging collector process
2025-07-11 08:13:02.805 UTC [40367] HINT:  Future log output will appear in directory "log".
 done
server started

# shared_buffers のサイズ確認
$ psql -c "SHOW shared_buffers"
 shared_buffers 
----------------
 4GB
(1 row)

shared_buffers に 4 GB を設定した状態で、PostgreSQL を起動しました。
この状態でメモリの利用状況を確認します。

# メモリの利用状況を確認（PostgreSQL 起動後）
$ free -g
               total        used        free      shared  buff/cache   available
Mem:              15           0          13           0           1          14
Swap:              1           0           1

$ grep Committed_AS /proc/meminfo
Committed_AS:    4552036 kB

想定通り、free の used は 1 GB 未満ですが、Commited_AS には 4 GB 強のメモリサイズが増加していることを確認できました。

物理メモリサイズ以上の値を shared_buffers に設定した場合（蛇足な検証）

確保できないメモリサイズを shared_buffers に指定して、PostgreSQL を起動した場合の挙動を確認します。
結論から先に言いますと、PostgreSQL の起動時にメモリを確保できなかった場合には、エラーが発生し起動できません。
検証サーバの物理メモリのサイズは 16 GB ですので、shared_buffers に 32 GB を指定して PostgreSQL を起動しようとすると、下記のようになります。

# 物理メモリ 16 GB で、shared_buffers に 32 GB を指定して起動
$ pg_ctl start
waiting for server to start....2025-07-11 08:20:13.849 UTC [40427] FATAL:  could not map anonymous shared memory: Cannot allocate memory
2025-07-11 08:20:13.849 UTC [40427] HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 35206660096 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing "shared_buffers" or "max_connections".
2025-07-11 08:20:13.850 UTC [40427] LOG:  database system is shut down
 stopped waiting
pg_ctl: could not start server
Examine the log output.

メモリが足りないので PostgreSQL が起動できないのは当然と言えば当然な挙動です。
今回は分かりやすく物理メモリ以上のメモリサイズを shared_buffers に指定しましたが、PostgreSQL の他にメモリを消費するアプケーションなどが同一サーバ上に稼働している場合など、物理メモリの範囲内であっても PostgreSQL 起動時にメモリが確保できなければ同様の挙動になります。

まとめ

以上が Linux で、共有バッファとして確保されたメモリサイズの確認方法となります。
top コマンドなどで「実際に使用されているメモリ」を確認し、/proc/meminfo から「確保されているが未使用のメモリ」を把握することで、より精度の高いメモリ監視ができると思います。