堀本と申します。 ご報告ありがとうございます！ alloc_count が常に増加しつづけるのは異常です。 基本的には、クエリー実行前後でalloc_countは変化がないことが期待される動作です。 なので、どこかでメモリーリークしています。 テーブルの定義とクエリーのご提供ありがとうございます！ 手元の環境でも再現できましたので、調査を進めていきます。 以上です。失礼いたします。 From: Mitsuo Yoshida <y****@ceek*****> Subject: [groonga-dev,04966] Re: Mroongaのalloc_countの増加について、cache_limitの恒久設定方法 Date: Tue, 19 Apr 2022 18:25:31 +0900 > 須藤さん > > 吉田です、こんにちは。 > > alloc_count の増加については、どのようなものが正常でしょうか。 > 私も、仮想メモリが増加し続け、クラッシュする問題に悩まされており、現状では日時の FLUSH TABLES でメモリを解放して回避しています。 > （table_open_cache の値の調整でどうにかなるかな…と検証しようと思った矢先に、今回の報告メールを見ました） > > 手元の環境で、実行してみたところ、以下の結果でした。 > alloc_countが常に2または5増加しています。 > > テーブルの定義： > → 同じようなテーブルが一つのDBに20件あり > → 本テーブルのデータ件数は約20万件（テキストデータ300MB程度） > > CREATE TABLE `news_latest` ( > `id` int(11) NOT NULL AUTO_INCREMENT, > `title` text NOT NULL, > `url` varchar(512) CHARACTER SET ascii NOT NULL, > `reverse_dn` varchar(128) CHARACTER SET ascii NOT NULL, > `redirect_url` varchar(512) CHARACTER SET ascii DEFAULT NULL, > `plugin` varchar(128) CHARACTER SET ascii NOT NULL, > `category` varchar(128) DEFAULT NULL, > `category_id` varchar(128) CHARACTER SET ascii NOT NULL, > `content` mediumtext DEFAULT NULL, > `published` datetime NOT NULL, > `is_crawl_date` tinyint(1) NOT NULL, > `is_removed` tinyint(1) NOT NULL, > `created` datetime NOT NULL, > `modified` datetime NOT NULL, > PRIMARY KEY (`id`), > UNIQUE KEY `url` (`url`), > KEY `reverse_dn` (`reverse_dn`), > KEY `category_id` (`category_id`), > KEY `published` (`published`), > FULLTEXT KEY `ft` (`title`,`content`) COMMENT 'tokenizer > "TokenBigramSplitSymbolAlphaDigit", normalizer "NormalizerAuto"' > ) ENGINE=Mroonga DEFAULT CHARSET=utf8mb4; > > 実行1： > → 実行の度に alloc_count が必ず2増加（LIMITの件数や実際に返ってくる結果に影響を受けず必ず2増加） > > SELECT > url, redirect_url, title, content, published, created, reverse_dn, category_id > FROM > news_latest > WHERE MATCH(title,content) AGAINST('*D+ 次期衆院選' IN BOOLEAN MODE) > ORDER BY > published DESC > LIMIT > 0, 1; > > 実行2： > → 実行の度に alloc_count が必ず5増加 > > SELECT > COUNT(*) > FROM > news_latest > WHERE MATCH(title,content) AGAINST('*D+ 次期衆院選' IN BOOLEAN MODE); > > 実行3： > → 実行の度に alloc_count が必ず5増加 > > SELECT > COUNT(*) AS cnt, > reverse_dn > FROM > news_latest > WHERE MATCH(title,content) AGAINST('*D+ 次期衆院選' IN BOOLEAN MODE) > GROUP BY > reverse_dn; > > > -- > Mitsuo Yoshida < y****@ceek***** > > > 2022年4月18日(月) 17:46 Sutou Kouhei <kou****@clear*****>: >> >> 須藤です。 >> >> 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 mailing list >> groon****@lists***** >> https://lists.osdn.me/mailman/listinfo/groonga-dev > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > https://lists.osdn.me/mailman/listinfo/groonga-dev
