Kentaro Hayashi
hayas****@clear*****
2017年 7月 24日 (月) 16:01:08 JST
To: 宮下さん 林です。 On Fri, 21 Jul 2017 20:06:19 +0900 Masanori Miyashita <walnu****@gmail*****> wrote: > いつもお世話になっております。宮下と申します。 > > 不定期なのですが、掲題の通りUPDATEが遅くなる現象を確認しております。 > もし、類似の現象をご存じの方がいらっしゃいましたら、対策など教えていただけますと幸いです。 > > ----- > 発生頻度： > 週に1,2回 〜 2週に1回程度 > > 現象： > UPDATEクエリが遅くなる。 > 遅いクエリにはURLの更新が入っているが、このクエリが常に遅いわけではなく、高速に処理される場合もありました。 > また、以下のログが多い時間帯にCPU使用率のsystemの値が上昇し、UPDATEが遅くなっていました。 > （そうでない時間帯でも、いつもCPU使用率のsystemの値は高いですが・・・） 確実に再現できるといいのですけど、悩ましいですね。。。 > > ログ： > 2017-07-06 02:13:22.049002|d|6ec53700|flushing a[0]=3867028 > seg=59(0x7f1025400000) free=4 > 2017-07-06 02:13:22.053452|d|6ec53700|flushed a[0]=3867028 > seg=59(0x7f101ba80000) free=4->258112 nterms=251 v=0 この部分はバッファーの空きがなくなってきたのでフラッシュして再度バッファーを 確保し直した(free 4->258112)ことを意味します。これが頻繁だとたしかにパフォーマンスは落ちそうです。 > 再現： > 他の要因も絡んでいるせいか、単純に更新前のデータに同じUPDATEを実行しても再現はできませんでした。 > 遅くなるUPDATEにはURLが入っているので、URL部分のインデックス作成が要因だとは思っているのですが・・・ > > > lib/ii.cのgrn_ii_update_oneでsizeがb->header.buffer_freeより小さくなると上記ログが出力されるようなのですが > このbuffer_freeの値をコントロールすることは可能なのでしょうか。。。 この値は内部的なやつなので、環境変数で最大値をごにょごにょと設定するとどうにかできるというタイプの ものとは違うのです。 さて、問題を解決するために、ひとつ試してもらいたいことがあります。 Groongaのバージョンをあげることは可能でしょうか。検証環境があればそちらでもかまいません。 http://groonga.org/ja/blog/2017/01/18/groonga-6.1.4.html に記載のとおり、マルチカラム インデックスに関連した改善が入っています。 「この改善処理では、Mroongaのマルチカラムインデックスで使う場合のように非自然言語 テキストのインデックス構築時のみ影響があります。Mroongaでマルチカラムインデックスを使っている方はぜひ試してみてください。」 宮下さんのケースだとマルチカラムインデックスを使っているので、もしかしたら Groongaを6.1.5以降に更新することで現象が改善するかもしれません。 -- Kentaro Hayashi <hayas****@clear*****> -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: 無し 型: application/pgp-signature サイズ: 833 バイト 説明: 無しDownload