<div dir="ltr">いつもお世話になっております。宮下と申します。 <div> </div><div>不定期なのですが、掲題の通りUPDATEが遅くなる現象を確認しております。</div><div>もし、類似の現象をご存じの方がいらっしゃいましたら、対策など教えていただけますと幸いです。</div><div> </div><div>-----</div><div>発生頻度：</div><div>週に1,2回　～　2週に1回程度</div><div> </div><div>現象：</div><div>UPDATEクエリが遅くなる。</div><div>遅いクエリにはURLの更新が入っているが、このクエリが常に遅いわけではなく、高速に処理される場合もありました。</div><div>また、以下のログが多い時間帯にCPU使用率のsystemの値が上昇し、UPDATEが遅くなっていました。</div><div>（そうでない時間帯でも、いつもCPU使用率のsystemの値は高いですが・・・）</div><div><div> </div><div>ログ：</div><div>2017-07-06 02:13:22.049002|d|6ec53700|flushing a[0]=3867028 seg=59(0x7f1025400000) free=4</div><div>2017-07-06 02:13:22.053452|d|6ec53700|flushed a[0]=3867028 seg=59(0x7f101ba80000) free=4->258112 nterms=251 v=0</div></div><div> </div><div>再現：</div><div>他の要因も絡んでいるせいか、単純に更新前のデータに同じUPDATEを実行しても再現はできませんでした。 </div><div>遅くなるUPDATEにはURLが入っているので、URL部分のインデックス作成が要因だとは思っているのですが・・・</div><div> </div><div> </div><div>lib/ii.cのgrn_ii_update_oneでsizeがb->header.buffer_freeより小さくなると上記ログが出力されるようなのですが</div><div>このbuffer_freeの値をコントロールすることは可能なのでしょうか。。。</div><div> </div><div>その他、各種情報は以下の通りです。ほかに必要な情報などありましたら、ご指摘いただけますと幸いです。</div><div> </div><div>OS:</div><div>CentOs6.5</div><div> </div><div>MySQL:</div><div>5.6.17</div><div> </div><div>Mroonga:</div><div>4.10</div><div> </div><div>Groonga:</div><div>4.1.1</div><div> </div><div>データサイズ：</div><div>20GB(InnoDB)　＊ラッパーモード</div><div> </div><div>テーブル定義：</div><div>CREATE TABLE `table_a` ( `col1` int(11) NOT NULL, `col2` bigint(20) NOT NULL, `col3` bigint(20) NOT NULL, `col4` text, `col5` varchar(255) NOT NULL, `col6` varchar(255) DEFAULT NULL, `col7` varchar(255) NOT NULL, `col8` varchar(32) DEFAULT NULL, `col9` varchar(255) NOT NULL, `col10` varchar(255) DEFAULT NULL, `col11` varchar(255) DEFAULT NULL, `col12` varchar(255) DEFAULT NULL, `col13` varchar(255) DEFAULT NULL, `col14` varchar(255) DEFAULT NULL, `col15` text, `col16` text, `col17` mediumtext, `col18` text, `col19` text, `col20` text, `col21` text, `col22` text, `col23` mediumtext, `col24` text, <-URLのカラム `col25` tinyint(4) NOT NULL, `col26` varchar(128) DEFAULT NULL, `col27` varchar(128) DEFAULT NULL, `col28` varchar(128) DEFAULT NULL, `col29` varchar(128) DEFAULT NULL, `col30` varchar(128) DEFAULT NULL, `col31` varchar(128) DEFAULT NULL, `col32` int(11) DEFAULT NULL, `col33` datetime NOT NULL, `col34` datetime NOT NULL, `col35` datetime NOT NULL, `col36` datetime NOT NULL, PRIMARY KEY (`col1`,`col2`), KEY `idx1` (`col25`), KEY `idx2` (`col33`), KEY `idx3` (`col34`), KEY `idx4` (`col5`,`col32`), KEY `idx5` (`col1`,`col5`,`col32`), KEY `idx6` (`col1`,`col3`), FULLTEXT KEY `ftx1` (`col4`) COMMENT 'parser "TokenDelimit"', FULLTEXT KEY `ftx2` (`col5`,`col6`,`col7`,`col8`) COMMENT 'parser "TokenBigramSplitSymbolAlphaDigit"', FULLTEXT KEY `ftx3` (`col9`,`col10`,`col11`,`col12`,`col13`,`col14`) COMMENT 'parser "TokenBigramSplitSymbolAlphaDigit"', FULLTEXT KEY `ftx4` (`col16`,`col17`,`col18`,`col19`,`col20`,`col21`) COMMENT 'parser "TokenBigramSplitSymbolAlphaDigit"', FULLTEXT KEY `ftx5` (`col15`,`col22`) COMMENT 'parser "TokenBigramSplitSymbolAlphaDigit"', FULLTEXT KEY `ftx6` (`col24`) COMMENT 'parser "TokenBigramSplitSymbolAlphaDigit"', FULLTEXT KEY `ftx7` (`col26`,`col28`,`col30`) COMMENT 'parser "TokenBigramSplitSymbolAlphaDigit"', FULLTEXT KEY `ftx8` (`col27`,`col29`,`col31`) COMMENT 'parser "TokenBigramSplitSymbolAlphaDigit"' ) ENGINE=Mroonga DEFAULT CHARSET=utf8 COMMENT='engine "InnoDB"' </div><div> </div><div>クエリの処理時間：</div><div>通常：1秒未満</div><div>現象発生時：1秒～3秒</div><div> </div><div>並列性：</div><div>Master(InnoDB)からのレプリケーションのため直列です。</div><div> </div><div>以上、よろしくお願いいたします。</div></div>