操作
バグ #925
未完了
mikutterがメモリを大量に消費することがある
プラグイン名:
ブランチ:
クラッシュする:
説明
いわゆるダークマターです。
https://github.com/toshia/memory_profiler/ を入れて1日半程度起動しっぱなしにしておいたmikutter(e1b61877)でグラフを生成したところ、次のグラフが得られました。
この時点でVIRTが20,844,868KB, RESが18,716,708KBとなっています。
GC.start; File.open('/tmp/strings.txt', 'w'){|f| f.puts(ObjectSpace.each_object(String).to_a)}をmikutterコンソールで実行し、生き残っているStringのリストを得る$ cat /tmp/strings.txt | sort | uniq -c | sort -k1 -r | head -n30でダブリ個数の上位30件を取ってくる
以下はその結果です。どうもcairoに渡している色コード（詳細不明）と、画像関係っぽい文字列が異常に多く生き残っているようです。
40392 ja 31135 fit 19951 000000 16739 C0DEED 15604 https 15599 twitter.com 14341 333333 14159 Tokyo 12637 none 10775 10378 crop 10191 DDEEF6 10129 photo 9794 https://abs.twimg.com/images/themes/theme1/bg.png 9794 http://abs.twimg.com/images/themes/theme1/bg.png 8553 low 6356 FFFFFF 6162 0084B4 4896 recent 4741 njslyr 4515 /home/osak/app/mikutter/core/lib/uithreadonly.rb:23:in `block (2 levels) in singleton class' 3915 /search 3076 1DA1F2 2899 <a href="http://twitter.com" rel="nofollow">Twitter Web Client</a> 2880 en 2871 http 2846 pbs.twimg.com 2780 #njslyr 2680 mikutter.rb:92:in `<main>' 2679 mikutter.rb:63:in `boot!'この時点でのオブジェクト数のうち、メモリやオブジェクトの使用量に相関していそうなものの値は以下の通りでした。
>>> GC.start;ObjectSpace.each_object(Message).count
12605
>>> GC.start;ObjectSpace.each_object(User).reject{|u| Message::MessageUser === u}.count
7738
>>> GC.start;ObjectSpace.each_object(Gtk::TimeLine).reject{|t| t.destroyed?}.count
113
>>> GC.start;ObjectSpace.each_object(Gtk::TimeLine).reject{|t| t.destroyed?}.map(&:size).sort.reverse
[3959, 1243, 1041, 383, 206, 200, 200, 200, 200, 187, 182, 119, 117, 108, 97, 84, 76, 73, 60, 60, 59, 59, 58, 56, 52, 51, 44, 41, 41, 40, 40, 39, 38, 37, 35, 35, 34, 34, 29, 28, 27, 27, 27, 27, 25, 24, 24, 23, 23, 23, 22, 22, 21, 21, 20, 20, 14, 13, 12, 10, 8, 8, 7, 6, 5, 5, 5, 5, 4, 3, 3, 3, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
>>> GC.start;ObjectSpace.each_object(Hash).map(&:size).sort.reverse[0..30]
[41108, 27682, 12673, 7760, 7757, 5096, 4233, 4010, 1620, 1270, 1041, 1017, 918, 811, 498, 485, 436, 383, 383, 379, 373, 373, 348, 327, 327, 310, 291, 273, 262, 256, 253]
>>> GC.start;ObjectSpace.each_object(Gdk::Pixbuf).count
3905
>>> require 'objspace'
GC.start;ObjectSpace.memsize_of_all(String)
164113887
>>> require 'objspace'
GC.start;ObjectSpace.memsize_of_all(Array)
15699400
>>> require 'objspace'
GC.start;ObjectSpace.memsize_of_all(Hash)
159073600
あと入ってるプラグイン一覧：
YUKI.N@aincrad> ls ~/.mikutter/plugin display_requirements/ memory_profiler/ osa_k_store/ sub_parts_client/ dummy_dep/ mikustore/ pakuri/ toshi_a_store/ eject/ mikutter-fb/ penguin2716_store/ usercomplete/ favorited_count/ mikutter-subparts-image/ protected_source/ userutil/ geocode/ mikutter_shell_post/ randnum/ yukkuri_/ intelligent_fav/ mikutter_update_with_media_/ sakuratrick/ matsuyatter/ mikutter_yodobashi/ shindanmaker/ md5tweet/ nonomura/ show_tweet/
問題になりそうなものは
- 単純にMessageが多く、そもそも200個を超えてMessageを保持している謎のGtk::TimeLineがいる（ちなみにプロフィールと抽出タブを合わせて50個くらいタブを開いているので、プロフィール1つにつきTLとDMの2つGtk::TimeLineが生成されることを考えると、TLの個数自体は妥当だと思います）。
- mikutter内に存在する、意味のある（と想像される）オブジェクト数に対して、異常に巨大なハッシュが存在する
- スタックトレースの断片のようなものが見える（ただしこれは時間経過で増えないっぽい）
あたりだと思われます。ただそれにしても、memsize_of_allの結果と比べて実際の消費メモリが多すぎるのが少し気になります。
とりあえずはみんなから情報が集まるといいな。
ファイル
関連するチケット
操作