Naoya Murakami
visio****@gmail*****
2013年 5月 21日 (火) 20:04:30 JST
お世話になっております。村上です。 ・Spider 3.0を更新しました。まだ、体感だけですが、挙動が安定したような気がします。 なお、Spiderノードとdataノードは、同一サーバ上にあります。 ・ sysctl -w vm.overcommit_memory=1をセットしました。 ・テーブルのレコード数が数百万程度になるように、テーブルの分割数を見直しました。 >そのテーブルの主キーのサイズは何バイトくらいになりますか？ 主キーは、70バイト程度で、分割前は、３０００万レコードぐらいでした。現在は、多くて、数百万程度です。 以上のように、設定を見直し、データ移行、インデックス構築をしたのですが、結局は、mysqldが 再起動することが多発し、 インデックス構築→mysqldクラッシュ→インデックスロック→repair table、インデックス構築やり直し→ mysqldクラッシュ→repair table・・・ の無限地獄におちいりました。 が、今回は、mysqld.logにも、groonga.logにも何もでずに、mysqldが再起動されているので、 おそらくは、メモリ不足によるOOM killerの仕業かなと考えました。 瞬間的に、メモリが大きくなりすぎてしまったのかもしれません。 こうなると、あきらかにメモリ不足が問題かと思いますが、 とりあえずは、瞬間的にメモリが大きくなりすぎてOOM killerにmysqldが 殺されることが防ぐことができればいいかなと、一時的にスワップを もりっと８０GBほど追加させました。 これにより、今のところ、インデックス構築、大量データ更新時にmysqldの再起動が 多発することが回避できました。 また、数千万レコードの１テーブルの場合、インデックス構築が２日程度かかっていましたが、 １０テーブル程に分割して、並列してやれば、数時間で終わるようになりました！ どうも、ありがとうございました。 ほかにも数千万のレコードのテーブルがいくつかあり、多くても１千万以下になるように 全体的にテーブル設計を見直そうと考えています。 あ、あと、データを分割しているときに気づいたのですが、ラッパーモードでdisable keysした 状態で、 レコードをdeleteすると、必ず、mysqldがクラッシュする事象が発生しました。 当方の環境不備によるものかわかりませんが、とりあえず、ご報告いたします。 マニアックなケースなので、影響は低いと思いますが、後ほど別メールで、再現手順をお送りいたします。 更新時のmpstat -P ALL 02時58分31秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 02時58分31秒 all 22.35 0.00 1.51 2.54 0.00 0.13 0.00 0.00 73.48 02時58分31秒 0 61.42 0.00 4.09 4.88 0.00 0.81 0.00 0.00 28.79 02時58分31秒 1 21.49 0.00 1.33 2.83 0.00 0.00 0.00 0.00 74.35 02時58分31秒 2 21.67 0.00 1.28 1.89 0.00 0.00 0.00 0.00 75.15 02時58分31秒 3 30.84 0.00 1.57 2.54 0.00 0.00 0.00 0.00 65.05 02時58分31秒 4 13.60 0.00 1.63 3.84 0.00 0.00 0.00 0.00 80.93 02時58分31秒 5 8.66 0.00 0.66 1.19 0.00 0.00 0.00 0.00 89.49 02時58分31秒 6 12.14 0.00 0.87 2.31 0.00 0.18 0.00 0.00 84.50 02時58分31秒 7 9.15 0.00 0.64 0.84 0.00 0.00 0.00 0.00 89.36 [root ＠ localhost jppat]# vmstat 3 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 15 0 296252 235300 11036 28562492 0 0 11148 231 155360 10770 79 5 17 0 0 9 0 296252 216096 11044 28585220 0 0 10833 57 103971 10009 78 4 18 0 0 3 0 296252 237088 11060 28572832 0 0 9321 141215 282643 10042 69 5 24 2 0 以上、よろしくお願いします。 2013年5月20日 16:59 Kouhei Sutou <kou****@clear*****>: > 須藤です。 > > In <CANM+HhfkV8XQVSZTxyR1US4=xtHoL=hEq+RzvPWh2E8b9_swdQ****@mail*****> > "[groonga-dev,01406] Re: mysqldがクラッシュした後のmrnファイルのロックについて" on Mon, 20 May > 2013 13:02:51 +0900, > Naoya Murakami <visio****@gmail*****> wrote: > > > SSD４枚のraid0構成で、iowaitは低いのですが、メモリ３２ＧＢに対して、 > > １つのテーブルサイズが１０ＧＢ超、数千万レコードは、大きすぎるの > > かもしれませんね。テーブルサイズ２０Ｇで、数万レコードの場合は、 > > 数時間で終わるので、レコード数のが問題なのかな。。 > > 数千万レコードですか。。。 > もし、2,3千万くらいなら大丈夫だと思いますが、5000万を超える > くらいになるとmroongaには1テーブルのキーの合計サイズが4GBと > いう制限があり、それに到達してしまう可能性があります。 > > そのテーブルの主キーのサイズは何バイトくらいになりますか？も > し、主キーの平均サイズが64バイトとすると、6700万件くらいで > 4GBに到達してしまいます。 > > 参考: http://mroonga.org/ja/docs/reference.html#limitations-of-table > > 20GBの方がわりとすぐに終わっているのに、どうしてでしょう > ねぇ。。。 > > > iostat > > avg-cpu: %user %nice %system %iowait %steal %idle > > 27.95 0.00 1.72 3.09 0.00 67.23 > > mpstat -P ALLでそれぞれのCPUについて確認したほうがよさそうな > 気がしました。すべてのCPUで更新処理をしているわけではないの > で薄まってしまいそうな気がします。 > > まぁ、iowaitが小さめなので、更新がIOのボトルネックになってい > るということはなさそうですが。。。 > > > -- > 須藤 功平 <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 >
