各務 洋
kagam****@outwa*****
2017年 4月 19日 (水) 12:34:37 JST
お世話になります、各務です。 > 実践的に cat * > /dev/nullが使われているなら、今後 > わたくしもこれを使いたいと思います。 念のためですが、これはだいぶ限定的な状況で、選択的に使用している。 という点を重ねて申し上げたいのです。 これを定期実行化してしまうと、下記の点が出てきます。 前提としては、キャッシュする（捨てる）アルゴリズムの方が優秀です。 逆に必要とされているものが捨てられる可能性が上がります。 cron だと実行時の時点でキャッシュに乗り切れるかは分からないです。 DB用のファイルを、稼働中に外部から触るのは良い策ではないと思います。 そもそも、Disk I/O を下げたいのに上げちゃいます。 という点が挙げられます。 手動でちょっと結果が出たから、定期実行してみたら実稼働でダメなや〜つって 罠かも知れません。もちろん私はやりました（笑）。 想定としては、内山さんの全文検索に時間がかかる状況が、あるタイミングで 発生する点が気がかりなのでしょうか？ であれば、select.sql に全文検索を追加されてみるのはいかがでしょうか？ 理想は parser 通したら頻出になる語句がランダムだとより良い気がします。 これを定期的に回してそれでも失速するなら、やはりメモリが足りていない可 能性を疑います。 shared_buffers を下げるなど、Postgres が占有する物理メモリ量を下げてみ て、改善するか改悪になるか確認はできると思いますが、足りていない時は大抵 何やっても悪くなる方にしか結果が出ない気がします。 物理メモリを積み増した環境で確認できると良いですね。 ---- 各務 kagam****@outwa*****
