saki kashi
saki.****@gmail*****
2014年 11月 11日 (火) 19:18:34 JST
kashiharaです。 max_map_count増加したところ、再起動しなくなりました。 vm.max_map_count=100000->再起動 vm.max_map_count=150000->再起動せず 細かい値については、現在調査中です。 search_field というtext型のカラムにFULLTEXT INDEXを貼っていますが、このFULLTEXT INDEXを削除すると、max_map_countを変更しなくても再起動せず、 category_idsというタグ検索のカラムは削除しても再起動していました。 180万件のデータを一気に消すというのはあまりないケースではありますが、 念のためmax_map_countを増やして運用したいと考えています。 max_map_countを設定するにあたり、データベースサイズ以外の指標などあったりしますでしょうか。。 2014年11月11日 12:36 Kouhei Sutou <kou****@clear*****>: > 須藤です。 > > In <CAA3x****@mail*****> > "[groonga-dev,02945] Re: delete後にselectするとmysqlが再起動する" on Tue, 11 Nov > 2014 10:38:24 +0900, > saki kashi <saki.****@gmail*****> wrote: > > > 検証環境では、同じデータに対して実行すると、必ず再現する状態になっています。 > > データに関してはそのままお渡しするのが難しいため、加工したデータでも再現されるのかどうか、こちらで確認してみますね。 > > ありがとうございます。 > > > mmap Cannot allocate memoryエラーを回避するには > > こちら確認させていただきましたが、 > > 今回対象のDBサイズは2.1Gでvm.max_map_count は既に65530でしたので、 > > 不足しているということはないように感じます。 > > groonga.logを見るとこれに該当している可能性が高いと思いまし > た。なので、vm.max_map_countを増やしてもう一度試してみてもら > えないでしょうか？ > > > groonga.logの記載した以前のログです。大量に出ているので一部分を切り取っております。 > > もしこれでも不足しているようでしたらお知らせください。 > > mmap(...)=Cannnot allocate memoryのやつだけを抜き出すとこん > な感じになっています。 > > > 2014-11-10 16:27:20.022243|A|7afff700|mmap(20480,-1,0)=Cannot allocate > memory <18656522240> > ... > > 2014-11-10 16:27:20.025597|A|7afff700|mmap(20480,-1,0)=Cannot allocate > memory <18656522240> > ... > > 2014-11-10 16:27:20.028278|A|7afff700|mmap(20480,-1,0)=Cannot allocate > memory <18656522240> > ... > > 2014-11-10 16:27:41.494837|A|7afff700|mmap(4194304,-1,0)=Cannot allocate > memory <18656522240> > > 注目するポイントは最後の「<18656522240>」の部分です。 > > 全部同じになっているので、上限に達したんだということがわかり > ます。 > > http://groonga.org/ja/docs/troubleshooting/mmap_cannot_allocate_memory.html > > のページにはデータベースを開くときしかmmap()しないような計算 > 式になっていますが、実際は一時データ（たとえば検索結果を保存 > する場所とか）や内部データ用の領域もmmap()しています。 > > （↑のログのmmap(...)は第2引数が-1になっていますが、-1になっ > ているのはこういった一時データや内部データ用の領域を確保する > ためのmmap()です。） > > なので、データベースサイズは小さくても、今回のように検索結果 > （delete対象を検索しています）が大量になる場合は、一時データ > 用の領域を確保するためにmmapする数が増えるので上限に達したん > だと思います。 > > ということで、vm.max_map_countを増やしてもう一度試してみても > らえないでしょうか？ > > > もし、1回だけ大量レコードを扱っても問題が起きないのに、何度 > もやると問題が起きる、という状況だったら、一時データの開放を > もっとこまめにやれるのにやっていないところがあるのかも。。。 > という気はしています。 > > > -- > 須藤 功平 <kou****@clear*****> > 株式会社クリアコード <http://www.clear-code.com/> > > Groongaベースの全文検索システムを総合サポート: > http://groonga.org/ja/support/ > パッチ採用 - プログラミングが楽しい人向けの採用プロセス: > http://www.clear-code.com/recruitment/ > 名著『リーダブルコード』を解説者と一緒に読み解こう: > http://schoo.jp/class/1502 > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev >
