Firefox 3.1 Beta 3 でのメモリ使用量

数日前、私は Firefox 3.1 Beta 3 をレビューしました。とても素敵です。 Javascript のパフォーマンスが向上し、新しい使いやすさとプライバシー機能が追加され、将来の HTML マルチメディア要素がサポートされます。

正当な理由があります。

アプリケーションのメモリ使用量を正確に測定することは、非常に難しい作業です。せいぜい、推測、見積もり、兆候を持つことができますが、通常、それらは主観的であり、非常に限られた範囲の要因に基づいているため、ほとんど役に立ちません.ほとんどの人は、さまざまなシステム ユーティリティ (タスク マネージャー、プロセス エクスプローラー、ps など) によって報告される未加工の数値を、メモリ使用量の要求に対する唯一の調停者と考えています。

この記事では、次の 2 つのことを行います。まず、Firefox 3.1 Beta が現在の Firefox リリースよりも多くのメモリを使用するか、または少ないメモリを使用するかについて、率直でシンプルな回答を提供してみてください。 2 つ目は、メモリ管理に関する非常にこっけいなことをいくつか教えることです。

この記事では、主に Linux でのメモリ使用について説明します。このオペレーティング システムでは、物事の核心を深く掘り下げる方がはるかに簡単だからです。 Windows Firefox のメモリ使用量についても説明します。

始めましょう。

単純な答えを得ることが難しい理由

これは、オペレーティング システムが、刻々と変化する何千ものパラメータを持つ生き物であるためです。それは、人間が呼吸する空気の量を尋ねるようなものですか?プロセッサの種類、クロックとアーキテクチャ、オペレーティング システム、現在実行中のプロセスの数、プロセスの優先度、整合性モニター、ファイル チェッカー、アンチウイルスプログラム、その他、その他多くのもの。すべてのコンピューター ユーザーは、異なる結果を報告します。

これは、ここでの私のテストは、塩の大きなピンチで受けなければならないことを意味します.最も重要なことは、絶対的な数値は何の意味も持たないということです。第二に、私がここで報告したこととは正反対のことを経験するかもしれません.せいぜい、このレビュー/チュートリアルは、かなりハンサムなエラーで、何が起こるかを示す良い指標です.

実際の例

以前の職場の 1 つで、自分のマシンでマカフィー アンチウイルスを実行することを余儀なくされました。これにより、起動時とすべてのタブを開くときの両方で、Firefoxの応答性を含め、物事がかなり遅くなるように見えました.迷惑なウイルス対策をオフにすると、応答時間が少なくとも 3 分の 2 短縮され、メモリ使用量が半分になりました。アンチウイルスは一種の Web コンテンツ フィルターにもなろうとしていることが判明したため、表示しようとしているすべてのページをチェックしていました。ウイルス対策プログラム、ファイアウォール、コンテンツ チェッカー、Web フィルター、ツールバー、プラグインなど、これらすべてがブラウザーの動作を変化させます。

したがって、あなたのテスト (および私のもの) は厳密に管理する必要があります。アプリケーションの動作を調べたい場合は、1 つまたは複数のタブを開いた状態で、画像をレンダリングしてスクリプトを実行する場合と静的な HTML テキストを実行する場合との比較、12 時間アイドル状態にある場合と低温の場合を比較して、短期的および長期的な使用法をテストする必要があります。ダウンロード時などに開始します。これをバージョンごとに少なくとも 2 回行い、報告された結果が正しいことを確認し、変動を測定します。

目の前の仕事の重大さを理解していただければ幸いです。さて、ナンセンスは十分です。ビジネスに取り掛かりましょう。

Linux でのメモリ使用量

テスト ケース:ゲスト オペレーティング システムに 512MB の RAM が割り当てられた Intel Core Duo マシンで仮想化された Linux Mint 6 Felicia、アドオンなしの Firefox はデフォルトのテーマを保存します。まず、システム モニター ユーティリティを開いて、システムが何を示しているかを調べることから始めましょう。

Firefox 3.0.3:

Firefox 3.1 ベータ 3:

ベータ版は、既存の製品版が使用する 24.4MB よりも 29MB 必要であることがわかります。これはコールド スタートで、1 つのタブが開いています。全体として、19% の増加のようです。

これらの数字は何を教えてくれますか?

答えは、何もありません。 Linux では、一般に、アプリケーションはメモリを使用するつもりがなくてもメモリを取得する傾向があります。これは特に Java ベースのプログラムに当てはまります。Java ベースのプログラムは、将来の使用のためにメモリを事前に割り当て、他のプロセスから要求された場合に時間の経過とともに解放する傾向があります。したがって、静的な数値はほとんど意味がありません。自分が使える以上のものを取り、他の誰かがそれを求めたときに手放すことは、貪欲とは言えません。

プログラムが実際にどれくらいかかるかを確認するには、余分なものをすべて取り除く必要があります。これは、私たちが持っているメモリ プール全体 (私たちの場合は 512MB) を占有することを意味します。しかし、大量のプログラムを実行するだけでは、これを達成するのは困難です。最悪の場合、システムが不足していると感じた場合、メモリ不足 (OOM) の強制終了ルーチンが開始され、最も問題のあるプロセスが強制終了されます。したがって、すべてを取得してから返す短期メモリ豚が必要です。

ご想像のとおり、メモリホッグが必要です。

メモグ

これは、今説明したことを実行する非常に単純なユーティリティです。メモリを受け取り、それを返します。その過程で、実行中のすべてのプロセスが未使用の予約を強制的に解放し、それらを必要最低限​​まで削減します。

Linux Mint のリポジトリにはそのようなユーティリティはありませんが、独自のユーティリティを作成できます。 C コードをダウンロードしてコンパイルします。方法は次のとおりです:

gcc -Wall memhog.c -o memhog

小さなユーティリティがコンパイルされたら、次のように実行します:

./memhog <メモリ>

例:

走らせてください。数秒、場合によっては 1 分かかります。その間、システムはあまり反応しません。終了したら、テスト アプリケーションのメモリ使用量の測定を開始できます。

これは、テスト プログラムを memhog の前と後に 2 回実行することを意味します。また、システムの使用状況を確認するより正確な方法であるコマンドライン ps ユーティリティも使用します。

ps によって報告されたメモリ使用量 (memhog を使用)

ps ユーティリティには多くのオプションとフラグがあり、使用されているシステム リソースを徹底的に調べることができます。 aux フラグを付けて実行し、VSZ と RSS の値を確認します。以下のスクリーンショットでは、これらはそれぞれ出力の 5 番目と 6 番目の列になります。

VSZ (Virtual Size) と RSS (Real Set Size) の値が何を意味するかを詳しく説明することは、この記事の範囲を超えていますが、簡単に説明しようと思います:RSS は物理メモリの実際のフットプリントであり、VSZ に含まれています。 . VSZ は、プロセス、つまりコード、データ、およびスタックの仮想サイズです。それでも、これら 2 つの値は、カーネル スタックを含むプロセス使用の一部をカウントしませんが、Firefox はユーザー ランドのプログラムのみであるため、それらについてはあまり気にする必要はありません。

メモリ マップに触れるときに、VSZ と RSS についてもう少し説明します。 ps の詳細については、man ページを確認してください。それでは、Firefox を実行してその使用法を調べ、memhog を実行してからもう一度使用法を調べるとどうなるか見てみましょう。

Firefox 3.0.3:

2 つの出力は、memhog の実行前と実行後のものです。全体のフットプリントは 165MB で、コールド スタート時の実メモリは 65MB です。 memhog の実行後、全体的なフットプリントはほぼ同じままですが、実際のメモリは 16.5MB に減少します。

Firefox 3.1 ベータ 3:

VSZ 値は 189MB で、memhog の実行前は 53MB、実行後は 39MB です。 Firefox 3.1 Beta 3 は、起動時に事前に割り当てるメモリが少ないようです。つまり、メモリを大量に消費することは少ないはずですが [原文のまま]、実行するにはより高いベースラインが必要です。

Firefox 3.1 には Firefox 3 よりも多くの機能があるため、これは当然のことです。より多くの機能、より多くのメモリ、しかしより少ない貪欲。

CPU 使用率を見ると、Firefox 3.1 は Firefox 3 よりも少なくなります。前の 7.7% に対して 4.7%、4.2% に対して 3.3% と、27-64% の改善。これも重要です。つまり、Firefox 3.1 はシステム上で軽量であるため、実際のメモリをより把握する必要がありますが、より高速に応答するはずです。それでは、メモリ マップを見て、なぜ Firefox 3.1 の方が多くかかるのかを考えてみましょう。

メモリ マップ

メモリ マップは、プロセスごとに個別に /proc 疑似ファイル システムの下に表示されます。まず、プロセス ID を確認する必要があります (これは ps で行いました)。次に、/proc//maps に移動します。

Firefox 3.0.3:

どのマップがレポートするかについて詳細を説明することはできませんが、ごく簡単に言えば、得られるものは次のとおりです。この出力の最初の数行は、バイナリ コード（テキスト）、データ、およびヒープ セグメントです。次に、プロセスが使用する共有ライブラリがあります。出力を確認しながら、アプリケーションのメモリ使用量を詳細に調査し、その動作を理解しようとすることができます。

ここでは、もっと単純なことを行います。プロセスに必要なマップの総数を見ていきます。総数 455 を見てください。

Firefox 3.1 ベータ 3:

ここでは 472 です。これは、Firefox 3.1 がもっと必要であることを示しています。

ストレス下でのメモリ使用量

しかし、何もせずに単一のタブを開いてプログラムをテストすることは、ほとんどテストではありません。そこで、Youtube を動かして、アプリケーションが Flash をどれだけうまく処理できるかを調べました。 Flash Player は Firefox 用のサードパーティ製プラグインであり、Linux Mint にバンドルされていることに注意してください。したがって、私の「ストレス」テストが何を意味するのかを 100% 確信することはできませんが、それでも、知りたいと思うかもしれません。前回の記事で見たように、Firefox 3.1 では Javascript のパフォーマンスが大幅に向上していることに注意してください。

YouTube が Jan Hammer を再生しているときの結果を次に示します。テストの直前に memhog を実行して、コールド スタート時に両方のブラウザで 5 秒ごとに実行します。

Firefox 3.0.3:

メモリは 163MB (実質 40MB) で安定しており、CPU は 5.5% です。

Firefox 3.1:

メモリは 194MB (実際には 57MB) で、約11% の CPU。これは、メモリに関しては、以前とほとんど同じであることを意味します。 Youtube を実行しているときに CPU 使用率が高いということは、ベータ版がまだ Flash ライブラリを最大限に活用するように最適化されていないことを示している可能性があります。大幅に改良されたエンジンを考えると、これは当然のことです。

注目に値するもう 1 つのことは、メモリと CPU の使用量の両方がシステムで行われる内容に応じて変化することです。正確な判断は困難ですが、私はこのすべての超マニアックなことを合理化しようとします.最後に、メモリ不足 (OOM) スコアを見てみましょう。

OOM スコア

OOM スコアは、/proc ファイルシステムを介してカーネルによって報告される別の数値です。それはシステムに各プロセスのスコアを伝えます。また、プッシュが押し寄せてシステムがメモリ不足になった場合、どのプロセスを強制終了するかを伝えます。スコアが低いほど良い。

OOM スコア/キルがどのように機能するかという正確なメカニズムは重要ではありません。私たちが探しているのは、古い Firefox と新しい Firefox のスコア比較です。数値は /proc//oom_score から抽出できます。 memhog前後の数値を確認しました。

Firefox 3.0.3:

memhog の実行前と実行後の違いはごくわずかです。つまり、Firefox はかなりスマートにメモリを使用します。

Firefox 3.1 ベータ 3:

ここでは、memhog を実行した後の結果を確認できます (最初の結果は似ています)。

2 つのバージョンの違いは最小限です。 OOM スコアは、正確な数値ではなく、桁数によってのみ意味があることに注意してください。したがって、システムは両方のバージョンをほとんど同じように扱います。

これまでの簡単な結論:Firefox 3.1 はより大きなアプリケーションであり、より多くの機能を備えているため、より多くのメモリが必要です。一方、HTML や Javascript を表示するときは CPU の使用量が少ないため、高速に感じる可能性が高くなります。 Flash のパフォーマンスには改善が必要ですが、これは Adob​​e と Mozilla チームの両方が協力して取り組む必要があるものです。 Flash Player はこのベータ版を意図したものではなく、ディストリビューション (およびブラウザー) に含まれていたため、私がこれらの結果を得たのは当然のことのように思えます。

これで Linux の部分はほとんど終わりです。ここで、Windows 部分を確認します。

Windows でのメモリ使用量

テスト ケース:Windows XP SP3、AMD Athlon 3700+ で仮想化、仮想マシン専用の 768MB RAM、組み込みテーマおよび拡張機能なしの Firefox 3.0.7 を実行。

このセクションは、私の Windows のハッキング スキルが Linux よりもやや劣っているため、少し短くなります。それに、Windows の人はあまりコマンドラインのハッキングを見たくないので、私はそれらを控えます。

メモリ使用量をチェックするために、標準のタスク マネージャーと、Sysinternals によって作成された強力なツールである Process Explorer ユーティリティの 2 つのユーティリティを使用します。

タスク マネージャー

Firefox 3.0.7:

Firefox 3.1 ベータ 3:

メモリ使用量はほぼ同じで、現在のバージョンより 3MB わずかにリードしています。全体として、Firefox は 1 つのタブを開いた状態で 31 ～ 34 MB を使用しているようです。しかし、これがすべてではないことはわかっています。

プロセス エクスプローラー

また、以前に Linux で見た VSZ や RSS と同様の値を確認することもできます。 Process Explorer は喜んでこれらを報告します。

Firefox 3.0.7:

重要な数値は、ワーキング セット (54MB)、仮想サイズ (114MB)、およびプライベート バイト (43MB) です。 Private Bytes は、ほとんどのユーザーが参照したいものであり、アプリケーションが適切に機能するために必要なベースラインです。ワーキング セットには、プロセスがマップする仮想ページが含まれます。仮想サイズは、特定の瞬間にアプリケーションが持つ全体的なフットプリントです。

Firefox ベータ版のレポートを見てみましょう。

Firefox 3.1 ベータ 3:

Windows 上の Firefox 3.1 Beta 3 は、より少ないメモリを使用します。ベースラインは 25MB と低く、ワーキング セットは 34MB で、仮想サイズは 95MB です。およそ、これは全体で 20MB 少なくなっています。これらの結果は、Linux で得られる結果とは異なり、さらに興味深いものになっています。

結論

Linux では、Firefox 3.1 Beta は現在のバージョンよりもメモリを少し多く消費しますが、CPU は少なくて済みます。つまり、応答がより速くなるはずです。 Windows では、Firefox 3.1 Beta に約 10 分かかります。現在のバージョンより 20MB 少ない - 繰り返しになりますが、より高速になるはずです。

しかし、これらの数字は、繰り返しになりますが、何の意味もありません!

Windows と Linux ではメモリの処理方法が異なります。通常、Linux は必要以上に事前に割り当ててから解放し、Windows は必要に応じてメモリを追加します。これは、2 つのオペレーティング システムの全体的な動作とよく一致しており、通常、メモリを集中的に使用するタスクに関しては Linux が優先されます。

さらに、基本的には 2 つの異なるオペレーティング システム、2 つの異なるアプリケーションについて話しているため、直接比較してもほとんど意味がありません。どちらの場合も、2 つのオペレーティング システムの動作モデルを考えると、Firefox 3.1 Beta は既存の Firefox 3 よりも高速に動作すると予想されます。全体として、フットプリントは数十 MB のわずかな違いだけであり、おそらく日常の使用ではあまり変わらないでしょう.ただし、Javascript のパフォーマンスが 30% 向上したと感じるでしょう。少ない CPU 使用率と組み合わせることで、より高速なブラウザーを楽しむことができます。

ただし、Linux では現在、Flash の使用は最適化されていません。

これらの結果を、大まかな推定以上のものと見なさないでください。私は可能な限り徹底的にしようとしましたが、テストには欠陥があり、設計上制限されています.しかし、テスト全体のバックグラウンド ノイズと繊細さにより、結果は楽しい推測にすぎません。

ただし、me​​mhog、ps ユーティリティ、マップなどのマニアックなもので遊ぶ方法を学習したので、チュートリアルに付加価値がないわけではありません。とりあえず以上です、楽しんでください！

乾杯。