toshio_uchiy****@mirro*****
toshio_uchiy****@mirro*****
2017年 4月 20日 (木) 15:20:39 JST
各務様 お世話になります。内山と申します。 実践的な解説ありがとうございます。勉強になります。 わたくしも、cron で一時間に一回、次の select 文を実行していました。 #vi select.sh psql -f select.sql > /dev/null 2>&1 /dev/null #vi select.sql select count(*) from tablename; select count(*) from tablename where lower( colname ) like lower( '%apple%' ) 一回やって、うまくいくと cron で定期実行してみたくなりますね。 解説のメールは、かなり複雑な内容ですね。何か統一的な見解が だせるものというより、個々のケースにあたって少しでも良い結果が でるような打開策を見出していくというイメージです。 わたくしは、以前、自分で、分かち書きしたファイルから btree 索引を作って日本語高速検索（図書館蔵書検索）を作ってみたことが あるくらいです。それから、映像制作などをかじっていましたので、 全文検索についてもデータベースについても、常識がすっぽり 抜け落ちています。何かあったらご相談させていただければと思います。 今後ともよろしくお願いします。 -----Original Message----- From: groon****@lists***** [mailto:groon****@lists*****] On Behalf Of 各務 洋 Sent: Wednesday, April 19, 2017 12:35 PM To: 全文検索エンジンGroonga開発メーリングリスト Subject: [groonga-dev,04347] Re: Mroonga のテーブル格納について お世話になります、各務です。 > 実践的に cat * > /dev/nullが使われているなら、今後 > わたくしもこれを使いたいと思います。 念のためですが、これはだいぶ限定的な状況で、選択的に使用している。 という点を重ねて申し上げたいのです。 これを定期実行化してしまうと、下記の点が出てきます。 前提としては、キャッシュする（捨てる）アルゴリズムの方が優秀です。 逆に必要とされているものが捨てられる可能性が上がります。 cron だと実行時の時点でキャッシュに乗り切れるかは分からないです。 DB用のファイルを、稼働中に外部から触るのは良い策ではないと思います。 そもそも、Disk I/O を下げたいのに上げちゃいます。 という点が挙げられます。 手動でちょっと結果が出たから、定期実行してみたら実稼働でダメなや〜つって 罠かも知れません。もちろん私はやりました（笑）。 想定としては、内山さんの全文検索に時間がかかる状況が、あるタイミングで 発生する点が気がかりなのでしょうか？ であれば、select.sql に全文検索を追加されてみるのはいかがでしょうか？ 理想は parser 通したら頻出になる語句がランダムだとより良い気がします。 これを定期的に回してそれでも失速するなら、やはりメモリが足りていない可 能性を疑います。 shared_buffers を下げるなど、Postgres が占有する物理メモリ量を下げてみ て、改善するか改悪になるか確認はできると思いますが、足りていない時は大抵 何やっても悪くなる方にしか結果が出ない気がします。 物理メモリを積み増した環境で確認できると良いですね。 ---- 各務 kagam****@outwa***** _______________________________________________ groonga-dev mailing list groon****@lists***** http://lists.osdn.me/mailman/listinfo/groonga-dev
