Project

General

Profile

バグ #198

ダークマターの討伐

Added by toshi_a 初音 over 8 years ago. Updated over 5 years ago.

Status:
終了
Priority:
通常
Target version:
プラグイン名:
ブランチ:
クラッシュする:

Description

長時間起動していると、際限なくメモリを消費していく。


Files

proc-spread.png (128 KB) proc-spread.png Procオブジェクトの生成された場所ごとの個数 toshi_a 初音, 2011-05-30 01:31
memory.png (169 KB) memory.png オブジェクト別の個数 toshi_a 初音, 2011-05-30 01:31
iter.png (118 KB) iter.png Gtk::TreeIterが回収されない toshi_a 初音, 2011-06-04 12:33
iter.png (50.2 KB) iter.png Gtk::TreeIterを節約した。短時間しか測ってないけどずいぶんマシでしょう toshi_a 初音, 2011-06-04 12:33
memory.png (155 KB) memory.png オブジェクト別個数。やっぱりTreeIterだな toshi_a 初音, 2011-09-29 23:59
out.png (263 KB) out.png 2012/1/5の、trunkでの計測結果。10時前から後は役に立たないが、Procのグラフが段になってるのが気になる toshi_a 初音, 2012-01-06 01:27
out2.png (91 KB) out2.png toshi_a 初音, 2012-01-07 05:42
miraclepainter.png (17.5 KB) miraclepainter.png toshi_a 初音, 2012-01-07 05:42
mikutter-memory.gtk_liststore.png (79 KB) mikutter-memory.gtk_liststore.png home_timelineだけをインストールした状態での、Gtk::ListStore(Model)の数の変化 toshi_a 初音, 2012-11-30 23:12
mikutter-memory.png (146 KB) mikutter-memory.png home_timelineだけをインストールした状態での、各クラスのインスタンス数の変化(ベスト10) toshi_a 初音, 2012-11-30 23:15

Subtasks

バグ #523: タイムラインのスクロールによるメモリ使用率の上昇新規Actions
バグ #556: Gtk::TreeIterがリークしている問題終了toshi_a 初音Actions
最適化 #564: ダークマターが潜むプラグインの特定新規Takuma Nakajima

Actions

Associated revisions

Revision d28476b9 (diff)
Added by toshi_a 初音 almost 8 years ago

miraclepainterでProcオブジェクトを無駄に作成していたのを削減 refs #198

git-svn-id: svn://toshia.dip.jp/mikutter/trunk@631 03aab468-d3d2-4883-8b12-f661bbf03fa8

Revision e95479d4 (diff)
Added by toshi_a 初音 almost 8 years ago

miraclepainterでProcオブジェクトを無駄に作成していたのを削減 refs #198

git-svn-id: svn://toshia.dip.jp/mikutter/trunk@631 03aab468-d3d2-4883-8b12-f661bbf03fa8

Revision 560cd1ad (diff)
Added by toshi_a 初音 almost 8 years ago

Gdk::MiraclePainterが解放されていなかった問題を修正 refs #198

git-svn-id: svn://toshia.dip.jp/mikutter/trunk@632 03aab468-d3d2-4883-8b12-f661bbf03fa8

Revision fa7ba2e9 (diff)
Added by toshi_a 初音 almost 8 years ago

Gdk::MiraclePainterが解放されていなかった問題を修正 refs #198

git-svn-id: svn://toshia.dip.jp/mikutter/trunk@632 03aab468-d3d2-4883-8b12-f661bbf03fa8

History

#1

Updated by toshi_a 初音 over 8 years ago

Gtk::TreeIterが全くGCされない。おそらくRubyGtkのバグかと思われる。
これはバグ報告するにしても、ただちにメモリリークを直せるわけではないので、値の参照の時にはGtk::TreeIterをアロケートしないようにした。

#2

Updated by toshi_a 初音 over 8 years ago

Gtk::ListStore#flags を呼びだすと、 Gtk::TreeModel::ITERS_PERSIST がセットされている。どうやらこれがセットされていると Gtk::TreeIter が開放されないらしいんだけどもう眠いしまた今度ね

#3

Updated by toshi_a 初音 over 8 years ago

  • Status changed from 様子見 to 実装待ち
#4

Updated by toshi_a 初音 over 8 years ago

Gtk::TreeIterがGCされないので、ツリーごと殺すようにしてみた、これはひどい。
それはまた本家にフィードバックするとして、こんどはArrayが妙に増えるようになったみたいなので調べる

#5

Updated by toshi_a 初音 over 8 years ago

  • Subject changed from メモリリークへの対応 to ダークマターの討伐
#6

Updated by toshi_a 初音 over 8 years ago

  • Target version set to 0.0.3
#7

Updated by toshi_a 初音 about 8 years ago

未だ悪さをするのはTreeIterらしい。

#8

Updated by toshi_a 初音 almost 8 years ago

Gtk::TreeIterはとりあえずはましになってる。これ以上手を付けられない気がするので、先に他のところをやっつける。
一部Procオブジェクトが線形に増えているので、それを削減する(クロージャのスコープに巻き込まれることがあるため)。

#9

Updated by toshi_a 初音 almost 8 years ago

10時以降のデータは、mikutterのメモリ使用量的に限界に達したと思われるので、あまり意味のある値ではない。
下のグラフ(Procの統計)で、sub_parts_voter.rbのinitialize()内で作られたProcが定期的に段を作るように増えて行っているのは、Gtk::TreeIterのメモリリーク対策で強制的にリストビューを破棄しているところで、そのProcが解放されずに残っているということかもしれない。

#10

Updated by toshi_a 初音 almost 8 years ago

10時半以降のデータはmikutterの限界ry
Gdk::MiraclePainterが一切解放されていなかったので、 r632 で少し修正を加えた。
これで、コメント9で問題にしたcairo_subparts_voterのProcオブジェクトはMiraclePainterと共に解放されるようになった。
ただし、この版では、TLのリフレッシュ時にはMiraclePinterが解放されるようになったようだが、依然としてインスタンス数は添付のmiraclepainter.pngの通り増加していっている。タイムラインから溢れて削除する処理について、もう一度見直す。

#11

Updated by toshi_a 初音 almost 7 years ago

home_timeline, rest, streaming, gui, gtkの5プラグインだけを入れた状態でテストしてみたところ、やはりTreeIterがかなりメモリリークしている(RubyGtk1.1.5)。起動中のインスタンスを調べたところ、Gtk::TimeLineは1つ、Gtk::TimeLine::InnerTL(view)とGtk::ListStore(そのModel)はそれぞれ10個あり、1つを除いてはすべて破棄済み(destroyed? #=>true)だった。Gtk::ListStoreの数もグラフにプロットしてみたところ、どうも定期的にInnerTLを破棄する処理がされたあと、InnerTLがガベージコレクトされずに残ることがあるらしい。
グラフを見る限り、正しくInnerTLが破棄されればTreeIterも開放されるようで、実際二つのグラフは形が非常に似通っているため、InnerTLへの参照を切ることが出来れば、劇的な改善が期待できる。

他にこのグラフの気になる点としては、Gtk::ListStoreの開放に長くて15分程度かかっていること。サンプルを取る前に毎回明示的にガベージコレクタを呼んでいるので、この間どこかで参照が保持されていると考えられる。

#12

Updated by toshi_a 初音 almost 7 years ago

添付ファイル間違えた

#13

Updated by toshi_a 初音 almost 7 years ago

  • File deleted (memory_profiler.rb)
#14

Updated by toshi_a 初音 almost 7 years ago

Gtk::TreeIter関連の話は、今後 #556 に書く。

#15

Updated by toshi_a 初音 over 5 years ago

  • Status changed from 実装待ち to 終了

このチケットはある程度の成果を出したがまだ不十分です。しかし目標が明確でないので、今後は具体的な問題が分かり次第トピック毎にチケットを作成するようにします。

Also available in: Atom PDF