[pgsql-jp: 36081] Re: ramdisk上のtablespaceの効果
Morita Kazuro
morita @ yuki.ad.jp
2005年 10月 3日 (月) 16:03:51 JST
森田です。
水野様、早速返事をくださり、ありがとうございます。
すいません、質問で現在の
shared_buffers = 10000
をかいておくべきでした。これがわからないとお答えいただけませんよね。
また、全体のメモリは2Gです。
で、メモリをさらに4Gに増やそうかという話になっていまして、
増やしたメモリをどう使うかという話でした。
----- Original Message -----
From: "Kiyoshi Mizuno" <kiyoshi_mizuno @ mail.toyota.co.jp>
To: "'PostgreSQL Japanese Mailing List'" <pgsql-jp @ ml.postgresql.jp>
Sent: Monday, October 03, 2005 1:58 PM
Subject: [pgsql-jp: 36077] Re:ramdisk上のtablespaceの効果
> 水野です。
>
> > -----Original Message-----
> > で、質問ですが、ramdisk を使うのと、その領域を shared_buffers にするのでは、どちらが
> > 高速化を期待できるのでしょうか?
>
> 今回のケースはURLの一時記憶という事ですので、テーブル全体がメモリ上に
> ある必要は無く、比較的直近に参照/更新されたレコードだけがメモリ上に
> あればシステムのレスポンスは維持できるのではないかと思います。
>
> データの格納領域をRAMDISKにしても、読み込む際には一度 shared_buffers に
> 転送されます(書き込む際も shared_buffers に格納された後、遅延書込される)。
> それを考えるとアプリケーションに対して十分な shared_buffers が確保できれば
> 記憶域自体はHDDでもよいのではないかと思います。
> (該当テーブルのディスクI/Oの量を測定するにはマニュアル23章にあるように
> stats_* で統計情報を収集してやる必要があります。それで該当テーブルの
> READキャッシュが効いていればOKだと思います。)
>
> ただ谷田さんが [pgsql-jp: 36070] Re: 検索系システムのパフォーマンスについて
> で書かれているように単純に shared_buffers を増やせばそれでよいというものでも
> ないようですから、現在の shared_buffers 値がすでに十分大きいならば
> ディスクI/O自体を高速化するためRAMDISK化したほうが効果が出るでしょう。
> #最近あまり聞きませんが「シリコンディスク」ってどうなんでしょうね。
>
pgsql-jp メーリングリストの案内