Naoya Murakami
visio****@gmail*****
2013年 6月 3日 (月) 12:11:52 JST
お世話になっております。村上です。 spider,mroonga共に１サーバ上にあります。 どうすれば、事象を再現できるか検討していますが、なにぶんサイズが大きく、 壊れたときの復旧に半日はかかるので、なかなかどういう条件のときに、 この事象が発生するか追い込むのが困難な状況です。 今朝、また、３回目の同事象が発生しました。 今度は、並列数１でやりましたが、やはり、だめでした。現在、インデックス再構築中です。 ３回とも同じテーブルがクラッシュしています。 特定のテーブルに対する特定のサイズのクエリ発行時にクラッシュするのか、 それとも、メモリが増大していって、たまたまそのテーブルのときにメモリが一杯になったのか、 spider経由、spider経由なしで事象がかわるのか等を確認したいと思いますが、 特定するのに、時間がかかりそうです。 再現できるかどうか、少し、がんばってみます。 どうもありがとうございました。 以上、よろしくお願いします。 2013年6月3日 11:40 kentoku <kento****@gmail*****>: > 斯波です。 > > この問題をこちらで再現するには、どのようにすればよいか > ご教示頂くことはできますでしょうか？ > また構成は、Spider、mroonga共に、１サーバ上に > あるという認識であっておりますでしょうか？ > > どうぞ、よろしくお願いいたします。 > > > > 2013年6月3日 2:32 Naoya Murakami <visio****@gmail*****>: > > > お世話になっております。村上です。 > > > > mroonga3.04をMyISAMのラッパーモードで利用しています。 > > > > データのDELETE,INSERT時にmmap Cannot allocate memoryが発生して困っています。 > > > > 以前、インデックス構築時にmmap failed!が発生していたときに、相談させてていただいたときは、 > > １．vm.overcommit_memory = 1の設定 > > ２．swapを増加（スワップ６４ＧＢ、実メモリ３２ＧＢ） > > ３．テーブル分割数の見直し（１テーブル数十万レコード〜数百万レコード、数ＧＢ〜数十ＧＢ程度までにし、数十テーブルずつspiderでローカルリンク） > > で改善することができました。 > > > > しかし、インデックスを有効にしたまま、データのDELETE,INSERTをしていると、mmap Cannot allocate > > memoryが発生するようになってしまいました。 > > > > 更新中にクラッシュすると、spiderでリンクしているテーブルすべてにcheck table、壊れていたら、repair table > > でまた１日超かかってしまって困っています。 > > > > １回目は、負荷をかけすぎたのかなと、repair tableした後、２回目は、並列数を低くして実行したたもの、１０分程度で事象が再発しました。 > > > > これは、もう、ハードのリソース不足というしかないんでしょうか？ > > 更新の量はたいした量でなくても、発生しましたが。。テーブルサイズに対してメモリが足りないのでしょうか？ > > > > 何か、調査方法、解決方法はないでしょうか？ > > > > 方法がなければ、苦労して構築した数百ＧＢのインデックスをまた削除して、 > > レコード追加してから、インデックスを再構築するぐらいしかないですかね。 > > また、１週間ぐらいかかりそうですが。。 > > > > ・groonga.log抜粋 > > 2013-06-03 01:43:53.189474|n|c27fc700|split (16384) encsize=393485 > > 2013-06-03 01:43:57.588864|A|c283d700|mmap(4194304,600,12587008)=Cannot > > allocate memory <13627740160> > > 2013-06-03 > 01:43:57.590934|A|c283d700|/usr/lib64/libgroonga.so.0(+0x12e5fb) > > [0x7fc7c360a5fb] > > 2013-06-03 > > > 01:43:57.590947|A|c283d700|/usr/lib64/libgroonga.so.0(grn_io_seg_map_+0xb8) > > [0x7fc7c360e848] > > 2013-06-03 > > > > > 01:43:57.590952|A|c283d700|/usr/lib64/libgroonga.so.0(grn_io_win_map2+0x1004) > > [0x7fc7c3610294] > > 2013-06-03 > 01:43:57.590955|A|c283d700|/usr/lib64/libgroonga.so.0(+0x114e35) > > [0x7fc7c35f0e35] > > 2013-06-03 > 01:43:57.590958|A|c283d700|/usr/lib64/libgroonga.so.0(+0x11e4cd) > > [0x7fc7c35fa4cd] > > 2013-06-03 > > > > > 01:43:57.590961|A|c283d700|/usr/lib64/libgroonga.so.0(grn_ii_delete_one+0x16b) > > [0x7fc7c35fe4ab] > > 2013-06-03 > > > > > 01:43:57.590964|A|c283d700|/usr/lib64/libgroonga.so.0(grn_ii_column_update+0x907) > > [0x7fc7c36069e7] > > 2013-06-03 > > > > > 01:43:57.590967|A|c283d700|/usr/lib64/libgroonga.so.0(grn_column_index_update+0x3a) > > [0x7fc7c350aeea] > > 2013-06-03 > > > > > 01:43:57.590971|A|c283d700|/usr/local/mysql-5.5.14-spider-3.0-vp-0.18-hs-1.2-q4m-0.95-linux-x86_64-glibc25/lib/plugin/ha_mroonga.so(_ZN10ha_mroonga24wrapper_delete_row_indexEPKh+0x20e) > > [0x7fc7c3934a9e] > > > > ・・・ > > この後も、多数Cannot allocate memoryがでています。 > > 2013-06-03 01:43:57.598247|A|c283d700|mmap(262144,599,575705088)=Cannot > > allocate memory <13627740160> > > 2013-06-03 > 01:43:57.599186|A|c283d700|/usr/lib64/libgroonga.so.0(+0x12e5fb) > > [0x7fc7c360a5fb] > > > > ・mysqld.log > > 130603 1:45:59 - mysqld got signal 11 ; > > This could be because you hit a bug. It is also possible that this binary > > > > 以上、よろしくお願いします。 > > _______________________________________________ > > groonga-dev mailing list > > groon****@lists***** > > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev > > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev >
