[pgsql-jp: 29360] Re: パフォーマンス向上策

Yoshihiro Hanahara hanahara @ meiko.co.jp
2003年 3月 10日 (月) 13:23:01 JST


花原@明宏です

On Sun, 09 Mar 2003 18:21:32 +0900
SAITO Masaru <daisaito @ lares.dti.ne.jp> wrote:

>> > > > PostgreSQL内部では1テーブル1ファイルになっているものと思われます。
> > > > # $PG/data/base/[DB名]/ 以下をのぞいてみただけですので、
> > > > # これを別のところで管理しているとしたら外しています。
> > > > でもって、同じディレクトリの中に数万ものファイルがあると
> > > > 各ファイルにアクセスするのにものすごく時間がかかります。
> > > > たぶん、indexを張るのも無駄だと思います。
> > 
> > これは本当なのでしょうか?
> 
> 以下の検証結果も含めてファイルシステムに依存していると思うのですが。。
> 永安さんの環境と小泉さんの環境が一緒なら何も言いませんが。
> (少なくともファイルシステムが一緒である必要があります)
> 私の経験上、スライス(パーティーション)へのファイル容量に対する
> inode数が少ない場合はファイルを*ダイレクト*に指定してopenする
> 場合も遅かったと記憶しております。

ファイルシステムと、そのi-node探索アルゴリズムに依存するとは思いますが、
1つのディレクトリに沢山ファイルがあれば遅くなるのは一般的に事実だと思い
ます(絶対パスだと、それだけ沢山のディレクトリエントリを経由することにな
ります。ただし、2回目以降はメモリに読み込み済みになっている確率が高くな
りますが)。
永安さんの場合、実際にディスクブロックを読んだのではなく、メモリに読み込
まれているディレクトリファイルを読んでいることになると思うので、低負荷時
では、あまり差が分からなかったのではないかと思われます(高負荷時だと、ディ
レクトリファイルのブロックがメモリから追い出されてしまっている場合が
多くなります。つまりディスクのヘッドが動く可能性が高くなると...)。

ただ、このオーバーヘッドよりも、DBにテーブルが4万もあって、
それを1つ(or一連の)クエリーが走ることにより、4万ものファイルのオープン・
クローズが発生してしまうことの方がはるかに重いのと思います。

1つのプロセスがオープンできるファイルの数は有限ですし、PostgreSQLが使う
共有メモリも有限です。
すべてを同時にオープンできないので、オープン済みのファイルディスクリプタの
プールをキャッシュし、管理するコードがPostgreSQLの中にはあると思います
(コード見てないので憶測ですが...)。
これらの資源プールが溢れる要求が発生するので、ある閾値を境に、それらの追
い出し・読み込み・オープン・クローズが頻繁に起こり、スラッシング状態が発
生するのではないでしょうか(実メモリの少ないメモリで、大きな仮想メモリを
必要とするアプリを動かしたのと同じ状態になる)?

PostgreSQLのソースコードを調べたわけではないので、外しているかもしれませ
ん(^_^;)。


いずれにしても1つのデータベースに4万もテーブルがあり、それを全部舐めると
いうのが問題の根本です(かつ、そのテーブル数はどんどん増える)。


このあたりの限界値は、カーネルパラメータやpostgresql.confの設定値により
左右されますので、以下をチェックして、ゴニョゴニョやれば、ほんのちょっと
は改善し、時間稼ぎができるかもしれませんが...。

    <http://www.postgresql.jp/document/pg721doc/admin/kernel-resources.html>


---
Yoshihiro Hanahara <hanahara @ meiko.co.jp>





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