kousa****@nttda*****
kousa****@nttda*****
2007年 10月 12日 (金) 09:38:54 JST
幸坂です。こんにちは。 > まず、マシン起動後の初回クエリが遅いです。 > ヒット件数は、20万件です。（全体でも20万件ほどです） つまり、全件ヒットですね。 SELECT COUNT(*) FROM tab; と SELECT COUNT(*) FROM tab WHERE col @@ '??????'; が同じぐらいの時間でしたら、PostgreSQLが律速段階ですね。 Ludia, Sennaは関係ありません。 postgresql.confのshared_buffersなどを変更したり、 初回起動時にSELECT COUNT(*) FROM tab;でDBのデータを キャッシュに置けば解決できると思います。 後者が格段に遅いようでしたら、Ludia周りが原因です。 cat *.SEN.* > /dev/null などを初回起動前に実行しておけば、SennaのインデックスがOSの キャッシュに乗るので、高速になる可能性があります。 （上記のコマンドはLinuxの場合。Winではtype *.SEN.* > nul かな。） > sennaのインデックスもPostgreSQLの共有バッファに乗るのでしょうか？ PostgreSQLの共有バッファとは別です。 まずは、PostgreSQLとLudiaのどちらが原因なのか 問題の切り分けをする必要がありますね。 > -----Original Message----- > From: ludia****@lists***** > [mailto:ludia****@lists*****] On Behalf > Of sakamoto > Sent: Thursday, October 11, 2007 7:05 PM > To: ludia****@lists***** > Subject: [Ludia-users 109] Re:一回目の検索が遅い件 > > こんにちは、坂本です。 > > 加納さん、ありがとうございます。 > > > こんばんは 加納です。 > > > > > ・マシン起動後の一回目の検索が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-sta > ts.html#MONITO > > RING-STATS-VIEWS > > > > _______________________________________________ > > Ludia-users mailing list > > Ludia****@lists***** > > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > _______________________________________________ > Ludia-users mailing list > Ludia****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/ludia-users >
