[pgsql-jp: 26127] Re: メモリの有効利用

[Hiroki Takada]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

高田と申します．

こんにちは．

> initialize は -s 100 で行い、テストは -t 100 -c 100 で行っています。
> pgbench 自体は別のマシンで network ごしに実行させています。またキャッ
> シュの影響を考え、複数回実行して結果が安定したところを調べています。

- ----snip----

> らでの実験では、shared_buffers = 512 (共有メモリ 4Mbytes) とした時
> よりも、例えば shared_buffers = 65535 (共有メモリ 512Mbytes) とし
> た時の性能がどうしても高くなりません。物理メモリはまだ 3Gbytes 以上
> も余っています。
> 
> 前者に対して後者の方が、確かに I/O は劇的に減っているように見えますが、
> TPC の数値は１割から２割、下まわってしまいます。もっとも前者でも iostat
> で見るバス占有率は 100% とはならないのですが…。
>

- ----snip----
 
> 上記文書とは違い、shared_buffers の量はメモリの許す限り増やせばいい、
> というものではないのでしょうか。どこかにトレードオフがあるのでしょうか？
> 均衡点を見つけ出すには、どうやって調査すれば良いか、ご存じの方はいらっ
> しゃいますか？
>

まずwal_sysnc_methodについて，最適な方法を見つける必要があると思います
が，確認されましたでしょうか．
一説では，Solarisの場合は，fdatasyncが最も良いとの話ですが，私はSPARC
マシンを持っていないので，確認したことがありません．
スケーリングファクタを小さくしてから，それぞれの方法を比較してみては，
いかがでしょうか．

それで，本題のshared_buffersとパフォーマンスの関係ですが，結果を素直
に受け止めると，4MB以上必要ないのか，4MB〜512MBのどこかに最も良いとこ
ろがあるのかのどちらかでしょうね(実際マニュアルの計算式では4MBも必要
ないようです)
これは，指数的にパラメタを変えるなどして，プロットするしか無いような，
気がします．

あまりお役に立てませんが．

では，

- -- 
 ----------------------------------------------------
|   高田 浩生 (Hiroki Takada/takada ＠ rh.xdsl.ne.jp)   |
|                                                    |
|   My public key is available at the public key     |
|   servers. The message was signed as iso-2022-jp   |
|   char-set document in no PGP/MINE (RFC 2015)      |
|   format.                                          |
 ----------------------------------------------------


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: KUHASIKU WA http://www.gnupg.org/ WO GORANKUDASAI

iD8DBQE87lMvyTl8Jc+E3sERAuSVAJsEOuDJmdOI9Qdr3RMnPSxBh58ZXACbBo73
yj9kgnUXjg6tyzcRG3/62k4=
=FHbp
-----END PGP SIGNATURE-----