Firefox 3.1 Beta 3のメモリ使用量を徹底検証 ― LinuxとWindowsでの実測レポート

先日、Firefox 3.1 Beta 3をレビューしました。JavaScriptパフォーマンスの大幅な向上、使い勝手とプライバシーに関する新機能、将来のHTMLマルチメディア要素への対応など、非常に魅力的なリリースです。ところが、あの記事ではメモリ使用量については一切触れていませんでした。

それには、ちゃんとした理由があります。

アプリケーションのメモリ使用量を正確に測定するのは、実は非常に難しい作業です。せいぜい得られるのは「推測」や「目安」程度で、しかも主観的かつ限られた要因に基づくもので、ほとんど役に立たないことも珍しくありません。多くの人は、タスクマネージャー、Process Explorer、psといったシステムユーティリティが表示する生の数値だけを、メモリ使用量の唯一の判断材料にしています。

本記事では2つのことをお伝えします。第一に、Firefox 3.1 Betaは現行版よりもメモリを多く使うのか、それとも少なくするのかというシンプルな答えを提示すること。第二に、メモリ管理に関する少しマニアックですが役立つ知識をいくつか紹介することです。

内容は主にLinux環境を中心に据えています。このOSの方がシステムの深部まで掘り下げやすいからです。とはいえ、Windowsユーザーを置き去りにはしません。Windows版Firefoxのメモリ使用量についてもしっかり取り上げます。

それでは始めましょう。

シンプルな答えが出しにくい理由

その理由は、OSが常に変化し続ける「生き物」だからです。これは「人間はどれくらいの空気を吸うのか?」という質問に似ています。答えは、プロセッサの種類・クロック・アーキテクチャ、OSの種類、現在稼働中のプロセス数、プロセスの優先度、整合性監視ツールやファイルチェッカー、アンチウイルスソフトなどポーリング型ソフトウェアの有無など、膨大な要因に左右されます。ユーザーごとに結果は異なるのです。

つまり、ここで示すテスト結果も大きめの塩ひとつまみをもって受け止めてください。最重要なのは、絶対値にはほとんど意味がないという点です。また、私の報告とは正反対の結果になる可能性もあります。あくまで「こういうこともありうる」という目安であり、それなりに大きな誤差を含むものだとご理解ください。

実際にあった例

以前勤めていた職場では、PCにMcAfeeのアンチウイルスを導入することを強制されていました。これが原因で動作がかなり重くなり、Firefoxの起動やタブを開くたびの応答性にも影響が出ていました。この厄介なアンチウイルスを無効にしたところ、応答時間は少なくとも3分の1に短縮され、メモリ使用量も半減しました。調べてみると、このアンチウイルスはウェブコンテンツフィルター的な動作もしており、閲覧しようとするすべてのページを検査していたのです。アンチウイルス、ファイアウォール、コンテンツチェッカー、ウェブフィルター、ツールバー、プラグイン――これらはすべて、ブラウザの挙動を変えてしまいます。

したがって、あなたのテスト(そして私のテスト)は厳密に制御される必要があります。アプリケーションの挙動を調べたいなら、短期利用と長期利用、タブ1つの状態と複数タブの状態、画像描画やスクリプト実行時と静的なHTMLテキストのみの状態、12時間アイドル状態とコールドスタート、ダウンロード中など、さまざまな条件でテストしなければなりません。さらに各バージョンにつき最低2回は繰り返して、結果の正確性を確認し、ばらつきを把握することが大切です。

課題の重大さは理解していただけたと思います。それでは、前置きはこのくらいにして本題に入りましょう。

Linuxでのメモリ使用量

テスト環境: Linux Mint 6 FeliciaをIntel Core Duoマシン上で仮想化して実行。ゲストOSには512MBのRAMを割り当て、Firefoxはデフォルトテーマ以外のアドオンなしで動作させています。まずはシステムモニター(System Monitor)ユーティリティを開いて、システム自身が教えてくれる情報を確認してみましょう。

Firefox 3.0.3:

Firefox 3.1 Beta 3:

ご覧のとおり、Beta版は既存の正式版の24.4MBに対して29MBを使用しています。これはコールドスタート直後、タブ1つを開いた状態での数値です。全体としては約19%の増加に見えます。

この数字は何を語っているのか?

答えは:何も語っていません。一般的にLinuxでは、アプリケーションは実際には使わないメモリまで確保しがちです。特にJavaベースのプログラムは顕著で、将来のためにメモリを先回りして確保し、他のプロセスが要求すれば時間をかけて解放していきます。つまり、静的な数値にはほとんど意味がないのです。必要以上に確保して、求められれば手放す――それは決して強欲ではありません。

プログラムが本当に消費している量を知るには、余分な部分をすべて剥ぎ取る必要があります。具体的には、システムのメモリプール全体(今回の場合512MB)を使い尽くすことです。しかし、大量のプログラムを起動するだけでこれを実現するのは困難です。最悪の場合、システムがメモリ不足に陥るとOOM(Out-of-Memory)キラーが発動し、問題のプロセスを強制終了してしまうからです。そこで必要になるのが、一時的にメモリを根こそぎ奪い、その後にすべて返却する仕組みです。

お察しのとおり、必要なのは……memhogです。

Memhog

これは、まさに先ほど述べた通りの動作をする非常にシンプルなユーティリティです。メモリを占有し、その後返却します。この過程で、稼働中のすべてのプロセスは未使用のメモリ予備を手放すことを強いられ、必要最小限のサイズへと引き締められます。

Linux Mintのリポジトリにはこのユーティリティは含まれていませんが、自分で作ることができます。C言語のコードをダウンロードしてコンパイルするだけです。手順は以下のとおりです。

gcc -Wall memhog.c -o memhog

コンパイルできたら、次のように実行します。

./memhog <memory>

実行例:

そのまま実行させましょう。数秒から1分ほどかかります。この間、システムの応答性はかなり低下します。完了したら、テスト対象アプリケーションのメモリ使用量の測定を開始できます。

つまり、テストプログラムを2回実行します。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 Beta 3:

VSZは189MB、実メモリはmemhog実行前に53MB、実行後に39MBです。Firefox 3.1 Beta 3は起動時のメモリ事前確保が少なく、つまり「メモリ食い」度合いは低いと言えますが、動作にはより高いベースラインを必要とします。

これは理にかなっています。Firefox 3.1はFirefox 3よりも多くの機能を備えているからです。機能はどこかに収まり、対応される必要があります。機能が増えればメモリも増える。しかし貪欲さは減るのです。

CPU使用率に注目すると、Firefox 3.1はFirefox 3よりも少なくなっています。memhog前で4.7%対7.7%、後で3.3%対4.2%と、27〜64%の改善です。これも重要なポイントです。実際のメモリ確保量は多いものの、Firefox 3.1はシステムへの負荷が軽く、したがって応答も速いはずだということです。次にメモリマップを見て、Firefox 3.1がなぜ多くのメモリを取るのかを探ってみましょう。

メモリマップ

メモリマップは、/proc疑似ファイルシステム配下でプロセスごとに確認できます。まずプロセスIDを特定し(psで確認済み)、次に /proc/<pid>/maps を参照します。

Firefox 3.0.3:

mapsの出力内容の細部まで説明するのは難しいのですが、ごくごく簡単に言うとこうなります。出力の最初の数行はバイナリコード(text)、データ、ヒープセグメントです。続いて、そのプロセスが使用する共有ライブラリが並びます。出力を順にたどることで、アプリケーションのメモリ使用状況を詳細に分析し、その挙動を理解しようとすることができます。

ここではもっと単純なことをしてみます。プロセスが持つマップの総数を確認するのです。合計数に注目してください。455です。

Firefox 3.1 Beta 3:

こちらは472でした。Firefox 3.1の方が多く必要なのは当然といえば当然ですね?

負荷のかかった状態でのメモリ使用量

しかし、タブを1つ開いて何もしない状態でのテストでは、テストとは呼べません。そこでYouTubeを起動し、Flashをどの程度うまく処理できるかを確認しました。なお、Flash PlayerはFirefox向けのサードパーティ製プラグインであり、Linux Mintにバンドルされているものです。したがって、この「ストレス」テストがどれほど意味を持つかは100%保証できませんが、参考までにご紹介します。前回の記事で見たとおり、Firefox 3.1はJavaScriptパフォーマンスが大幅に向上している点も忘れないでください。

YouTubeでJan Hammerを再生している状態での結果がこちらです。psが約5秒ごとに使用量を報告する設定で、両ブラウザともコールドスタート直後、テスト直前にmemhogを実行しています。

Firefox 3.0.3:

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

Firefox 3.1:

メモリは194MB(実メモリ57MB)、CPUは約11%です。メモリに関しては、ほぼ従来どおりの傾向です。YouTube再生時のCPU使用率が高いのは、Beta版がまだFlashライブラリを最大限活用できるよう最適化されていないことを示唆しています。エンジンが大幅に刷新されたことを考えれば、理にかなった結果です。

もう1点留意すべきは、メモリとCPUの使用量はシステム上で行っている操作によって変動するため、厳密な結論を出すのが難しいということです。それでも、この超マニアックなデータをできるだけ合理的に整理してみます。最後に、OOM(Out Of Memory)スコアを見てみましょう。

OOMスコア

OOMスコアは、カーネルが/procファイルシステム経由で報告するもう1つの数値です。各プロセスのスコアを示し、万一メモリが枯渇した場合にどのプロセスを終了させるかを判断する材料になります。スコアは低いほど良いのです。

OOMスコア/キルの正確なメカニズムは重要ではありません。注目すべきは、新旧Firefoxのスコア比較です。数値は /proc/<pid>/oom_score から取得できます。memhog実行前後で数値を確認しました。

Firefox 3.0.3:

memhog実行前後の差はごくわずかで、Firefoxがかなり賢くメモリを使っていることがわかります。

Firefox 3.1 Beta 3:

こちらはmemhog実行後の結果です(実行前の結果もほぼ同様)。

2つのバージョンの差はごく僅かです。なお、OOMスコアは正確な数値ではなく桁で見るものだという点に注意してください。したがって、システムは両バージョンをほぼ同等に扱っていると言えます。

ここまでの中間まとめ:Firefox 3.1はより多くのメモリを必要とします。より大規模で多機能なアプリケーションだからです。一方で、HTMLやJavaScriptの表示ではCPU使用量が少なく、体感速度は速くなる可能性が高いでしょう。Flashのパフォーマンスには改善の余地がありますが、これはAdobeとMozillaチームが協力して取り組むべき課題です。Flash PlayerはこのBeta向けのものではなく、ディストリビューション(およびブラウザ)に同梱されていたものなので、こういう結果になったのも納得がいきます。

以上でLinux編は終了です。続いてWindows編を見ていきましょう。

Windowsでのメモリ使用量

テスト環境: Windows XP SP3をAMD Athlon 3700+上で仮想化して実行。仮想マシンには768MBのRAMを割り当て、Embeddedテーマを使用し、拡張機能なしのFirefox 3.0.7で動作させています。

このセクションはやや短めになります。私のWindowsハッキングの腕前は悪くないものの、Linuxほどではないからです。それに、Windowsユーザーはあまり大量のコマンドライン操作を見たくないでしょうから、控えます。

メモリ使用量の確認には2つのユーティリティを使用します。標準のタスクマネージャーと、Sysinternals製の強力なツールであるProcess Explorerです。

タスクマネージャー

Firefox 3.0.7:

Firefox 3.1 Beta 3:

メモリ使用量はほぼ同一で、現行版がわずかに3MB優勢です。全体として、Firefoxはタブ1つを開いた状態で31〜34MBを使用しているようです。しかし、これが全貌ではないことはご存じのとおりです。

Process Explorer

先ほどLinuxで見たVSZやRSSに類似した値も確認できます。Process Explorerは喜んでこれらを報告してくれます。

Firefox 3.0.7:

重要な数値は、Working Set(ワーキングセット)の54MB、Virtual Size(仮想サイズ)の114MB、そしてPrivate Bytes(プライベートバイト)の43MBです。Private Bytesは、ほとんどのユーザーが参照すべき指標であり、アプリケーションが正常に動作するために必要なベースラインを表します。Working Setにはプロセスがマップした仮想ページが含まれます。Virtual Sizeは、ある時点におけるアプリケーション全体のフットプリントです。

では、Firefox Betaはどうでしょうか。

Firefox 3.1 Beta 3:

Windows版のFirefox 3.1 Beta 3は、より少ないメモリを使用しています。ベースラインは25MBと低く、Working Setは34MB、仮想サイズは95MBです。おおよそ全体で20MB少ない計算になります。この結果はLinuxでの結果とは異なっており、興味をそそられるところです。

結論

Linuxでは、Firefox 3.1 Betaは現行版よりやや多くのメモリを使用するものの、CPU使用量は少なく、応答性はより俊敏になるはずです。Windowsでは、Firefox 3.1 Betaは現行版より約20MB少ないメモリで動作し、こちらも高速化が期待できます。

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

WindowsとLinuxはメモリの扱い方が異なります。Linuxは通常、必要量より多めに事前確保してから解放するのに対し、Windowsは要求に応じてメモリを追加していきます。これは2つのOSの全体的な挙動ともよく一致しており、メモリを大量に使うタスクでは通常Linuxが有利です。

さらに言えば、これは異なる2つのOS上の、実質的に別々のアプリケーションの話なので、直接比較にはあまり意味がありません。いずれの場合も、2つのOSの動作モデルを考えると、Firefox 3.1 Betaは既存のFirefox 3よりも高速に動作すると期待できます。全体としてフットプリントの差はわずか数十MB程度で、日常使用において大きな影響はおそらくないでしょう。しかし、JavaScriptパフォーマンスの30%向上は体感できるはずです。CPU使用量の低減と相まって、より速いブラウザを楽しめることでしょう。

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

これらの結果は、「こうなるかもしれない」という大まかな推定以上のものとして受け取らないでください。可能な限り綿密を期したとはいえ、テストは設計上不完全で限定的なものです。背景ノイズとテスト全体の繊細さを考えれば、結果はせいぜい「楽しい推測」程度のものです。

とはいえ、memhog、psユーティリティ、メモリマップといったマニアックな道具の使い方を学べたわけですから、このチュートリアルにも十分付加価値があったはずです。今日はここまで。それでは、楽しいブラウジングを!

それではまた。