Kouhei Sutou
kou****@clear*****
2013年 9月 17日 (火) 23:11:45 JST
須藤です。 In <52381****@rozet*****> "[groonga-dev,01780] mroongaのメモリーリーク（の疑い）について" on Tue, 17 Sep 2013 18:15:58 +0900, 磯部 和広 <k-iso****@rozet*****> wrote: > ■質問■ > > MySQLをselectオンリーで使い続けると > クエリキャッシュの増加 > 以外は起きないと考えています。 > > マシンはメモリが32GBで、mroongaのデータが11GBですので > mroongaによるメモリーリーク以外に、上記現象が起きる原因は思い当たらない > のですが、他に考慮する現象はあるでしょうか。 うーん、メモリーリークなんですかねぇ。。。 以下を教えてもらえますか？ 1. 「一定時間内に応答しない」ときのmysqldプロセスの VIRT/RES/SHRの値（topで確認したもので十分です。） 2. /proc/${mysqldのPID}/mapsの中身（大きいです。） ファイルにマップされていないメモリ領域が多かったらメモ リーリークの可能性が高くなるなぁと思っています。 手元のシェルのヒストリーにはこんなワンライナーが残ってい ました。これでメモリ使用量を眺めていたみたいです。 % watch -n 1 'cat /proc/$(cat groonga.pid)/maps | ruby -e "ARGF.each_line {|line| range = line.split[0]; file = line.split[5]; low, high = range.split(/-/); usage = high.to_i(16) - low.to_i(16); puts %Q[#{usage}\t#{file}]}" | sort -r -n' 手元で再現するなら、↓な感じでどのクエリーが問題かを絞り込ん で、それからコードのどこらへんが問題かを絞り込んでいったりし ます。クエリーがわかればあとはこっちでできるのですが、そこま でいくのはなかなか難しいですよねぇ。。。 1. 確実に再現するクエリーのパターンを見つける。 この時点では1日流すと再現するとか長くても構わない。 2. 1.で再現したクエリーのパターンを2分割にする。 3. 前半を流して再現 && 後半を流して再現しない （前半再現しない && 後半再現なら以降の前半・後半を逆にする。） 4. 前半が問題なので、以降、後半は無視 5. 前半をさらに半分にする 6. 2.からくりかえす （できれば1つのクエリーがわかるまで。無理ならできるだけ。） 7. 問題のクエリーをステップ実行したりデバッグログをだした りして実行パスを確認 8. 実行パスを前半と後半にわけて…↑と同じようなことをする -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> (03-6231-7270) groongaサポート: http://groonga.org/ja/support/ パッチ採用はじめました: http://www.clear-code.com/recruitment/ コミットへのコメントサービスはじめました: http://www.clear-code.com/services/commit-comment.html
