Firefoxが無駄に消費しているメモリの正体が突き止められる 52
ストーリー by hylom
ダークマターとは大仰な 部門より
ダークマターとは大仰な 部門より
Firefoxに長らく存在していた用途不明なヒープメモリ、通称「ダークマター」の発生原因のひとつが突き止められたらしい(マイコミジャーナルの記事)。このダークマターはFirefoxが使うメモリのうち結構な比率を占めているそうで、この問題が解消されるとメモリ使用量の大幅な減少が期待できるとのこと。
Nicholas Nethercote氏によってなされた報告によると、jemallocのメモリアロケート時に発生する未使用領域がダークマターの原因のひとつとなっているそうだ。jemallocでは確保したメモリを開放するときにフラグメンテーションが発生しにくくなるように、特定のサイズに区切ってメモリの確保を実施している。Nicholas Nethercote氏はこの領域を「スロップ」と呼んでおり、このスロップがメモリ食いの原因とのこと。スロップを完全に排除するには、jemallocの確保するメモリサイズである2のべき乗で容量を確保すればよい。
すでにどの部分でスロップが発生しているのか大枠で特定されており、Firefox 8やFirefox 9以降のFirefoxは、メモリ使用量が大幅に減る可能性があるとのこと。
ダークマターなどと (スコア:3, おもしろおかしい)
格好いい表現を使ってるから、事の本質や重大さや深刻さが誤魔化されてしまうんですよ。
Re: (スコア:0)
こんなに笑ったのは久しぶり
Re: (スコア:0)
Re: (スコア:0)
メモリ食い過ぎバグにはよく悩まされるが、この発想はなかった。
8とか9とか結構先のように見えても (スコア:2)
まあ、1つで6週間ですからね。
18週間か24週間。
うん、結構先だ。
Re: (スコア:0)
一気に13まで上げちゃっていいよもう
とか思っちゃう
# 開発側のバージョンコンプレックに付き合わされるアドオン開発者がかわいそう
Re:8とか9とか結構先のように見えても (スコア:1)
13とか14は縁起が悪いので15にしましょう。
# それなんてCisco IOS?
Re: (スコア:0)
既存バージョンで置換えが出来ればいいのにと思ってしまう。
爆速のわけは劇重 (スコア:2, 興味深い)
jemalloc()~Firefox 3.爆速の理由~ [mew.org](PDF)
どっちにすればいいのとは思うけど、バランスをかんがえないのか?
そもそもjemallocを改良するとかそっちで貢献しようとか
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:爆速のわけは劇重 (スコア:3, 参考になる)
記憶によれば、jemalloc()が有名になったのはFreeBSDのSMPng終了アナウンス時のパフォーマンステストでLinuxを抑えたとき。
そして、その時「Linuxはglibcのmalloc()に問題あるんじゃね?」と言い出した人はLD_PRELOADか何かでgoogle malloc()と差し替えて評価してたはず。
なのでまずは現行バージョンのgoogle malloc()版を出してみて欲しい。
何の速度が重要か (スコア:0)
コールドスタートのクソ重さは全く改善されないのがfirefox。
今のところのFxチームの対応策は
コールドスタートの件には沈黙して
レンダリングが「早くなった!」と騒ぐだけ。
信者もしっかりと、
「(レンダリングが前のバージョンと比較して)爆速!」
としか言わない。
chromeに負けるのは必然。
バージョンナンバーとか小手先の問題で回避できる問題じゃない。
Re:何の速度が重要か (スコア:1, 参考になる)
単に君のアンテナが低いだけだろう。つい最近の大幅な高速化話は日本語の記事も出てたよ。
Firefox Planet [firefox.com]あたりをチェックしていれば大抵のネタは手に入るので、フィードリーダーにでもブチ込んでおいたら?
Re: (スコア:0)
ブラウザにおけるコールドスタートって何だ?スタートアップかなにかに登録しておいて、電源を投入してから最初にブラウザ画面が表示されるまでの時間、みたいなのを問題にしてる?
Re:何の速度が重要か (スコア:1)
PC起動して、ユーザーの入力受け付ける状態になってから初めてブラウザを
起動してからの時間ってことじゃないかなぁ。
起動がクソ重いなんて思ったこともなかったから想像だけどね。
Re: (スコア:0)
コールドスタート()が早いのは必然だわなw
Re: (スコア:0)
あれ、記憶しておいたページポインタを表示するのって普通の機能じゃなかったんだっけ?
Re: (スコア:0)
ページポインタって初めて聞いたけど、一体なんですかそりゃ。
考えてもさっぱりわからん。
2^nで確保するとか本末転倒もいいとこだなw (スコア:1)
2nより細かい単位、たとえば20.5nとかで区切ればいいのに。サイズとの対応が簡単に計算できればよくて、20.5nでもたかだか128エントリなんだから表にしちゃったっていいし、log2n求めてから選んでもいい。アロケータ内部の結構簡単な修正で他には修正いらないから局所性も高い。
...なのに...何考えてんだろ。
Re:2^nで確保するとか本末転倒もいいとこだなw (スコア:1)
マイコミジャーナルの方にはちゃんと「基本的には2のべき乗」と書いてあるのを、私が「基本的には」をはしょったのですが、
http://blog.mozilla.com/nnethercote/2011/08/05/clownshoes-available-in... [mozilla.com]
を見ると、完全な2のべき乗ではないようです。(貼り付けようと思ったら、空白が多すぎるとかで投稿フィルタにひっかかる...)
どっちにせよ、もっと細かい単位でとるようにすればいい話なのですが。
はしょった部分については、紛らわしいので、修正しておきます。
1を聞いて0を知れ!
Re:2^nで確保するとか本末転倒もいいとこだなw (スコア:1)
いやー、どっちにしても根本的な問題と解決法は同じで、ユーザ側でサイズを変えても統計に出ないだけで無駄なままだし、もっと細かくする以外の解はないし。ほぼO(1)で速くてフラグメント起きにくくてと、いいアルゴリズムなんだけどねー。
あと、ユーザプロセスであることを考えると実メモリの無駄はあんまり多くないはず。
実メモリの無駄も多いんなら領域返却時に返せるページを返してない手抜きコードだわな。
# これもアロケータの修正だけで直るけどな。
Re:2^nで確保するとか本末転倒もいいとこだなw (スコア:4, 参考になる)
2のべき乗で確保するのはすでに行っていたけど、サイズを計算した後で文字列末尾のnullバイトの分を足したりヘッダサイズを足したりしてからjemallocに渡していたので、意図した割り当て量の2倍近く割り当てられてしまった上に半分近くはまったく何にも使えず完全な無駄になっていたという話。バグ以外の何者でもない。ご高説のとおりに2のべき乗で割り当てるのがそもそも妥当でないとしてもそれはまったくの別問題。
> ユーザ側でサイズを変えても統計に出ないだけで無駄なままだし、
アロケータの割り当て量そのものが半分になる。
> 領域返却時に返せるページを返してない
返却されないで無駄になってる。そもそもユーザ側は無駄な領域が存在することさえ認識していない。
Re:2^nで確保するとか本末転倒もいいとこだなw (スコア:1)
ん?それって、確保サイズの半分扱いで返却する事があるって事か?
Re:2^nで確保するとか本末転倒もいいとこだなw (スコア:2, 参考になる)
Re: (スコア:0)
#2001451 [srad.jp]には、
> > 領域返却時に返せるページを返してない
> 返却されないで無駄になってる。
と書いてあるけど、2^(n+1)で確保されてしまったメモリを返却しようとしたら
2^n+チョットしか開放できないなんておかしくないか?という指摘だよ。
malloc側では2^(n+1)で割り当てたのだから開放も2^(n+1)なんじゃないの?ということ。
Re: (スコア:0)
> 2^n+チョットしか開放できないなんておかしくないか?という指摘だよ。
jemallocでも2^(n+1)でmallocしたメモリをfreeしたら2^(n+1)返却されます。それはさすがに。
今回の問題は
・jemallocは内部でメモリ量をランドアップして確保している
・jemallocを使う側の中に、メモリ量をランドアップしてから+チョットしてjemaloocにメモリ要求していたものがあった
というののあわせ技ということで。
ちなみにみんな2倍、2倍といってるけど、そういうわけで必要量の4倍近くとってたケースもあると思われ。
Angel's share (スコア:0)
問題解決するように読めますよね。
Re: (スコア:0)
>nullを足したり
つまり「2^nプラスちょっと」になっていたため、
jemallocで2^(n+1)確保されたということですか?
Re: (スコア:0)
それはあまりよくありません。メモリ割り当ての処理で、欲しい大きさのブロックがなくて、その一つ上の大きさのブロックに解放済みのものがあったときは、一つ上のブロックを分割して使います。このとき、欲しい大きさのブロックを切り出した残りが中途半端な大きさだと、残りのブロックを登録するところがありません。20.5nだと、(20.5(n+1) - 20.5n) の大きさのブロックが残って、これを登録するところがなく、細切れにして登録するのは無駄ということです。2n
某OSが、メモリのI/Fを公開しないとか?そんなとこ? (スコア:1)
取得が当時怪しかったかのゾンビのようなものでしょうか?
複数のウインドウやタブを表示するのにメモリ取得もグルーピングしたり
スイッチしたり、色々と大変なのでしょう。開放メモリが連続領域で
邪魔されたりしないで再取得できるのかとか(当然某ブラウザが優先して
とりやすい状況は、想像できるわけだが...)
# いずれにしても、8までまてねぇよ。7でやれ。
Re: (スコア:0)
んなことOS任せでいいような気もしないでもない。
最近のモダンOSならそれくらいアプリ側が気にしないようにしてくれて当たり前でしょー? みたいな。
これでエアコンの設定温度を1度上げてください (スコア:0)
> # いずれにしても、8までまてねぇよ。7でやれ。
「ったく、マダー?」
最近メモリ埋まらないから (スコア:0)
いくら減っても減らなくてもいいや。
組み込みとかで使われているのか?firefox
Re: (スコア:0)
Re: (スコア:0)
Androidなどモバイル用のFirefoxにとっては大きな改善になると思います。まさに目に見えてパフォーマンスが良くなるかもしれない。
せっかくSyncという優れた機能があるのに、モバイル用ではそのメモリ消費の多さから敬遠されがちなのがFirefoxですから。
今回のメモリ浪費の原因解明によってモバイル用Firefoxが軽くなるのなら、是非使いたいという人も結構いるのではないでしょうか。
そろそろVMベースのほうが (スコア:0)
Webブラウザみたいな恐竜アプリを手動メモリ管理で作るのは凄いけど、
もうあんまりメリットなくなってるような。
Mozillaは初期からフットプリント削減運動を繰り返してますね。
機能拡張して汚くなってくると放棄されるソフトも多いけど、モジラの根気は凄い。
Re:そろそろVMベースのほうが (スコア:1)
フットプリント削減すると、どーしても速度が犠牲に…
速度を上げようとするとフットプリントが増加
なんかMozilaはずっと繰り返してる気がするw
# Mozilla Suiteに比べると遥かに軽くなったよなぁ。
思わせぶり (スコア:0)
>メモリ使用量が大幅に減る可能性があるとのこと
そうやって次期バージョンに期待を持たせるのがmozillaの手口です。
私は毎回新バージョンへの期待に裏切られながらも使い続けています。
今回は信じていいのでしょうか?
Firefox 8やFirefox 9以降のFirefoxは、メモリ使用量が大幅に減る可能性 (スコア:0)
この件を改善して消費メモリがある程度抑えられたとしても、マルチプロセス化で消費メモリが増大して結局減らない、むしろ増えている。という結末が待ってる気してならないんだけどなあ。
こんなのってタブのプロセス分離化すれば勝手に解決されるんじゃないの (スコア:0)
Re: (スコア:0)
今回のは、プロセスそのもののメモリ使用量が小さくなる、って話なんですけど。
Re: (スコア:0)
使ってないメモリをさっさと開放することだよ。
タブ開きまくり->タブ全部閉じてもメモリ使用量1GBとかあまりにも馬鹿げた挙動。
>タブ閉じる→プロセス終了→メモリ解法でめでたしめでたし、という発想ですか。めでたいですねぇ。
めでたいの意味がよくわからないんだけど
これじゃ解決しないと言いたいの?
オフトピならオフトピと言ってくれればいいけどめでたい理由にはならないし。
Re:こんなのってタブのプロセス分離化すれば勝手に解決されるんじゃないの (スコア:1)
プロセス化したところでメモリ解放、即、別プロセスで使用可にはならないですよ。
モダンOSの仕組みを勉強した方がいいです。
一定期間はキャッシュとして残されます。
# 再度使われる可能性があるから。
# 領域再割り当て&ディスクから読込のコストは意外とでかい。
一定期間経過後、ガベージコレクタにより、領域使用可としてOSに回収されるわけです。
GCに回収される前であれば、2度目以降の起動が速いのは、OSがよきにはからってくれるからなのです。
Re: (スコア:0)
それは、プロセス化しようがしまいが、ある時点でのメモリ使用量の総量が 1GB を越えるってこと。プロセス化すれば何でも解決しますって考えるのが、 めでたいと言ったまで。
Re: (スコア:0)
プロセス化してれば、タブに関連するメモリについてはタブを閉じるだけで開放できるでしょ? でもFirefoxではできないでしょ?
ウィンドウを全く開いてないのにメモリを1GB以上食ってたり、メモリ開放するためにブラウザを全終了させる必要があったりとか、ありえない挙動です。そのありえないことが現実に起きてるのがクソアプリ、Firefoxなんですよ。
Re: (スコア:0)
>ある時点で超えるから、何? どんなまともなブラウザだって1GB超えることはあるでしょうよ。
ねえよ。
Re:こんなのってタブのプロセス分離化すれば勝手に解決されるんじゃないの (スコア:1)
それ実装メモリ不足で、プロセス合計で 1GB 割り当てられないだけじゃないですか?
ビューポートのレンダリングのためにかかる量を考えても、どんなまともなブラウザでもタブひらきまくりとかしたら、割り当て可能メモリーに余裕があるなら 1GB 超に達することはありうるはずですが。たとえ w3m でも。
Re: (スコア:0)
そうですよ。
今回の話は、ピークを最大半分にできる、って話であって、 プロセス化した場合にもその恩恵を受けられる、ってこと。
今回のような努力もせずに、単純にプロセス化すると勝手に解決できるような問題ではない。
Re: (スコア:0)
GoogleChromeの方が、長時間起動していた時のメモリー占有量が半端ないから。
Re:こんなのってタブのプロセス分離化すれば勝手に解決されるんじゃないの (スコア:1)
デスヨネ~
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re: (スコア:0)
とは思う
ChromeはDL毎に連番振っててブラウジングをトレースできるって都市伝説を聞いたから
再インストールしてから使ってないw