[groonga-dev,04959] Re: Mroongaのalloc_countの増加について、cache_limitの恒久設定方法

Back to archive index
Sutou Kouhei kou****@clear*****
2022年 4月 18日 (月) 17:46:24 JST


須藤です。

In <20220****@ayd*****>
  "[groonga-dev,04957] Mroongaのalloc_countの増加について、cache_limitの恒久設定方法" on Mon, 18 Apr 2022 17:12:05 +0900 (JST),
  OHTSUKA Soushi(大塚 総司) <so****@ayd*****> wrote:

> 先日、Mroonga(Groonga)を使ったサイトを構築したところ、時間経過でメモリ
> 使用量が増加しOOM Killerが発生する現象が続いております。

おぉ。。。
これはどこかのタイミングでメモリーリークのバグを入れてしまっ
た感じがしますね。。。

> ### alloc_countの増加原因について
> 
> メモリ使用量の増加はalloc_countが増加しているMroongaが関係していると考え
> ています。
> ただ現状手詰まり状態でして何か利用できそうな原因の調査方法等ありますで
> しょうか。
> 
> 他に必要な情報があれば確認してご連絡します。

日中のどれか1つ以上のクエリーでメモリーリークしていると思う
ので、日中のクエリーを記録しておいて(*)、各クエリーについて
以下を確認してもらえますか?

(*) General Query Logで記録できます。
    https://mariadb.com/kb/en/general-query-log/

  1. 実行前のalloc_countを記録する
  2. クエリーを実行する
  3. 実行後のalloc_countを記録する
  4. ↑の1.から3.を何回も実行し続ける

クエリーの中には実行し続けてもalloc_countが安定しているやつ
とalloc_countが増え続けるやつがあると思います。alloc_countが
増え続けるクエリーを1つでいいので見つけてもらえませんか?

見つかったらそれで再現できるはずです。ここまでくれば、再現デー
タ(元データを元にサンプルデータを作るとか元データを無害なデー
タに置換するとかして作成)と再現クエリーが用意でき、私の手元
でデバッグして直せます。


回避方法なんですが、たぶん、再起動ではなくFLUSH TABLESでも回
避できるとは思います。再起動よりは多少はマシかもしれませ
ん。。。


> ### cache_limitの恒久設定
> 
> cache_limitの設定を永続させる事は可能でしょうか。

できないです。

> MaraiaDB起動後に mroonga_command("cache_limit 0"); を実行すれば設定変更
> できますが、MariaDBの再起動を行うと元の設定(100)に戻ってしまいます。
> 
> メモリ増加の問題とは恐らく関係がないとは思うものの、cache_hit_rateが0.0
> なので、cache_limitは最初から0にしておきたいです。

普通の使い方(SELECT ... FROMしか使わず、SELECT
mroonga_command('...')を使わない使い方)ではそもそもキャッシュ
を使わないのでcache_limitの設定は影響ありません。なので、元
の設定のままでもなにも挙動は変わらないはずです。


groonga-dev メーリングリストの案内
Back to archive index