kousa****@nttda*****
kousa****@nttda*****
2007年 10月 12日 (金) 15:46:52 JST
幸坂です。こんにちは。 > とすれば、PostgreSQLもsennaもどちらも影響の原因になると > いうことでしょうか。 そうですね。 > type *.SEN.* > nul > を実行しても、結果的には変わりませんでした。 > うまくOSのキャッシュに乗らないのか、乗ってもそれを使ってくれないのか？ Sennaのインデックスファイルの容量はどのぐらいですか？ 合計でOSのキャッシュを超えていませんか？ *.SEN.i.cはキャッシュに乗せてもあまり効果がありません。 それ以外をキャッシュに乗せると効果が出ます。 こちらの環境では、*.SEN.i.c以外をキャッシュに乗せ、 さらにSELECT COUNT(*) FROM tab;を実施しておけば、 初回検索時であっても、十分高速な検索になりました。 > -----Original Message----- > From: ludia****@lists***** > [mailto:ludia****@lists*****] On Behalf > Of sakamoto > Sent: Friday, October 12, 2007 12:46 PM > To: ludia****@lists***** > Subject: [Ludia-users 113] Re:一回目の検索が遅い件 > > こんにちは、坂本です。 > > 幸坂さん、ありがとうございます。 > > 簡単に確認しましたので、ご報告します。 > > > 幸坂です。こんにちは。 > > > > > まず、マシン起動後の初回クエリが遅いです。 > > > ヒット件数は、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 > > _______________________________________________ > Ludia-users mailing list > Ludia****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/ludia-users >
