sakamoto
sakam****@ma*****
2007年 10月 11日 (木) 19:04:44 JST
こんにちは、坂本です。 加納さん、ありがとうございます。 > こんばんは 加納です。 > > > ・マシン起動後の一回目の検索が1分10秒くらいかかるが、 > > マシン起動後の初回クエリでしょうか？まだ、IOが発生していなかった > ところに初めてIOが入るので、キャッシュヒット率が極めて低いものと > 思われます。ヒット件数はどれくらいでしょうか。マシンのおおよその > 構成は？この時間は単独で実行時でしょうか？ まず、マシン起動後の初回クエリが遅いです。 ヒット件数は、20万件です。（全体でも20万件ほどです） マシンの構成は、 OS：WindowsXP CPU：Core2 DUO 1.066GHz メモリ：1.5GB HDD：80GB ノートPCなのでHDDの回転数は遅いと思います。 5400rpm or 4200rpm 単独実行です。 > > どれだけ意味があるかは分かりませんが、単純な計算としては以下が成り > 立ちます。 > １ランダムIOに8msecとする。 > ヒット件数は1万件 > →IO時間は80000msec＝80sec > 母体が大規模で、満遍なく分散された行がヒットする場合、件数によっ > ては大きな時間が要することは想定されます。 > > > 二回目以降の検索は、9秒程度と一回目が極端に遅い。 > > 同一クエリを実行された場合、二回目以降は、PostgreSQLの共有バッファ > に乗っている可能性がありますので、その場合は当然早くなります。 > 一回目のクエリ実行時と二回目のクエリ実行時にIOの発生がどうなってい > るのかパフォーマンスモニター等でご確認ください。おそらく実IOが減少 > しているものと思います。 sennaのインデックスもPostgreSQLの共有バッファに乗るのでしょうか？ PostgreSQLを再起動後（マシン再起動ではない）も速いので、 PostgreSQLの共有バッファは関係ない？ とすればsennaかな？ とも思っています。その場合は、仮想メモリ？ 実際に運用する場面では、マシン起動後に、一度クエリを投げておく などで回避しなければならないのかと考えていますが、その場合、 どのようなクエリが効果的かなどと考えています。 また、フラッシュされない方法があるのなら、その方法も ご教授いただければと思います。 > > > ・初回検索後も、別のキーワードで検索すると、遅い場合がある。 > > これも、別の行の検索になったので、また実IOが出たと考えれば説明がつ > きます。 > > > ・しばらく（８時間）ほど放置すると、一回目と同じく遅くなる。 > > これも同様に共有バッファからフラッシュされてしまったので、再度実IO > が発生したと思われます。 > > このあたりの統計データを取得されると、PostgreSQLの挙動としても分かる > と思います。 > http://www.postgresql.jp/document/pg824doc/html/monitoring-stats.html#MONITO > RING-STATS-VIEWS > > _______________________________________________ > Ludia-users mailing list > Ludia****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/ludia-users
