各務 洋
kagam****@outwa*****
2015年 10月 28日 (水) 18:28:22 JST
お世話になります、各務です。 > auto repair中はロックをとってスレッドでマルチスレッドでも同 > 時に処理しないようにしました。 > > http://packages.groonga.org/tmp/mysql-community-mroonga-5.09-2.el6.x86_64.rpm さっそくのご対応ありがとうございます、確認してみます。 > 頻繁に接続・切断を繰り返しているケースでは多少影響があると思 > いますが、多くの場合はそんなことをしていないと思うので性能へ > の影響は軽微じゃないかと思っています。 私の環境では Web で使用しているので、接続・切断は頻繁で、接続したまま の方が少ないのです。 ただ、この際は保全性の方が性能だと思うので、処理時間の影響はいずれにせ よ低いのではと思いました。 >> 処理中はテーブルロック（他からは READ 可能な方が良い気がします）がある >> と良いのかなぁと思いましたが、どうでしょうか？ > > これ、auto repair発動中はINSERTをブロックするということです > よね？ はい。イメージとしては、innodb の reindex や ALTER TABLE 〜 ENGINE の 時の挙動です。 この修復が終わるまで影響のある他の処理は全部順番待ちね〜といった所です。 innodb も SELECT まで待たせることもあるので、ガッチリロックもありだと 考えた次第です。 >> また検知の開始時期は分からないのですが、 > > クラッシュ後、最初にテーブルを開いたとき（最初にテーブルに触っ > たとき）に動くようになっています。 おっ！ >> 2015-10-27 10:58:13.401678|n|a00b9700|DDL:obj_remove tbl_test_pat_0005-a_id >> 2015-10-27 10:58:13.417480|n|a00b9700|DDL:obj_remove tbl_test_pat_0005-a_id.index >> >> と、時間に差があるのも気になる点ではあります。 > > これはしょうがないのです。。。 > テーブル削除はファイルを削除するためI/Oが走ります。そのため、 > メモリー上で終わる処理に比べて時間がかかるのです。。。 気になる点はお送りしたログ上の > 2015-10-27 10:54:56.879764|n|cda62720|log level is 'DUMP' > 2015-10-27 10:58:13.401678|n|a00b9700|DDL:obj_remove tbl_test_pat_0005-a_id こちらの3分少々の差の方なのです。（分かりにくくて申し訳ありません） テスト上、 mysqld が上がってくるとほぼ同時にテーブルを触っているので。 （処理は動かしっぱなしなのです） この3分少々は想定内でしょうか？なおレコードは最大でも55,000件以内です。 ---- 各務 kagam****@outwa*****
