!rZemGiqmyMCWkAxURV:gitter.im

groonga/ja

158 Members
4 Servers

Load older messages

SenderMessageTime
25 Aug 2023
@askdkc:gitter.imdkc突っ込んだら「完全にインメモリというわけではなく、キャッシュはインメモリだよ、、、」と言い出した08:46:28
@askdkc:gitter.imdkcそれでも使い方次第ではお安くパフォーマンス向上が出来るかも〜💖08:47:15
@askdkc:gitter.imdkcダミーデータ10万件程度作って試したところ、EXPLAIN ANALYZE VERBOSEに差は無かったので、インメモリ説は消えた💔09:49:56
@askdkc:gitter.imdkcこれで悩みのない週末に突入できる。09:50:19
@askdkc:gitter.imdkcテストついでにVIEWにはPGroongaのインデックス張れないので、VIEWを作った後にPGroongaの検索使いたくなった時は、どの道マテビューは必須という発見がございました09:58:08
@askdkc:gitter.imdkc
In reply to @ktou:matrix.org
なるほど。
https://www.postgresql.org/docs/current/rules-materializedviews.html にはそんなことが書いていないのでどこ情報なのかと思っていました。
実際のところどうなんですかねぇ。
大きなマテリアライズドビューを作ってみてPostgreSQLのデータディレクトリーになにもファイルが増えていなければインメモリーなのかなぁという気もしますけど。
一応このオフィシャルドキュメントに「While access to the data stored in a materialized view is often much faster than accessing the underlying tables directly or through a view, the data is not always current; yet sometimes current data is not needed」とあるので、本当は速いのかもしれない 		10:13:15
@askdkc:gitter.imdkcマジでよく分からん。10:16:19
28 Aug 2023
@milano:gitter.immilanoお邪魔します mroongaのメーリングリストはまだ健在でしょうか？ 公式サイトから保管庫のリンクを辿っても504になり、googleで検索して辿り着いても2023年の投稿が見当たらずだったので、ここで質問させていただきました 01:24:26
@ktou:matrix.orgkouいやぁ、メーリングリストをホスティングしているOSDNが買収 https://forest.watch.impress.co.jp/docs/news/1520393.html とかでゴタゴタしているらしく、安定しないんですよ。 ここか https://github.com/mroonga/mroonga/discussions を使ってもらえますか？01:26:27
@milano:gitter.immilanoなるほど、了解しました、ではここで質問させていただきます01:28:11
@milano:gitter.immilano 
mysql> show variables like '%mroonga_version%';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| mroonga_version | 5.12  |
+-----------------+-------+

mysql> select * from information_schema.TABLES where TABLE_NAME = 'SearchItems'\G
*************************** 1. row ***************************
  TABLE_CATALOG: def
     TABLE_NAME: SearchItems
     TABLE_TYPE: BASE TABLE
         ENGINE: Mroonga
        VERSION: 10
     ROW_FORMAT: Dynamic
     TABLE_ROWS: 2332764
 AVG_ROW_LENGTH: 0
    DATA_LENGTH: 2518052864
MAX_DATA_LENGTH: 0
   INDEX_LENGTH: 0
      DATA_FREE: 0
 AUTO_INCREMENT: NULL
    CREATE_TIME: NULL
    UPDATE_TIME: NULL
     CHECK_TIME: NULL
TABLE_COLLATION: utf8_general_ci
       CHECKSUM: NULL
 CREATE_OPTIONS:
  TABLE_COMMENT:
1 row in set (0.06 sec)

mysql> show create table SearchItems;
| SearchItems | CREATE TABLE `SearchItems` (
  `ItemId` int(10) unsigned NOT NULL,
  `NewsId` varchar(150) NOT NULL,
  `DeliverDate` datetime NOT NULL,
  `HeadLine` varchar(255) NOT NULL,
  `SubHeadLine` varchar(255) DEFAULT NULL,
  `Body` mediumtext NOT NULL,
  `GenreInformation` text NOT NULL,
  `LastUpdated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `UnixTime` int(10) unsigned DEFAULT NULL,
  `CreateUser` int(10) unsigned DEFAULT NULL,
  `ModifyUser` int(10) unsigned DEFAULT NULL,
  `PublishRange` tinyint(3) unsigned DEFAULT NULL,
  `PublishFlg` tinyint(1) DEFAULT NULL,
  `Status` tinyint(1) DEFAULT NULL,
  `IsKantele` tinyint(1) DEFAULT NULL,
  `SendRestricts` tinyint(1) DEFAULT NULL,
  `CompanyId` int(10) unsigned DEFAULT NULL,
  PRIMARY KEY (`ItemId`),
  KEY `NewsId` (`NewsId`),
  KEY `DeliverDate` (`DeliverDate`),
  KEY `LastUpdated` (`LastUpdated`),
  KEY `UnixTime` (`UnixTime`),
  KEY `CreateUser` (`CreateUser`),
  KEY `ModifyUser` (`ModifyUser`),
  KEY `PublishRange` (`PublishRange`),
  KEY `PublishFlg` (`PublishFlg`),
  KEY `Status` (`Status`),
  KEY `IsKantele` (`IsKantele`),
  KEY `SendRestricts` (`SendRestricts`),
  KEY `CompanyId` (`CompanyId`),
  FULLTEXT KEY `HeadLine` (`HeadLine`) COMMENT 'parser "TokenBigram", normalizer "NormalizerAuto"',
  FULLTEXT KEY `SubHeadLine` (`SubHeadLine`) COMMENT 'parser "TokenBigram", normalizer "NormalizerAuto"',
  FULLTEXT KEY `Body` (`Body`) COMMENT 'parser "TokenBigram", normalizer "NormalizerAuto"',
  FULLTEXT KEY `GenreInformation` (`GenreInformation`) COMMENT 'parser "TokenBigram", normalizer "NormalizerAuto"',
  FULLTEXT KEY `Head_Sub` (`HeadLine`,`SubHeadLine`) COMMENT 'parser "TokenBigram", normalizer "NormalizerAuto"',
  FULLTEXT KEY `Head_Sub_Body` (`HeadLine`,`SubHeadLine`,`Body`) COMMENT 'parser "TokenBigram", normalizer "NormalizerAuto"'
) ENGINE=Mroonga DEFAULT CHARSET=utf8

このようなテーブルに対して、DELETE文・INSERT文の実行が遅くて頭を悩ましています。
古いシステムなため、古いmroongaで恥ずかしい限りです。
slow queryの一例はこんな感じです。

Time: 230825 10:06:15

User@Host: root[root] @ [127.0.0.1] Id: 6321625

Query_time: 26.651038 Lock_time: 0.000027 Rows_sent: 0 Rows_examined: 2

SET timestamp=1692925575;
DELETE FROM SearchItems WHERE ItemId=2887131;

Time: 230825 10:07:20

User@Host: root[root] @ [127.0.0.1] Id: 6321740

Query_time: 49.110938 Lock_time: 0.000069 Rows_sent: 0 Rows_examined: 0

SET timestamp=1692925640;
INSERT INTO SearchItems(ItemId,NewsId,DeliverDate,HeadLine,SubHeadLine,Body,GenreInformation,LastUpdated,UnixTime,CreateUser,ModifyUser,PublishRange,PublishFlg,Status,IsKantele,SendRestricts,CompanyId) VALUES(省略);

上記は特に遅いケースですが、日常的に5秒程度かかるケースが頻発しています。
遅い原因と調査方法、解決策などのアドバイスがあればご教授いただきたいです。

01:32:38
@milano:gitter.immilano * 
mysql> show variables like '%mroonga_version%';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| mroonga_version | 5.12  |
+-----------------+-------+

mysql> select * from information_schema.TABLES where TABLE_NAME = 'SearchItems'\G
*************************** 1. row ***************************
  TABLE_CATALOG: def
     TABLE_NAME: SearchItems
     TABLE_TYPE: BASE TABLE
         ENGINE: Mroonga
        VERSION: 10
     ROW_FORMAT: Dynamic
     TABLE_ROWS: 2332764
 AVG_ROW_LENGTH: 0
    DATA_LENGTH: 2518052864
MAX_DATA_LENGTH: 0
   INDEX_LENGTH: 0
      DATA_FREE: 0
 AUTO_INCREMENT: NULL
    CREATE_TIME: NULL
    UPDATE_TIME: NULL
     CHECK_TIME: NULL
TABLE_COLLATION: utf8_general_ci
       CHECKSUM: NULL
 CREATE_OPTIONS:
  TABLE_COMMENT:
1 row in set (0.06 sec)

mysql> show create table SearchItems;
| SearchItems | CREATE TABLE `SearchItems` (
  `ItemId` int(10) unsigned NOT NULL,
  `NewsId` varchar(150) NOT NULL,
  `DeliverDate` datetime NOT NULL,
  `HeadLine` varchar(255) NOT NULL,
  `SubHeadLine` varchar(255) DEFAULT NULL,
  `Body` mediumtext NOT NULL,
  `GenreInformation` text NOT NULL,
  `LastUpdated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `UnixTime` int(10) unsigned DEFAULT NULL,
  `CreateUser` int(10) unsigned DEFAULT NULL,
  `ModifyUser` int(10) unsigned DEFAULT NULL,
  `PublishRange` tinyint(3) unsigned DEFAULT NULL,
  `PublishFlg` tinyint(1) DEFAULT NULL,
  `Status` tinyint(1) DEFAULT NULL,
  `IsKantele` tinyint(1) DEFAULT NULL,
  `SendRestricts` tinyint(1) DEFAULT NULL,
  `CompanyId` int(10) unsigned DEFAULT NULL,
  PRIMARY KEY (`ItemId`),
  KEY `NewsId` (`NewsId`),
  KEY `DeliverDate` (`DeliverDate`),
  KEY `LastUpdated` (`LastUpdated`),
  KEY `UnixTime` (`UnixTime`),
  KEY `CreateUser` (`CreateUser`),
  KEY `ModifyUser` (`ModifyUser`),
  KEY `PublishRange` (`PublishRange`),
  KEY `PublishFlg` (`PublishFlg`),
  KEY `Status` (`Status`),
  KEY `IsKantele` (`IsKantele`),
  KEY `SendRestricts` (`SendRestricts`),
  KEY `CompanyId` (`CompanyId`),
  FULLTEXT KEY `HeadLine` (`HeadLine`) COMMENT 'parser "TokenBigram", normalizer "NormalizerAuto"',
  FULLTEXT KEY `SubHeadLine` (`SubHeadLine`) COMMENT 'parser "TokenBigram", normalizer "NormalizerAuto"',
  FULLTEXT KEY `Body` (`Body`) COMMENT 'parser "TokenBigram", normalizer "NormalizerAuto"',
  FULLTEXT KEY `GenreInformation` (`GenreInformation`) COMMENT 'parser "TokenBigram", normalizer "NormalizerAuto"',
  FULLTEXT KEY `Head_Sub` (`HeadLine`,`SubHeadLine`) COMMENT 'parser "TokenBigram", normalizer "NormalizerAuto"',
  FULLTEXT KEY `Head_Sub_Body` (`HeadLine`,`SubHeadLine`,`Body`) COMMENT 'parser "TokenBigram", normalizer "NormalizerAuto"'
) ENGINE=Mroonga DEFAULT CHARSET=utf8

このようなテーブルに対して、DELETE文・INSERT文の実行が遅くて頭を悩ましています。
古いシステムなため、古いmroongaで恥ずかしい限りです。
slow queryの一例はこんな感じです。

# Time: 230825 10:06:15
# User@Host: root\[root\] @  \[127.0.0.1\]  Id: 6321625
# Query\_time: 26.651038  Lock\_time: 0.000027 Rows\_sent: 0  Rows\_examined: 2
SET timestamp=1692925575;
DELETE FROM SearchItems WHERE ItemId=2887131;

# Time: 230825 10:07:20
# User@Host: root\[root\] @  \[127.0.0.1\]  Id: 6321740
# Query\_time: 49.110938  Lock\_time: 0.000069 Rows\_sent: 0  Rows\_examined: 0
SET timestamp=1692925640;
INSERT INTO SearchItems(ItemId,NewsId,DeliverDate,HeadLine,SubHeadLine,Body,GenreInformation,LastUpdated,UnixTime,CreateUser,ModifyUser,PublishRange,PublishFlg,Status,IsKantele,SendRestricts,CompanyId) VALUES(省略);

上記は特に遅いケースですが、日常的に5秒程度かかるケースが頻発しています。
遅い原因と調査方法、解決策などのアドバイスがあればご教授いただきたいです。

01:33:23
@ktou:matrix.orgkou昔は速かったけど徐々に遅くなってきて今はこんな状態ということですよね？01:36:08
@milano:gitter.immilanoはい、そうです 今年の3月からslow queryログを出力するようにしたのですが、それ以降ログが出る回数が徐々に増えているような状態です01:37:27
@ktou:matrix.orgkou200万件ちょいなのでレコード件数的には別に余裕ですけどねぇ。01:37:38
@ktou:matrix.orgkou

一般的には、データそのものの更新が遅くなることはなくて、遅くなるとしたらインデックスの更新です。
インデックスは、できるだけ対策はしてありますが、更新を繰り返すとゴミが貯まっていくことがあります。そうなると更新処理が遅くなります。

ALTER TABLE SearchItems DISABLE KEYS; → ALTER TABLE SearchItems ENABLE_KEYS;でインデックスを作り直してみてもらえますか？これでゴミがなくなります。

（破壊的な操作なので一応作業前にバックアップを取っておいてください。あと、DISABLE KEYS/ENABLE KEYSをしている間はDBに触らないでください。）

01:40:29
@milano:gitter.immilanoFULLTEXT KEY のインデックスだけを対象にすれば良いでしょうか？それとも全てのインデックスでしょうか？01:41:28
@milano:gitter.immilanoあ、個別に指定するものではないんですね01:41:50
@ktou:matrix.orgkou そうですね。
DISABLE KEYS/ENABLE KEYSは全部のインデックスが対象になります。 		01:42:02
@ktou:matrix.orgkou FULLTEXT KEYの方が影響が大きいですが、そうじゃないKEYもゴミが貯まる可能性はあります。 01:42:29
@ktou:matrix.orgkou昔のGroonga（Mroongaじゃない）だとデータもゴミが貯まる可能性はありました。 https://www.clear-code.com/blog/2014/3/13.html01:43:02
@ktou:matrix.orgkouでも、これのせいで更新速度は遅くならない気はしますね。。。 ストレージ容量が増えるだけな気がします。01:43:29
@milano:gitter.immilano一度インデックスの作り直しをやってみます。サービスを停止しないとならなそうなので、実施まで調整が必要そうなので結果の報告まで時間がかかりそうです01:45:05
@ktou:matrix.orgkou あぁ、これが効くか実験するだけなら、同じような性能の別のマシンに同じ環境を作って、そこにこのデータベースをリストアしてINSERT/DELETEしてみるといけると思います。
それで速くなるなら効果がある可能性が高いです。
リストア直後はインデックスがきれいな状態なんです。 		01:46:45
@ktou:matrix.orgkou あとは、INSERT/DELETE中のシステムの状態を確認ですかねぇ。
メモリーが足りなくてスワップを使っているとか、IOが遅い（HDDですか？）とかがボトルネックならインデックスを作り直してもそんなに効果がない可能性があります。 		01:48:48
@milano:gitter.immilanoありがとうございます オンプレミスなので容易に同じような性能のマシンを用意できないので、既存のマシンでなんとかできないかも含めて確かめてみたいと思います 残念ながらHDDなのでIOの遅さもあると思います 01:53:59
@ktou:matrix.orgkou リソースに余裕があるなら同一データベース内に違う名前の同じスキーマのテーブルを作ってそこにデータをINSERT INTO XXX SELECT * FROM SearchItemsでコピーしてそこで実験するのもアリかもしれません。 01:56:26
@milano:gitter.immilanoおお、それならできそうです！ありがとうございます01:58:35
30 Aug 2023
@milano:gitter.immilano先日教えていただいた、テーブルをコピーしてそこに対してINSERT / DELETEするテストを行ってみました 結果として、新しいテーブルでも同じように時間がかかることがわかったので、インデックスの肥大化・断片化などは影響がなさそうです ディスク性能、スワップが使われている、などが怪しそうなので、メモリの値を疑ってみます ちなみに、mroongaエンジンのテーブルには、innodb_buffer_pool_sizeのパラメータは影響しますか？ 00:59:16
@ktou:matrix.orgkou 直接は影響しないです！
間接的には影響します。innodb_buffer_pool_sizeでInnoDBがシステムのたくさんのメモリーを使うことになってシステム内でMroongaが使えるリソースが少なくなると影響が出ます。 		01:02:54

Show newer messages

Back to Room ListRoom Version: 6