Naoya Murakami
visio****@gmail*****
2013年 5月 20日 (月) 13:02:51 JST
お世話になっております。村上です。
須藤様、斯波様、早速のご回答ありがとうございました。
メモリ周りの件と、spiderの更新の件、現在のインデックス再構築が完了したら、
いろいろと試してみたいと思います。
土曜日の晩にクラッシュして、インデックス作り直しているのですが、
いまも動いていて、まだ終わってません。
どうやらswapがたまに起きているようです。
やはり、メモリ周りが怪しいですね。
SSD４枚のraid0構成で、iowaitは低いのですが、メモリ３２ＧＢに対して、
１つのテーブルサイズが１０ＧＢ超、数千万レコードは、大きすぎるの
かもしれませんね。テーブルサイズ２０Ｇで、数万レコードの場合は、
数時間で終わるので、レコード数のが問題なのかな。。
すでに分割していて、このサイズなので、テーブルがある程度大きくなるのは、
あきらめ半分なのですが、インデックス構築でここまでくたくたになるのは、
大変なので、いただいた情報を試しても、解消されない場合、
テーブルの再設計、リソース増強含めて検討したいと思います。
vmstat
procs -----------memory---------- ---swap-- -----io---- --system--
-----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id
wa st
2 0 541240 2542764 16264 24478128 0 0 664 8204 3452 1145 24 1
75 0 0
2 0 541240 2542080 16272 24478808 0 0 744 132 4061 1662 24 0
75 0 0
2 0 541240 2541832 16272 24479252 0 0 360 0 3407 1626 24 1
75 0 0
2 0 541240 2527448 16272 24480816 0 0 1300 0 5079 1403 24 1
75 0 0
2 0 541236 2519256 16272 24482564 40 0 2072 4 4337 1905 24 1
74 0 0
iostat
avg-cpu: %user %nice %system %iowait %steal %idle
27.95 0.00 1.72 3.09 0.00 67.23
以上、よろしくお願いします。
2013年5月20日 11:53 Kouhei Sutou <kou****@clear*****>:
> 須藤です。
>
> In <CANM+Hhd_Pdfqu_nVOEr****@mail*****>
> "[groonga-dev,01400] mysqldがクラッシュした後のmrnファイルのロックについて" on Sun, 19 May
> 2013 03:52:00 +0900,
> Naoya Murakami <visio****@gmail*****> wrote:
>
> > mroonga3.03をmyisamのラッパーモードで利用しています。
> >
> > updateを並列させすぎたせいか、mmap failed!!!! in GRN_IO_SEG_REF(0x7fcbe44d19b0,
> > 618)というメッセージでmysqldがクラッシュし、再起動することがよくあります。
>
> mmapが失敗しているということはリソース不足（メモリ不足）だと思います。
>
> まずは、以下を実行して実メモリ以上の領域もmmapできるようにし
> てください。groongaが実メモリ以上の領域をmmapしても同時にす
> べての領域に触らなければ動き続けられるはずです。
>
> % sudo sysctl -w vm.overcommit_memory=1
>
> 参考:
> http://sourceforge.jp/projects/groonga/lists/archive/dev/2013-April/001294.html
>
> もし、そもそも同時に実メモリ以上のデータ量を扱わなければいけ
> ない場合は、もっとデータを分散するか、定期的にMySQLを再起動
> して扱っているデータをリセットする必要があります。
> （FLUSH TABLESでいけるような気がするのですが、磯部さんのケー
> スを聞くと、FLUSH TABLESでは足りないようです。。。）
>
> > その後、groonga.logを参照すると、
> > io(xxxx.mrn.000010A) collisions(1000/598903): lock failed 1000 times
> > となっており、クラッシュした際にアップデートしていたテーブルの
> > インデックスがロックされて、以後、更新できなくなります。
> >
> > このように、インデックスがロックされた場合、該当のテーブルをdisable keys 後、
> > enable keysすることにより、インデックスを再構築しなおすことにより、対応しています。
>
> はい、対応はそれで問題ありません。
>
> > ５月頭よりずっとインデックス構築しておりますが、途中で、mysqldがクラッシュし、
> > インデックスがロックされることが多くて、やり直しが多数発生してなかなか大変です。
> > インデックスの再構築に、１日超かかるテーブルが多いです。。
>
> enable keysで1日超かかるというのは、メモリ不足な気がしま
> す。。。インデックス再構築時のサーバーのリソース使用状況を確
> 認して、CPUがボトルネックになっている場合はデータがたくさん
> あるのでしょうがないのですが、IO waitがすごいことになってい
> る場合はメモリ不足だと思います。
>
> > ***.mrn.001がロックされ、データベースごとインデックス構築やり直したことも
> > あります。
> >
> > Q.インデックスがロックされた場合、インデックスの再構築以外にロックを
> > 解除させる方法はないでしょうか？
>
> もし、単にロックが残っているだけであれば、以下のSQLでロック
> を解除できます。
>
> mysql> SELECT mroonga_command("clearlock");
>
> 参考: http://groonga.org/ja/docs/reference/commands/clearlock.html
>
> ただし、ロックが残っているだけではなく、データベースに不整合
> が発生している場合はインデックスを再構築しないといけません。
>
> なお、「***.mrn.001」がロックされているときはデータベース内の
> オブジェクト名（テーブル名やカラム名）を管理している内部のテー
> ブルキーがロックを持っている状態になります。このときは、ラッ
> パーモードであれば、
>
> * mysqldを終了
> * 「*.mrn*」ファイルを全て削除
> * mysqldを起動
> * disable keys
> * enable keys
>
> でデータの再投入なしで復活しそうな気もします。
> （データベースファイルがなかったら自動で作るようにしてあった
> 気がするので。）
>
> --
> 須藤 功平 <kou****@clear*****>
> 株式会社クリアコード <http://www.clear-code.com/> (03-6231-7270)
>
> groongaサポート:
> http://groonga.org/ja/support/
> パッチ採用はじめました:
> http://www.clear-code.com/recruitment/
> コミットへのコメントサービスはじめました:
> http://www.clear-code.com/services/commit-comment.html
>
> _______________________________________________
> groonga-dev mailing list
> groon****@lists*****
> http://lists.sourceforge.jp/mailman/listinfo/groonga-dev
>