Naoya Murakami
visio****@gmail*****
2013年 8月 26日 (月) 22:43:21 JST
お世話になっております。村上です。 アドバイスありがとうございます。 以下の２パターンで試しましたが、どちらも、同じタイミングでクラッシュしました。 （１）オーバーコミット無効、スワップは100G程度 mysql 5.5.14 vm.overcommit_memory=2 vm.overcommit_ratio =99 クラッシュ時の空きディスクは140G程度 2013-08-26 12:15:24.929599|n|312d3700|nterms=236 chunk=2186602 total=5908644KB 2013-08-26 12:15:27.897238|n|e77bc720|mroonga 3.06 started. （２）オーバーコミット有効、スワップは100G程度 mysqldのoom_adjに-17 vm.overcommit_memory=1 mysql 5.6.13にバージョンアップ groonga-3.0.6.2013.08.26 mroonga-3.06.2013.08.26 2013-08-26 22:37:55.039041|n|5490c700|nterms=236 chunk=2186602 total=5908644KB 2013-08-26 22:37:58.571426|n|46a08720|mroonga 3.07 started. どちらも、メモリ、ファイルオープン数、ディスクサイズに怪しい動きなし メモリとかプロセス数とかファイルオープンリミットとか思いつくOS資源 はかなり上限値をあげているのですが、使えるOS資源が枯渇してクラッシュ しているのであれば、そのときどきで多少クラッシュするタイミングがずれる ような気もしています。 もう、ちょっと切り分ける方法が思いつかないですね。。 あとは、インデックス有効の状態で全件ぶちこむか、分割するしかないかなぁ。。 別のさらに大きいデータベースで、インデックス有効の状態で直接ぶちこんで、 どのくらいかかるか試していますが、いまのところ、２〜３日かかりそうなスピード感です。 このとき、同じテーブル構造のmroonga→mroongaのinsert selectでも、 grn_str_charlen_utf8(): imcomplete characterが多数でており、 このメッセージの影響が知りたいと思っていたり。。 以上、よろしくお願いします。
