ブログラの管理画面でブログを検索するときのプログラムが異常に遅いのです。そう、単純にブログ一覧からブログを検索するだけなのに、1分45秒くらいかかっちゃってる。昔から、余り速くは無かったんだけど、流石にかかりすぎだなぁと思ってとりあえずメモリを追加してみました。
今まで1GBだったのを4倍の4GBにしてみました。これで速くなるだろー、と思ってましたけど全然速くならねぇ～。って、当然当然。PostgreSQLのチューニングって言うか調整を全くしてないからねぇ。というわけで、postgresql.confをいじってみました。
まずはshared_buffersを32MB→128MBへ。んー、なんか全然いまいち。で、work_memを1MB→2MB、ヲヲー！激ハヤッ！ 95secだったのが15secまで速くなりました、そうですかそうでしたか－。で、順番が真逆ですがマニュアルで色々確認。
17.4. 資源の消費
17.4.1. メモリ
work_mem（integer）
一時ディスクファイルに切替える前に、内部並べ替えとハッシュテーブル操作が使用するメモリ容量を指定します。値はキロバイト単位で、デフォルトは1024キロバイト（1メガバイト）です。複雑な問い合わせの場合、いくつかの並び替えもしくはハッシュ操作が並行して実行されることに注意してください。それぞれは、データを一時メモリに置く以前にこの値が指定したと同じ大きさのメモリ使用が認められます。さらに、いくつかの実行中のセッションはこれらの動作を同時に行います。したがって、使用されるメモリの合計は、work_memの数倍になります。値を選択する時には、この事実に留意することが必要です。並び替え操作はORDER BY、DISTINCT、およびマージ結合に対して使われます。ハッシュテーブルはハッシュ結合、ハッシュに基づいた集約、およびIN副問い合わせのハッシュに基づいた処理で使用されます。
了解了解、当然と言えば当然だよなぁ。「あるタイミングから激遅になった」ってのは、work_memを越える大きさになったんだろうね対象が。ちなみにですが、work_memを2MBから大きくしても検索性能に変化は現れませんでした。ってのも、ある意味当然。
って、ホントはエンジニアに「ログを出せや！」って言われていたんだけど、先に試してみちゃった、ごめんちょ。ただ、テーブルの大きさからしてこんな単純な話しで15secかかってるのはあり得ないので、適切なindexをはってもらおう、あ、ログ出すようにしまぷ。