soushiです。
alloc_countが増加する件、実行する度にalloc_countが増加するクエリが見つ
かったので、そのクエリを元に確認用のテーブルを作成しました。
[作成テーブル]
・テーブル1:InnoDB
CREATE TABLE `ml_master` (
`entry_id` int(11) NOT NULL,
`title` varchar(200) DEFAULT NULL,
`open_date` datetime NOT NULL DEFAULT '1900-01-01 00:00:00',
`del_flag` int(11) NOT NULL DEFAULT 0,
PRIMARY KEY (`entry_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 `encrypted`=YES ;
・テーブル2;Mroonga
CREATE TABLE `ml_text` (
`entry_id` int(11) NOT NULL,
`entry_text` mediumtext CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
PRIMARY KEY (`entry_id`),
FULLTEXT KEY `entry_text` (`entry_text`)
) ENGINE=Mroonga DEFAULT CHARSET=utf8mb4;
[サンプルクエリ]
・alloc_countが増加するクエリ1
SELECT
`ml_master`.`entry_id`
FROM
`ml_master`
INNER JOIN `ml_text` ON `ml_master`.`entry_id` = `ml_text`.`entry_id`
WHERE
MATCH(ml_text.entry_text) AGAINST('*D+ \"あいうえお\"' IN BOOLEAN MODE)
AND ml_master.open_date >= DATE_FORMAT(NOW(), '%Y-%m-%d %H:%i:59');
・alloc_countが増加するクエリ2
SELECT
`ml_master`.`entry_id`
FROM
`ml_master`
INNER JOIN `ml_text` ON `ml_master`.`entry_id` = `ml_text`.`entry_id` AND MATCH(ml_text.entry_text) AGAINST('*D+ \"あいうえお\"' IN BOOLEAN MODE)
WHERE
ml_master.open_date >= DATE_FORMAT(NOW(), '%Y-%m-%d %H:%i:59');
・alloc_countが増加しないクエリ
SELECT
`ml_master`.`entry_id`
FROM
`ml_master`
INNER JOIN `ml_text` ON `ml_master`.`entry_id` = `ml_text`.`entry_id`
WHERE
MATCH(ml_text.entry_text) AGAINST('*D+ \"あいうえお\"' IN BOOLEAN MODE);
WHERE句の日付の条件を消すとalloc_countが増加しなくなりました。
他にも増加パターンはあるかもしれませんが、取り急ぎ現在判明したパターンを
連絡します。
///////////////////////////////////////////////////////////////
[NAME] 大塚 総司 - OTSUKA Soushi
[Mail] so****@ayd*****
From: OHTSUKA Soushi(大塚 総司) <so****@ayd*****>
Subject: [groonga-dev,04964] Re: Mroongaのalloc_countの増加について、cache_limitの恒久設定方法
Date: Tue, 19 Apr 2022 13:59:49 +0900 (JST)
>
> soushiです。
>
>>> また結構地道な作業になりそうですので、返信にしばらくお時間かかると
>>> 思いますが、うまく問題のクエリが釣れるように頑張ってみます。
>>
>> 結構いきおいよく上昇しているので10:00-12:00あたりのMATCH
>> AGAINSTを使っているクエリーをいくつかピックアップすると意外
>> とすぐに見つかるのではないかという気がしています。
>
> 確かにalloc_countが大きく上昇している付近を重点的に確認すると見つけ
> やすそうですね。
> 参考にさせていただきます。
>
>> 再現の確認ですが、本番環境で実行しなくても大丈夫です。
>> mysqldumpでダンプしたデータ（Mroongaはオンラインでmysqldump
>> をするとデータの整合性が壊れることがありますがテスト用なので
>> 気にしなくていいです）をテスト用の環境にリストアしてテスト用
>> の環境で確認しても大丈夫です。
>
> クエリログは本番環境で取得し、繰り返しの実行は検証環境で行う予定でした。
> ただ情報管理の問題で本番環境のダンプをそのまま検証環境に持っていくことが
> できず、この点の調整でも少し時間をとられそうです。
>
>> FLUSH TABLESした直後は再起動直後と同じように最初のクエリーの
>> 処理が遅くなるので注意してください。（DBを開いたりストレージ
>> 上のデータをメモリー上に載せたりするため。）
>
> 補足ありがとうございます。
> CPU/ディスクIOには余裕があるため、恐らくサービスへの大きな影響はないかな
> と考えています。
>
> ///////////////////////////////////////////////////////////////
> [NAME] 大塚 総司 - OTSUKA Soushi
> [Mail] so****@ayd*****
>
> _______________________________________________
> groonga-dev mailing list
> groon****@lists*****
> https://lists.osdn.me/mailman/listinfo/groonga-dev