[pgsql-jp: 34586] PostgreSQLメモリサイジング

EBIHARA, Yuichiro ebihara @ iplocks.co.jp
2005年 1月 5日 (水) 16:12:13 JST


こんにちは、海老原です。

PostgreSQLによって消費されるメモリ量の計算式を探しています。
どなたか知っていればぜひとも教えていただきたく。

以下はOracleにおけるアプローチを自分なりにPostgreSQLに適用してみようと、
Red Hat Linux 9上のPostgreSQL 7.3.4で試してみたものです。

PostgreSQL関連プロセスとしては、postmasterとpostgresの2つを考えます。た
だしpostmasterはpostgresへのシンボリックリンクなので、実質postgresのみ。
psqlなどのクライアントプロセスは今回の見積もりの対象外です。

長文になってしまって恐縮ですが、お気づきの点があればご指摘いただけるとう
れしいです。

■各プロセスが共有するメモリ領域
(1)共有メモリ
(2)postgres(postmaster)のテキストセグメント
(*)共有ライブラリのテキストセグメント

共有ライブラリについては、ldd /usr/bin/postgres で見る限り、PostgreSQL以
外でも使われそうなライブラリばかりなので、無視することにします。

■各プロセスがプライベートに確保するメモリ領域
(3)データセグメント
(4)BSS
(5)共有ライブラリのデータセグメント
(6)共有ライブラリのBSS
(7)ヒープ
(*)スタック

スタックはそれほど大きくならないと思うので、無視することにします。

■総メモリ使用量の計算
データベースへの平均同時接続数を n とすると、PostgreSQLによって消費され
る総メモリ量は概ね以下のようになるはずです。
(安全な値を得たい場合は、n に max_connectionsを採用するべきかも)

総メモリ使用量
 = (1) + (2) + ( (3) + (4) + (5) + (6) + (7) ) * n

(1)共有メモリ
マニュアルに従えば、次の計算式により共有メモリサイズを計算できそうです。

共有メモリ(bytes) = shared_buffers * 8192
                  + wal_buffers * 8192
                  + max_fsm_pages * 6
                  + max_fsm_relations * 50

と思ったら、手元の環境ではipcsの結果と大幅にずれました。

shared_buffers                 | 512
wal_buffers                    | 8
max_fsm_pages                  | 10000
max_fsm_relations              | 1000

上記計算式では 4,369,840 bytesとなるはずが、ipcsでは 8,667,136 bytesと表
示されます。バッファ管理用の領域などが追加で確保されるんでしょうかね? 共
有メモリサイズについては実際にPostgreSQLを起動して、ipcsなどで実サイズを
測るのがよさそうです。

(2)postgres(postmaster)のテキストセグメント
sizeコマンドより取得します。
例えば以下の場合は1896553 bytes。

$ size /usr/bin/postgres
   text    data     bss     dec     hex filename
1896553   33772  233476 2163801  210459 /usr/bin/postgres

(3)データセグメント
(4)BSS
(5)共有ライブラリのデータセグメント
(6)共有ライブラリのBSS
これらは(2)と同様にsizeコマンドで取得可能です。が、後述の理由により、こ
れはやらなくてもいいかもしれません。

(7)ヒープ
ソート領域などが確保されるはずだが、サイズが可変なので厳密な計算は難しい
ですね。
結局、PostgreSQLをある程度動かしている状態で各postgresプロセスに対して
pmapを実行すると、最終行に以下のような出力が得られるので、

mapped:   14544 KB writable/private: 768 KB shared: 8464 KB

"writable/private"の平均値を総メモリ使用量の計算式の
(3) + (4) + (5) + (6) + (7) として採用するのが楽チンで、それなりに現実的
な値が得られるような気がします。

最後に上記までで計算した総量に対して2割〜3割の安全率を見込めば、無視した
スタック領域も吸収できて、それなりに妥当なメモリサイジングができるのでは
ないかと思っています。

いかがなものでしょう?

-- 
アイピーロックス ジャパン株式会社

海老原 雄一郎 / EBIHARA, Yuichiro
  Email: ebihara @ iplocks.co.jp






pgsql-jp メーリングリストの案内