Kouhei Sutou
kou****@clear*****
2013年 5月 14日 (火) 12:04:00 JST
須藤です。 In <5190F****@rozet*****> "[groonga-dev,01384] mroongaのメモリ解放方法について" on Mon, 13 May 2013 23:09:41 +0900, 磯部 和広 <k-iso****@rozet*****> wrote: > ■概要■ > > rronga等、直接groongaとお話しする場合、下記のようにしてメモリが解放でき > るようです。 > http://sourceforge.jp/projects/groonga/lists/archive/dev/2011-December/000641.html > > mroongaを使う場合、どのようにしたらgroongaのメモリを解放できるのでしょうか。 うーん、FLUSH TABLESで解放できているはずなんですよねぇ。。。 > ひょっとして、3.0.2で追加された > ○ mroonga_commandのサポート(実験的) > で可能だったりしますか？ いえ、それではできないのです。。。 > ■詳細■ ... > エラーは出なくなりましたが、今度は > 時々、酷い時には数十分、ping以外には全く反応しなくなる > その際には、HDDのアクセスランプが点きっぱなしになる > という状況になりました。 スラッシングしているということですね。 > バッチ処理で、検索語を次々変えながら > 連続してmroonga検索を１日以上続けるとこのような状況になりやすいです。 > ※１回の検索は数秒〜数十秒です。 > DBマシンが無応答になると、当然その間の検索は止まりますが結果自体は取得 > できます ... > MySQLを再起動してみたのですが、やはり状況が変わりません。 > > どうも、mroongaがメモリを掴み、離さないようです。 MySQLを再起動（一度終了）しているのであればmroongaはOSにはメ モリを解放するということを伝えているはずです。ただ、OSのペー ジキャッシュには残るはずです。 もし、ページキャッシュもがっつり開放したい場合は以下で開放で きます。 % sudo sysctl -w vm.drop_caches=3 が、解放してもあんまり意味ないかも。。。という気はします。 というのは、キャッシュなので必要がなくなったら追い出されて必 要なデータが来たら代わりにキャッシュするというのをOSが自動で やってくれるはずだからです。 > SQL文の末尾にも > flush tables; > を付与したのですが、状況は変わりません。 これは、各SELECTの後に入れましたか？それともすべてのSELECTの 後に1つだけ入れましたか？ SELECT ...; FLUSH TABLES; SELECT ...; FLUSH TABLES; ... としたか、 SELECT ...; SELECT ...; ... FLUSH TABLES; で変わってきそうだなぁと思ったからです。 前者なら1回のSELECTで読み込まないといけないデータ量がメモリ サイズ以下ならスラッシングを回避できそうな気はします。 後者なら回避できなそうだなぁという気がします。 ただ、前者の場合でも1回のSELECTでメモリサイズ以上のデータを 扱わないといけない場合はスラッシングは避けられない気がします。 どうにかして調べられればいいのですが。。。 > VmallocTotal: 34359738367 kB って物凄いですね・・・ 仮想メモリのサイズですね。 groonga単体で使っているときでも仮想メモリはもりっと大きくな るのですが、mmap(2)を使っているからなのであまり気にしなくても 大丈夫です！ -- 須藤 功平 <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
