sakamoto
sakam****@ma*****
2007年 10月 12日 (金) 12:46:00 JST
こんにちは、坂本です。 幸坂さん、ありがとうございます。 簡単に確認しましたので、ご報告します。 > 幸坂です。こんにちは。 > > > まず、マシン起動後の初回クエリが遅いです。 > > ヒット件数は、20万件です。（全体でも20万件ほどです） > つまり、全件ヒットですね。 > SELECT COUNT(*) FROM tab; →（SQL1)とします > と > SELECT COUNT(*) FROM tab WHERE col @@ '??????'; →（SQL2)とします [ケース１] マシン起動→SQL1→SQL2 SQL1,SQL2共に遅い。 [ケース２] マシン起動→SQL2→SQL1 SQL2は遅いが、SQL1は速い SQL2のパターンも、PostgreSQLのデータ参照しているということでしょうか。 とすれば、PostgreSQLもsennaもどちらも影響の原因になると いうことでしょうか。 > が同じぐらいの時間でしたら、PostgreSQLが律速段階ですね。 > Ludia, Sennaは関係ありません。 > postgresql.confのshared_buffersなどを変更したり、 > 初回起動時にSELECT COUNT(*) FROM tab;でDBのデータを > キャッシュに置けば解決できると思います。 > > 後者が格段に遅いようでしたら、Ludia周りが原因です。 > cat *.SEN.* > /dev/null > などを初回起動前に実行しておけば、SennaのインデックスがOSの > キャッシュに乗るので、高速になる可能性があります。 > （上記のコマンドはLinuxの場合。Winではtype *.SEN.* > nul かな。） type *.SEN.* > nul を実行しても、結果的には変わりませんでした。 うまくOSのキャッシュに乗らないのか、乗ってもそれを使ってくれないのか？ > > > > 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 > > > > _______________________________________________ > Ludia-users mailing list > Ludia****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/ludia-users
