murata satoshi
murat****@gmail*****
2016年 7月 18日 (月) 20:39:18 JST
村田です。ご確認とご返答ありがとうございます。 取り急ぎこちらも回答させたいただきます。 > たしかに、実行するたびにalloc_countが増えています。 > さらに続けていると > 1ずつしか増えなくなりました。 > さらに1000回以上続けていると > 今度はalloc_countが減り始めました。 切り分けができていないので条件が不明ですが、確かに1ずつしか増えない場合もありました。 （1回目のみ多めに増えて、2回目以降は1ずつ増加する、というケースもありました。） また、alloc_countが減ることがあるというのも確認しております。 ただ、減り続けるわけではなく、一度減ってまた増加していたように思えます。 （あまり多くの回数を試行したわけではないのですが、、、 > mrubyのGCが原因の場合はOOMで落ちる前にalloc_count（メモリー > 使用量）が減ると思うので妙なんですよね。。。 OOMが発生したのは先述の確認用ではなく実運用の環境なのですが、こちらの状況も記載します。 こちらではmatch…againtとmroonga_command(‘select…’)と通常のSELECTが混在で発行されています。 （絞り込み条件/ソート条件も多岐にわたっており、同じ問い合わせが連続で…というものではありません。） また、他のinnodbテーブルと共存しています。mrn.*ファイルの合計サイズは約5.5G程です。 innodb_buffer_poolが埋まった時点で空きメモリ(free+cached)13G程度でした。 (同時接続数とthread_bufferでの消費はこのケースでは無視できるレベルかと思います） そこから徐々に空きメモリが減り続け(mysqldのVIRT/RES共に増加）、空きメモリが2G近辺で IOの増加と対象テーブルへの操作におけるパフォーマンス低下が見られました。 （OOM直前の空きメモリは確認出来ていません。） また、その後OOM前に再起動させたケースでalloc_countを監視しておりましたが alloc_countは時折減少しながらも徐々に増加し続けていました。 > そもそもmrubyのGCが必要にならないように、一時的に作るオブジェ > クトを減らしておきました。次のリリースからは、このケースでは > alloc_countが増えなくなるはずです。 ありがとうございます。次のリリースで解消するようならそれまで定期再起動で乗り切れると思います。 他に必要な情報があればお申し付けください。 また、調査にご協力できる事があれば調査方法等ご教授ください。 以上、宜しくお願い致します。 ------------ murat****@gmail***** <mailto:murat****@gmail*****> -------------- next part -------------- HTMLの添付ファイルを保管しました...Download