パスワードを忘れた? アカウント作成
353008 story

Firefoxが無駄に消費しているメモリの正体が突き止められる 52

ストーリー by hylom
ダークマターとは大仰な 部門より

greentea 曰く

Firefoxに長らく存在していた用途不明なヒープメモリ、通称「ダークマター」の発生原因のひとつが突き止められたらしい(マイコミジャーナルの記事)。このダークマターはFirefoxが使うメモリのうち結構な比率を占めているそうで、この問題が解消されるとメモリ使用量の大幅な減少が期待できるとのこと。

Nicholas Nethercote氏によってなされた報告によると、jemallocのメモリアロケート時に発生する未使用領域がダークマターの原因のひとつとなっているそうだ。jemallocでは確保したメモリを開放するときにフラグメンテーションが発生しにくくなるように、特定のサイズに区切ってメモリの確保を実施している。Nicholas Nethercote氏はこの領域を「スロップ」と呼んでおり、このスロップがメモリ食いの原因とのこと。スロップを完全に排除するには、jemallocの確保するメモリサイズである2のべき乗で容量を確保すればよい。

すでにどの部分でスロップが発生しているのか大枠で特定されており、Firefox 8やFirefox 9以降のFirefoxは、メモリ使用量が大幅に減る可能性があるとのこと。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • ダークマターなどと (スコア:3, おもしろおかしい)

    by Anonymous Coward on 2011年08月11日 21時44分 (#2001572)

    格好いい表現を使ってるから、事の本質や重大さや深刻さが誤魔化されてしまうんですよ。

    • by Anonymous Coward
      いやー、言い得て妙な強烈な皮肉だと思いましたよ
      こんなに笑ったのは久しぶり
      • by Anonymous Coward
        この表現、積極的に活用したい。
        • by Anonymous Coward
          同意。

          メモリ食い過ぎバグにはよく悩まされるが、この発想はなかった。
  • まあ、1つで6週間ですからね。
    18週間か24週間。

    うん、結構先だ。

    • by Anonymous Coward
      途中はまとめてディスコンってことにして
      一気に13まで上げちゃっていいよもう
      とか思っちゃう

      # 開発側のバージョンコンプレックに付き合わされるアドオン開発者がかわいそう
    • by Anonymous Coward
      なんかこういうものこそ、モジュール化して
      既存バージョンで置換えが出来ればいいのにと思ってしまう。
  • by parsley (5772) on 2011年08月11日 0時13分 (#2001047) 日記

    jemalloc()~Firefox 3.爆速の理由~ [mew.org](PDF)

    どっちにすればいいのとは思うけど、バランスをかんがえないのか?
    そもそもjemallocを改良するとかそっちで貢献しようとか

    --
    Copyright (c) 2001-2014 Parsley, All rights reserved.
    • by superfox (31908) on 2011年08月12日 14時45分 (#2001929)

      そもそもjemallocを改良するとかそっちで貢献しようとか

      記憶によれば、jemalloc()が有名になったのはFreeBSDのSMPng終了アナウンス時のパフォーマンステストでLinuxを抑えたとき。
      そして、その時「Linuxはglibcのmalloc()に問題あるんじゃね?」と言い出した人はLD_PRELOADか何かでgoogle malloc()と差し替えて評価してたはず。

      なのでまずは現行バージョンのgoogle malloc()版を出してみて欲しい。

      親コメント
    • by Anonymous Coward
      メモリ消費量やレンダリング速度がどう変わろうとも
      コールドスタートのクソ重さは全く改善されないのがfirefox。

      今のところのFxチームの対応策は
      コールドスタートの件には沈黙して
      レンダリングが「早くなった!」と騒ぐだけ。

      信者もしっかりと、
      「(レンダリングが前のバージョンと比較して)爆速!」
      としか言わない。

      chromeに負けるのは必然。
      バージョンナンバーとか小手先の問題で回避できる問題じゃない。
      • by Anonymous Coward on 2011年08月12日 2時29分 (#2001645)

        単に君のアンテナが低いだけだろう。つい最近の大幅な高速化話は日本語の記事も出てたよ。

        http://japan.internet.com/webtech/20110625/3.html

        『Firefox 7』(タイプミスではない) では、コールドスタートに一連の改良を施すことで、『Linux』上における同ブラウザの起動がきわめて高速化するという (もちろん『Windows』上でも高速化する)。

        http://journal.mycom.co.jp/news/2011/06/22/095/index.html

        Bugzillaのコメント欄には、遅いディスクにおいて20%ほどの高速化が実現されるほか、高速なディスクであればさらに大幅な高速化が期待できると説明がある。なおMac OS XのFirefoxにはこの機能は適用されない。OSXのバイナリはユニバーサルバイナリであるため、この機能の恩恵を受けるにはサイズが大きすぎるためだと説明がある。

        Firefox Planet [firefox.com]あたりをチェックしていれば大抵のネタは手に入るので、フィードリーダーにでもブチ込んでおいたら?

        親コメント
      • by Anonymous Coward

        ブラウザにおけるコールドスタートって何だ?スタートアップかなにかに登録しておいて、電源を投入してから最初にブラウザ画面が表示されるまでの時間、みたいなのを問題にしてる?

      • by Anonymous Coward
        そりゃ中身空っぽのChromeの方が
        コールドスタート()が早いのは必然だわなw
        • by Anonymous Coward

          あれ、記憶しておいたページポインタを表示するのって普通の機能じゃなかったんだっけ?

          • by Anonymous Coward

            ページポインタって初めて聞いたけど、一体なんですかそりゃ。
            考えてもさっぱりわからん。

  • 2nより細かい単位、たとえば20.5nとかで区切ればいいのに。サイズとの対応が簡単に計算できればよくて、20.5nでもたかだか128エントリなんだから表にしちゃったっていいし、log2n求めてから選んでもいい。アロケータ内部の結構簡単な修正で他には修正いらないから局所性も高い。

    ...なのに...何考えてんだろ。

    • マイコミジャーナルの方にはちゃんと「基本的には2のべき乗」と書いてあるのを、私が「基本的には」をはしょったのですが、
      http://blog.mozilla.com/nnethercote/2011/08/05/clownshoes-available-in... [mozilla.com]
      を見ると、完全な2のべき乗ではないようです。(貼り付けようと思ったら、空白が多すぎるとかで投稿フィルタにひっかかる...)
      どっちにせよ、もっと細かい単位でとるようにすればいい話なのですが。

      はしょった部分については、紛らわしいので、修正しておきます。

      --
      1を聞いて0を知れ!
      親コメント
      • いやー、どっちにしても根本的な問題と解決法は同じで、ユーザ側でサイズを変えても統計に出ないだけで無駄なままだし、もっと細かくする以外の解はないし。ほぼO(1)で速くてフラグメント起きにくくてと、いいアルゴリズムなんだけどねー。

        あと、ユーザプロセスであることを考えると実メモリの無駄はあんまり多くないはず。
        実メモリの無駄も多いんなら領域返却時に返せるページを返してない手抜きコードだわな。
        # これもアロケータの修正だけで直るけどな。

        親コメント
        • by Anonymous Coward on 2011年08月11日 17時19分 (#2001451)

          2のべき乗で確保するのはすでに行っていたけど、サイズを計算した後で文字列末尾のnullバイトの分を足したりヘッダサイズを足したりしてからjemallocに渡していたので、意図した割り当て量の2倍近く割り当てられてしまった上に半分近くはまったく何にも使えず完全な無駄になっていたという話。バグ以外の何者でもない。ご高説のとおりに2のべき乗で割り当てるのがそもそも妥当でないとしてもそれはまったくの別問題。
          > ユーザ側でサイズを変えても統計に出ないだけで無駄なままだし、
          アロケータの割り当て量そのものが半分になる。
          > 領域返却時に返せるページを返してない
          返却されないで無駄になってる。そもそもユーザ側は無駄な領域が存在することさえ認識していない。

          親コメント
          • ん?それって、確保サイズの半分扱いで返却する事があるって事か?

            親コメント
            • by Anonymous Coward on 2011年08月12日 7時31分 (#2001668)
              jemallocはすでにテーブルに基づいて割り当て量を決めている。サイズが小さいところは2^n、大きいところは1M,2M,3M。実際にFirefoxを起動して「要求したサイズ、実際に割り当てられたサイズ、無駄になったサイズ」のダンプを作ったところ、「1M+ちょっとを要求して2Mが割り当てられた」みたいなケースが不思議と多かった。なんでか調べたら4つのケースでそういうこと、つまり必要量を2^nにラウンドアップした後にちょっとをたすみたいなことが結果的に行われていた。Nicholasの報告より。
              親コメント
              • by Anonymous Coward
                違う違う。

                #2001451 [srad.jp]には、

                > > 領域返却時に返せるページを返してない
                > 返却されないで無駄になってる。

                と書いてあるけど、2^(n+1)で確保されてしまったメモリを返却しようとしたら
                2^n+チョットしか開放できないなんておかしくないか?という指摘だよ。

                malloc側では2^(n+1)で割り当てたのだから開放も2^(n+1)なんじゃないの?ということ。
              • by Anonymous Coward
                > と書いてあるけど、2^(n+1)で確保されてしまったメモリを返却しようとしたら
                > 2^n+チョットしか開放できないなんておかしくないか?という指摘だよ。

                jemallocでも2^(n+1)でmallocしたメモリをfreeしたら2^(n+1)返却されます。それはさすがに。

                今回の問題は
                ・jemallocは内部でメモリ量をランドアップして確保している
                ・jemallocを使う側の中に、メモリ量をランドアップしてから+チョットしてjemaloocにメモリ要求していたものがあった
                というののあわせ技ということで。

                ちなみにみんな2倍、2倍といってるけど、そういうわけで必要量の4倍近くとってたケースもあると思われ。
          • by Anonymous Coward
            あれでは単純にjemallocを、mallocあたりに置換してしまえば
            問題解決するように読めますよね。
          • by Anonymous Coward

            >nullを足したり

            つまり「2^nプラスちょっと」になっていたため、
            jemallocで2^(n+1)確保されたということですか?

    • by Anonymous Coward

      2nより細かい単位、たとえば20.5nとかで区切ればいいのに。

      それはあまりよくありません。メモリ割り当ての処理で、欲しい大きさのブロックがなくて、その一つ上の大きさのブロックに解放済みのものがあったときは、一つ上のブロックを分割して使います。このとき、欲しい大きさのブロックを切り出した残りが中途半端な大きさだと、残りのブロックを登録するところがありません。20.5nだと、(20.5(n+1) - 20.5n) の大きさのブロックが残って、これを登録するところがなく、細切れにして登録するのは無駄ということです。2n

  • Javaアプリもメモリ指定があるくらいなので、いかにOS側のメモリ
    取得が当時怪しかったかのゾンビのようなものでしょうか?
    複数のウインドウやタブを表示するのにメモリ取得もグルーピングしたり
    スイッチしたり、色々と大変なのでしょう。開放メモリが連続領域で
    邪魔されたりしないで再取得できるのかとか(当然某ブラウザが優先して
    とりやすい状況は、想像できるわけだが...)

    # いずれにしても、8までまてねぇよ。7でやれ。
    • by Anonymous Coward

      んなことOS任せでいいような気もしないでもない。
      最近のモダンOSならそれくらいアプリ側が気にしないようにしてくれて当たり前でしょー? みたいな。

    • > # いずれにしても、8までまてねぇよ。7でやれ。

        「ったく、マダー?」

  • by Anonymous Coward on 2011年08月11日 18時03分 (#2001479)
    8GB,16GB当たり前になってメモリ使用量が半分を超えるのもめったになくなったから、
    いくら減っても減らなくてもいいや。

    組み込みとかで使われているのか?firefox
    • by Anonymous Coward
      ワーキングセットの大きさが変わらなきゃ、見栄えだけの問題だよね。
    • by Anonymous Coward

      Androidなどモバイル用のFirefoxにとっては大きな改善になると思います。まさに目に見えてパフォーマンスが良くなるかもしれない。
      せっかくSyncという優れた機能があるのに、モバイル用ではそのメモリ消費の多さから敬遠されがちなのがFirefoxですから。
      今回のメモリ浪費の原因解明によってモバイル用Firefoxが軽くなるのなら、是非使いたいという人も結構いるのではないでしょうか。

  • by Anonymous Coward on 2011年08月11日 20時40分 (#2001553)

    Webブラウザみたいな恐竜アプリを手動メモリ管理で作るのは凄いけど、
    もうあんまりメリットなくなってるような。

    Mozillaは初期からフットプリント削減運動を繰り返してますね。
    機能拡張して汚くなってくると放棄されるソフトも多いけど、モジラの根気は凄い。

  • by Anonymous Coward on 2011年08月11日 23時10分 (#2001605)

    >メモリ使用量が大幅に減る可能性があるとのこと
    そうやって次期バージョンに期待を持たせるのがmozillaの手口です。

    私は毎回新バージョンへの期待に裏切られながらも使い続けています。
    今回は信じていいのでしょうか?

  • この件を改善して消費メモリがある程度抑えられたとしても、マルチプロセス化で消費メモリが増大して結局減らない、むしろ増えている。という結末が待ってる気してならないんだけどなあ。

    • by Anonymous Coward
      タブ閉じる→プロセス終了→メモリ解法でめでたしめでたし、という発想ですか。 めでたいですねぇ。
      今回のは、プロセスそのもののメモリ使用量が小さくなる、って話なんですけど。
      • by Anonymous Coward
        根本的な解決はメモリ使用量を下げることじゃなく
        使ってないメモリをさっさと開放することだよ。
        タブ開きまくり->タブ全部閉じてもメモリ使用量1GBとかあまりにも馬鹿げた挙動。

        >タブ閉じる→プロセス終了→メモリ解法でめでたしめでたし、という発想ですか。めでたいですねぇ。

        めでたいの意味がよくわからないんだけど
        これじゃ解決しないと言いたいの?

        オフトピならオフトピと言ってくれればいいけどめでたい理由にはならないし。
        • プロセス化したところでメモリ解放、即、別プロセスで使用可にはならないですよ。
          モダンOSの仕組みを勉強した方がいいです。

          一定期間はキャッシュとして残されます。
          # 再度使われる可能性があるから。
          # 領域再割り当て&ディスクから読込のコストは意外とでかい。

          一定期間経過後、ガベージコレクタにより、領域使用可としてOSに回収されるわけです。

          GCに回収される前であれば、2度目以降の起動が速いのは、OSがよきにはからってくれるからなのです。

          親コメント
        • by Anonymous Coward

          タブ開きまくり->タブ全部閉じてもメモリ使用量1GBとかあまりにも馬鹿げた挙動。

          それは、プロセス化しようがしまいが、ある時点でのメモリ使用量の総量が 1GB を越えるってこと。プロセス化すれば何でも解決しますって考えるのが、 めでたいと言ったまで。

          • by Anonymous Coward
            ある時点で超えるから、何? どんなまともなブラウザだって1GB超えることはあるでしょうよ。
            プロセス化してれば、タブに関連するメモリについてはタブを閉じるだけで開放できるでしょ? でもFirefoxではできないでしょ?
            ウィンドウを全く開いてないのにメモリを1GB以上食ってたり、メモリ開放するためにブラウザを全終了させる必要があったりとか、ありえない挙動です。そのありえないことが現実に起きてるのがクソアプリ、Firefoxなんですよ。
            • by Anonymous Coward

              >ある時点で超えるから、何? どんなまともなブラウザだって1GB超えることはあるでしょうよ。

              ねえよ。

            • by Anonymous Coward

              ある時点で超えるから、何? どんなまともなブラウザだって1GB超えることはあるでしょうよ。

              そうですよ。
              今回の話は、ピークを最大半分にできる、って話であって、 プロセス化した場合にもその恩恵を受けられる、ってこと。
              今回のような努力もせずに、単純にプロセス化すると勝手に解決できるような問題ではない。

    • by Anonymous Coward
      そんなにプロセス分離化がメデタイことなら、プロセス分離化されているGoogleChrome使えば。
      GoogleChromeの方が、長時間起動していた時のメモリー占有量が半端ないから。
    • by Anonymous Coward
      Chromeとの比較でタブ数100いくつとか書かれると、もっと別のとこに労力裂けよ…
      とは思う
      ChromeはDL毎に連番振っててブラウジングをトレースできるって都市伝説を聞いたから
      再インストールしてから使ってないw
typodupeerror

日本発のオープンソースソフトウェアは42件 -- ある官僚

読み込み中...