Naoya Murakami
visio****@gmail*****
2013年 8月 26日 (月) 02:12:47 JST
お世話になっております。村上です。 60GB程度のインデックスの場合、スワップを追加することでmysqldがクラッシュする ことが回避できましたが、さらに大きいインデックスの場合（９０ＧＢ超程度）、 スワップをいくら足してもインデックス構築中にmysqldがクラッシュすることが判明しました。 どうにかして、インデックス９０ＧＢ超のデータを構築する方法はないでしょうか？ sysctlに以下は設定しています。 vm.overcommit_memory = 1 vm.max_map_count = 6553000 ・実メモリ32GB+スワップ160G(SSD)の場合 2013-08-25 11:07:19.248318|n|c21cd700|nblocks=5313, update_buffer_size=95856484978 ・・・ 2013-08-25 11:09:07.724612|n|c21cd700|nterms=236 chunk=2186602 total=5908644KB 2013-08-25 11:09:10.550480|n|7d444720|mroonga 3.06 started ・実メモリ32GB+スワップ230G(SSD)の場合 2013-08-26 01:05:13.819372|n|9398b700|nblocks=5313, update_buffer_size=95856484978 ・・・ 2013-08-26 01:07:04.395075|n|9398b700|nterms=236 chunk=2186602 total=5908644KB 2013-08-26 01:07:07.641821|n|b5c73720|mroonga 3.06 started. スワップを増やしてもまったく同じタイミングでmysqldがクラッシュしています。 このことからスワップを増やしても効果がないことがわかります。 ・vmstat 2013/08/26 00:56:28 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- 2013/08/26 00:56:28 r b swpd free buff cache si so bi bo in cs us sy id wa st 2013/08/26 01:06:58 1 0 53088 557400 13408 12086108 0 0 1 16 19053 1763 17 10 73 0 0 2013/08/26 01:07:01 2 0 53088 330836 13408 12267792 0 0 783 0 1838 1732 19 6 75 0 0 2013/08/26 01:07:04 1 0 53088 246216 13404 12397552 0 0 869 23 9874 1852 16 10 74 0 0 2013/08/26 01:07:07 2 0 53088 18475020 14444 12401964 0 0 1611 0 1967 1845 1 25 75 0 0 2013/08/26 01:07:10 1 0 53088 17702748 15356 12404272 0 0 979 84 1001 1614 2 1 97 0 0 2013/08/26 01:07:13 0 0 53088 17703004 15364 12404272 0 0 0 33 799 1470 0 0 100 0 0 2013/08/26 01:07:04周辺ではスワップすら発生していません。mysqldが再起動されることによりメモリの空きがあいているぐらいです。 ・df -h 2013年 8月 26日 月曜日 01:07:00 JST /dev/sda3 871G 731G 96G 89% 2013年 8月 26日 月曜日 01:07:03 JST /dev/sda3 871G 731G 96G 89% 2013年 8月 26日 月曜日 01:07:06 JST /dev/sda3 871G 731G 96G 89% 2013年 8月 26日 月曜日 01:07:09 JST /dev/sda3 871G 731G 96G 89% ディスクに空きはあり、ディスクフルによりmysqldが落ちたわけではないと思われます。 が、update_buffer_size=95856484978と空きサイズ96Gがだいたい一致しており、 これがなにかくさい気がしています。 あ、でも、-hなので、89GiBと96GiBであってないか。。 8/25時点のは、dfをロギングしてなかったので、クラッシュしたときのサイズが わからないですが、8/25のときのほうがswapが小さくディスクの空きが大きいはず なので、同じタイミングにクラッシュしなさそうなのになぁとも思います。 もう一度、インデックス構築中にディスクの空き容量がupdate_buffer_sizeを 下回らないようにdfロギングしながら、インデックス構築を再度やってみようと思いますが （8/25がだめだったのでたぶんだめな気がしますが。。）、 インデックス構築に最低限必要なメモリ、ディスク容量の計算方法はありませんでしょうか？ しかし、インデックス構築にはＳＳＤ４本のＲＡＩＤ０でも９時間ほどかかり、 また、データが毎回破壊されるので、トライアンドエラーもほんとうに大変です。 ・環境 mroonga-3.06.2013.08.20 (vectorカラムの出力区切り文字をセミコロンに書き換え） groonga-3.06の先々週ぐらい時点のmaster (too many postings回避のため、GRN_II_MAX_TF を0x1fffffに書き換え） MySQL5.5.14 CentOS6.4 以上、よろしくお願いします。
