yoku ts.
yoku0****@gmail*****
2016年 7月 20日 (水) 10:15:23 JST
こんにちはこんにちは。 アレはmalloc-lib限定のオプションでしたので、今回のケースには使えないと思います。 https://osdn.jp/projects/groonga/lists/archive/dev/2015-February/003082.html ので、俺がやるにしてもmysqld_safeか/etc/init.d/mysqldに書いちゃうと思います :) yoku0825, 2016年7月20日 9:59 Kouhei Sutou <kou****@clear*****>: > 須藤です。 > > In <D02F8****@gmail*****> > "[groonga-dev,04084] Re: Mroongaストレージモードでメモリリークの可能性" on Wed, 20 Jul 2016 00:23:39 +0900, > murata satoshi <murat****@gmail*****> wrote: > >>> それでは次の変更をして状況が改善されるか確認してもらえないで >>> しょうか？masterでの対応と同等の一時オブジェクトを減らす対応 >>> になります。 >> >> >> ありがとうございます。この変更を適用した上で各パターンで確認してみました。 > > ありがとうございます。 > 1条件の検索では増えなくなっているので、効果はあるようです。 > > 2条件以上の検索ではこの対策は関係なくなる(*)のですが、そのケー > スのときにメモリー使用量が増えていっているように見えます。 > > (*) 単純な条件の場合はmrubyを使わずに実行計画を決め、複雑な > 条件はmrubyを使って実行計画を決めるようになっていて、単 > 純な条件のケースでは一時オブジェクトが一切増えないように > する、というのが今回確認してもらった変更でした。 > > >> また、上記各パターン混在のSQL群を投げ続ける試験も実施してみました。 > > このデータは非常に助かります。たしかにメモリー使用量が増加傾 > 向にあることがわかります。mrubyが関係しているかどうかを切り > 分けたいので > > GRN_MRUBY_ENABLED=no > > という環境変数を指定してmysqldを起動し、同様の試験を実施して > みてもらえないでしょうか？環境変数を指定してmysqldを起動する > 方法は、前にyoku0825さんに教えてもらった気がするんですが忘れ > てしまいました。。。 > > 私がやるなら、一時的なものなので、/usr/bin/mysqld_safeの最初 > の方に > > export GRN_MRUBY_ENABLED=no > > を入れてMySQLのサービスを再起動します。 > > > この環境変数を指定するとmrubyが無効になります。mrubyが無効に > なるとalloc_countがものすごく少なくなるので確認はすぐにでき > ます。1500台からそんなに増えないはずです。 > > > -- > 須藤 功平 <kou****@clear*****> > 株式会社クリアコード <http://www.clear-code.com/> > 10周年祝いイベント： http://www.clear-code.com/blog/2016/7/13.html > > Groongaベースの全文検索システムを総合サポート: > http://groonga.org/ja/support/ > パッチ採用 - プログラミングが楽しい人向けの採用プロセス: > http://www.clear-code.com/recruitment/ > > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.osdn.me/mailman/listinfo/groonga-dev
