磯部 和広
k-iso****@rozet*****
2013年 4月 10日 (水) 13:20:48 JST
いつもお世話になっております。 ■結論■ SQL文の先頭に flush tables; を付与し sysctl -w vm.overcommit_memory=1 する事でエラーが出なくなりました。 本当にありがとうございました。 また、教えて頂いたように下記を実施しました。 if ( ! egrep '^sysctl -w vm.overcommit_memory' /etc/sysctl.conf > /dev/null ); then sudo bash -c "echo -e '\n# for mroonga\nsysctl -w vm.overcommit_memory=1' \ >> /etc/sysctl.conf" fi こちらにつきましては、社内のサーバーのセットアップ手順書に含めておきました。 ■詳細■ ＞実データが2.1GB * 120で240GBで、それのインデックスは少なくと ＞も2倍以上にはなっているのではないかと思います。 はい。 2.1GBのテキストファイルをmroonga化すると6GBになります。 mroonga内に インデックス情報 テーブル本体（データ）情報 が格納されるので、インデックスが２倍になっていると思われます。 ＞groongaはデータベースを閉じるまでは一度mmapした領域をunmapし ＞ません。mroongaで言えばFLUSH TABLESを実行するとgroongaのデー ＞タベースを一度閉じています。 ＞これで回避できている理由がわからないのですが、明示的にFLUSH ＞TABLESを実行しても回避できるのではないかと思います。 ＞（MySQLは自動的にFLUSH TABLES相当のことをするのでしょう ＞か。。。） groonga.logを調査しました。 内部的に、mroongaの再起動が掛かっているようです。 [root ＠ PMJ01 mysql]# grep -B2 'mroonga 3.02 started.' groonga.log | head -n 21 | tail -n 11 2013-04-09 13:26:17.486475|C|12844700|mmap failed!!! in GRN_IO_SEG_REF(0x7ef87d4574a0, 169, 1) 2013-04-09 13:26:17.486480|e|12844700|cursor open failed 2013-04-09 13:26:21.354717|n|c14eb7e0|mroonga 3.02 started. -- 2013-04-09 13:27:20.055359|A|1c1fe700|/usr/libexec/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x105) [0x5b8f35] 2013-04-09 13:27:20.055364|C|1c1fe700|mmap failed!!! in GRN_IO_SEG_REF(0x7efe0466f470, 53, 1) 2013-04-09 13:27:24.167334|n|8dabc7e0|mroonga 3.02 started. -- 2013-04-09 13:36:03.263132|C|e40c4700|mmap failed!!! in GRN_IO_SEG_REF(0x7f9f514574a0, 353, 1) 2013-04-09 13:36:03.263137|e|e40c4700|cursor open failed 2013-04-09 13:36:07.306581|n|725827e0|mroonga 3.02 started. [root ＠ PMJ01 mysql]# この再起動が掛かると、エラー状態から回復するようです。 ＞# sysctl -w vm.overcommit_memory=1 実施しましたが、効果はあったものの、完治しませんでした。 エラーが起きた後に、リカバリーとして flush tables; を実行し、エラーになったSQLを再実行しても再度エラーとなりました。 この為、実行するSQL文の先頭に flush tables; を加えた所、全くエラーが起きなくなりました。
