Linux のメモリー・フットプリントを削減する

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 中級

Martyn Honeyford, Software Engineer, IBM UK Labs

2007年 01月 31日

物理的なメモリーが不足すると、Linux® のパフォーマンスが大きく制限されます。この記事では、Linux システムが使用するメモリーの量を正確に測るための方法を学びます。また Ubuntu システムを例として使用しながら、メモリー要求を削減するための実際的なアドバイスを示します。

Linux の強みとして、Microsoft® Windows® よりも効率的なこと、従って最先端のハードウェアでなくても高いパフォーマンスを得られることが宣伝されています。このパフォーマンスの高さのため、Windows 98 時代の古いマシンをまだ使っている多くの人達にとって、Linux へのアップグレードは非常に魅力的です (Windows 98 はもはや、(特にセキュリティー・パッチの面で) 最新、最高のソフトウェアとしては扱われていません)。

しかし実際には、Linux カーネル自体は相変わらず適度に小さく効率的に構成できる一方で、新しいコンピューターが能力を増強するのに合わせて、多くの Linux デスクトップ環境 (KDE やGNOME など) に大量の機能が追加されてきました。その結果、古いハードウェアにインストールする場合には、大部分のディストリビューションのデフォルト・インストールでは最高のパフォーマンスを発揮できません。同じことは、最近の多くのアプリケーションにも当てはまります。Firefox のような Web ブラウザーや OpenOffice のような統合ソフトは機能が満載されていますが、これらを 128MB の RAM しか持たないマシンで実行しようとすると、悲しい思いをすることになります。

では、どうすればよいのでしょう。古いハードウェアは全部廃棄し、新しいマシンにアップグレードするのでしょうか。それとも circa 1995 から Linux ディストリビューションをインストールすべきなのでしょうか (もし皆さんがそうしたいなら、私が Linux-FT で非常に苦労したことを伝えておきましょう)。

恐れる必要はありません。Linux コミュニティーの人達ならば昔からよく知っているように、Linux カーネルと Linux ディストリビューション一般の強みの 1 つ (最大の強みと言う人もいます) は、カスタマイズが可能なことです。この記事では、そこそこのハードウェアでパフォーマンスを高めるために、どのように Linux システムを調整すべきかを解説します。

メモリーのおかげです

大部分の場合、デスクトップ・オペレーティング・システムのパフォーマンスにとって最も重要な要素は、利用可能なシステム・メモリーの量です。高速のプロセッサーはもちろん重要ですが、そのプロセッサーを活用するために十分な物理メモリーがないと、システムは物理メモリーとスワップ・スペースとの間での頻繁なデータのやり取り (スラッシングと呼ばれる状態) に大きな時間を費やすことになり、CPU はほとんどの間アイドル状態に置かれることになります。従って古いシステムでパフォーマンスを改善するための方法としては、通常はメモリーを追加するのが最も容易です。ただし、さまざまな理由から、必ずしもそれが可能ではないこともあります。空きスロットがない、システムによっては安価な RAM がない (特にラップトップや RAMBUS ベースのシステムの場合など)、さらには、古いシステムに余計な費用をかけたくないという、もっともな理由もあります。

RAM をアップグレードできない、あるいはアップグレードしたくない場合に次善の策として有効なのは、システムの RAM 要件を下げることです。この記事では、Linux マシンのメモリー問題を解決するための単純な 5 つのステップを説明します。

上に戻る

ステップ 1: 適切なデスクトップ環境を選択する

最も重要な選択肢として、皆さんがインストールしようとする Linux ディストリビューションとデスクトップ環境 (DE: desktop environment) があげられます。この 2 つは別々の選択肢ですが、ディストリビューションの選択が DE の選択にも影響します。例えば、Ubuntu に Fluxbox をインストールしても問題はありませんが、単純にディストリビューションに付属しているデフォルトの DE を使った方がずっと楽なはずです。

この記事のシナリオの目標は、新しいユーザーにとって容易な、単純なデスクトップ指向のディストリビューションを見つけることです。ここでは最初に Ubuntu 6.10 から始めました。これには GNOME 2.16 が付属しています。

私はベース・システムとして、800MHz のプロセッサーと 256MB の RAM を持つ古いマシンを選びました。そしてテストをそれぞれ 2 回行います。1 回は通常どおり 256MB の RAM を使って起動し、もう 1 回は、カーネルが 128 MB の物理メモリーしか認識しないように、カーネル行に mem=128M と追加して起動します。こうすることで、実際には物理的に 2 台目のマシンを使わずに (あるいは物理的にマシンの RAM チップを何度も抜き差しせずに)、実質的に 256MB のマシンと 128MB のマシンの両方を検証することができます。このカーネル行オプションによって、128MB のマシンの動作を十分に近似することができます。ただし、もし実際に 128MB しかなかった場合には、さらに面倒なことが必要になるかもしれないことに注意してください。例えば Ubuntu の場合、192MB 未満の RAM のマシン用に一般的に使われるインストール・ディスクとは異なるインストール・ディスクを使う必要があります。

メモリー使用量のベース・レベルを知るには、システムを起動し、デスクトップにログインし、そしてターミナルを起動します (この記事のこれから先では、この設定をベース・レベルと呼ぶことにします)。次に、free コマンドを使ってフリー・メモリーの量をチェックします。その結果をリスト 1 に示します。

                
ubuntu # free
             total       used       free     shared    buffers     cached
Mem:        255988     231704      24284          0       6432     139292
-/+ buffers/cache:      85980     170008
Swap:       746980          0     746980

最初の行は、256MB の RAM のうちの 231MB が「使用中」であることを示しています。次の行は、使われている 231MB のうち実際にアプリケーションが使っているのは 86MB のみであること、残りはバッファーとキャッシュに使われていることを示しています。

このリストからパフォーマンスを評価する上で最も重要な部分は、Swap の行です。この行は、現在スワップが使われていないこと、従って現状では何もメモリーの問題がないことを示しています。このシステムは、遅いディスク・ベースのスワップ・スペースを使わずに、すべてを物理メモリーの中に収めることができています。

次に、このシステムを日常的な使い方をした場合の様子をつかむために、Web ブラウザー (Firefox 2.0) を起動して developerWorks にアクセスし、インスタント・メッセージング・クライアント (Gaim) を MSN に接続し、ファイル・マネージャーを使ってフォルダーをブラウズし、そして Microsoft Word フォーマットの中規模サイズの文書を OpenOffice で開きます。(この記事のこれから先では、この設定を軽量使用レベルと呼ぶことにします。)

すべてがロードされると、free コマンドの出力はリスト 2 のようになりました。

                
ubuntu # free
             total       used       free     shared    buffers     cached
Mem:        255988     252196       3792          0      21276      87500
-/+ buffers/cache:     143420     112568
Swap:       746980      18676     728304

これを見ると、メモリーの余裕が少し減ったことがわかると思います。今度はアプリケーションが 143MB の物理メモリーを使っており、残りがバッファーに使われています。また、今度はシステムが 18MB のスワップを使う必要があります。このシステムを全体的に見ると、こうした軽量のオフィス・タスクには十分ですが、あまり余裕はなく、もっと要求の厳しいもの (大きなデジタル写真やビデオの編集など) をする気にはなれません。そんなことを始めれば、システムの動作はたちまち極端に遅くなるでしょう。

このシステムの動作が 128MB のメモリーではどうなるかを見るために、再起動し、先ほど触れたようにカーネル行に mem=128M を追加しました。リスト 1 と同じベース・レベルの状態で 128MB の RAM とすると、結果はリスト 3 のようになりました。

                
ubuntu # free
             total       used       free     shared    buffers     cached
Mem:        126100     121464       4636          0       1636      37000
-/+ buffers/cache:      82828      43272
Swap:       746980      17924     729056

今度は 128MB しかないため、既にスワップが使われ始めており、しかも実際にはまだ何も始まっていないのです。

先ほどの単純なアプリケーション・セットを起動した結果をリスト 4 に示します。

                
ubuntu # free
             total       used       free     shared    buffers     cached
Mem:        126100     123608       2492          0        392      51208
-/+ buffers/cache:      72008      54092
Swap:       746980      98452     648528

こうした数字から予測できると思いますが、通常の使用に対してもマシンの応答はずっと遅くなっています。こうした単純なタスクにはまだ何とか使えますが、ディスクが非常に頻繁にアクセスされており、私はこのマシンを自分のメイン・マシンにする気にはなれません。必要なアプリケーション・メモリーの合計は約 170MB ですが、物理メモリーは 72MB しか入らないため、98MB をスワップに頼っています。これを見ると、システム応答が遅い理由がわかるというわけです。

次のテストでは、Ubuntu に関連するプロジェクトのディストリビューションである Xubuntu を使うことにしました。このディストリビューションは Ubuntu に非常によく似ていますが、GNOME ではなく Xfce 4.4 Beta 2 DE を使っています。一般的な GNOME や KDE は最大機能を提供することを主眼に置いていますが、Xfce は軽量になるように設計されています。そのため、古くなりつつあるハードウェアに向いていると期待できます。Ubuntu を使って行ったテストと同じテストを、このディストリビューションを使って行うことにします。

リスト 5 を見ると、ベース DE が使用するアプリケーション・メモリーは約 25 MB 少なく、Ubuntu の場合よりもバッファーとキャッシュの使用量が大幅にがずっと少ないことがわかります (これはファイル操作が少ないことを意味しているかもしれません)。

                
xubuntu # free
             total       used       free     shared    buffers     cached
Mem:        255988     170964      85024          0       6004     104700
-/+ buffers/cache:      60260     195728
Swap:       746980          0     746980

リスト 6 では、先ほどのテスト・アプリケーション・スイート (Web ブラウザー、IM クライアント、そしてワード・プロセッサー) を再度起動します。同じアプリケーション・セットに対して Ubuntu が要求するよりも、メモリーの使用量が約 20MB も少ないらしいことがわかります (物理メモリーに 126、スワップに 17 で合計 143 に対して、Ubuntu では 143 + 18 で合計 161 です)。

                
xubuntu # free
             total       used       free     shared    buffers     cached
Mem:        255988     252180       3808          0       1972     124008
-/+ buffers/cache:     126200     129788
Swap:       746980      16956     730024

リスト 7 は、128MB の RAM しかない場合のベース・レベルでのメモリー使用量を示しています。今度はメモリーの制約された私のシステムでも問題なく、スワップもまだ使われていません。

                
xubuntu # free
             total       used       free     shared    buffers     cached
Mem:        126100     123228       2872          0       4252      60484
-/+ buffers/cache:      58492      67608
Swap:       746980          0     746980

リスト 8 では、再度アプリケーション・セットを起動しています。この場合も、相変わらずシステムは Ubuntu の場合よりもずっと良好ですが、やはり大量のスワップが使われており、マシンは少しばかり低速です (ただし Ubuntu の場合ほどには遅くありません)。

                
xubuntu # free
             total       used       free     shared    buffers     cached
Mem:        126100     123980       2120          0        468      56276
-/+ buffers/cache:      67236      58864
Swap:       746980      64516     682464

こうした数字からわかるとおり、全般的にどの場合でも Xubuntu の方が使用メモリーは少なくなっています。そのため、128MB (あるいはそれ以下) しかない場合には、Xubuntu がおそらく適切な選択肢と言うことができます。

Linux ディストリビューションの素晴らしいところは、通常はコストがかからないことです。そのためいくつかをダウンロードし、しばらく使ってみてみた上で気に入ったものを選ぶ、あるいは使用しているハードウェア上でのパフォーマンスを調べる、といったことが容易にできます。もしハードウェア上の制約が非常に厳しい場合には、Damn Small Linux のようなディストリビューションも検討に値します。Damn Small Linux は、486DX プロセッサーで 16MB の RAM という限定された仕様のシステムでも動作すると言われています。

私のシステムは 256MB で多少余裕があり、私は通常は KDE を使っているので、やはり Ubuntu から派生した、Kubuntu と呼ばれるディストリビューションも使ってみました。Kubuntu は KDE ベースであり、メモリー使用の面では Xubuntu と Ubuntu の中間のようです。参考までに、Kubuntu のベース使用レベルをリスト 9 に示します。

                
kubuntu # free
             total       used       free     shared    buffers     cached
Mem:        255988     244736      11252          0       7612     160008
-/+ buffers/cache:      77116     178872
Swap:       746980          0     746980

上に戻る

ステップ 2: 適切なアプリケーションを選択する

ディストリビューションを選択できたら、次は使用するアプリケーションを検討することです。メモリー要件は、アプリケーションによって大幅に異なります。場合によるとサイズと機能のいずれかを選択せざるをえないこともあります。また場合によっては機能上は等価なアプリケーションでもメモリー要件が大幅に異なることもあります。

この記事では、メモリー使用量を測定するためのツールとして、exmap を使います。exmap は複数のアプリケーションで使われる共有ライブラリーを考慮して測定するため、ps や top よりも正確です。例えば、2 つのアプリケーションが 1MB のメモリーを使用する同じ共有ライブラリーを使用している場合、ps は両方のアプリケーションが 1MB の余分なメモリーを使っていると表示しますが、exmap はもっと正確に、各アプリケーションが 500 KB を使っていると表示します。こうした精度の高さは、アプリケーション間で共有しているライブラリーをとても頻繁に使用する KDE や GNOME などのデスクトップ環境を評価する場合、特に重要です。

これから先のセクションで説明する各アプリケーションでは、exmap が出力する常駐値 (resident value) と実効常駐値 (effective resident value) を測定します。常駐値は、あるプロセスが使用している物理メモリーの合計量を (他のプロセスで使用している共有ライブラリーを含めて) 表します。この値は、通常 ps あるいは top で得られる種類の値と同じです。一方、実効常駐値は、共有ライブラリーを使用しているすべてのプロセス間で共通ライブラリーを均等に割り振った場合の値であり、対象プロセスが使用しているシステム・メモリーの量をずっと正確に示しています。

また、あるプロセスの合計メモリー・フットプリントを判断する際には、プロセスの一部としてスワップの中に置かれる、マップ値と実効マップ値も考慮する必要があることに注意してください。マップ値は常駐値と似ていますが、物理メモリーではなくスワップのページに関するものです。つまり共有ライブラリーを考慮しない評価方法では常駐値とマップ値とが加算されており、共有ライブラリーを考慮する評価方法では実効常駐値と実効マップ値とが加算されていることになります。下記の表では、マップ値を記録しませんでした。その理由は、私の行ったテストではどのプロセスもスワップに置かれることがなく、そうした列に対する exmap コマンドの出力の値がゼロだったためです。

Web ブラウザー

表 1 の各ブラウザーに対して、そのブラウザー・アプリケーションを起動し、developerWorks のホームページを開き、完全に描画されるのを待ちました。その結果が表 1 です。

この表を見るとわかるように、使用されるメモリーの量には大きな幅があり、最もメモリーを消費するブラウザー (Firefox) は、最もメモリー消費量の少ないブラウザー (Lynx) よりも約 27 倍もメモリーを使用しています。ただしこれは完全に公平な比較ではありません。Lynx は他のブラウザーと機能的に等価ではないからです (例えば Lynx はグラフィックスを描画することすらできません)。しかしこの表から、システム要件によっては大幅にメモリーの使用量を削減できることがわかります。リスト 1 の最初の 3 つのブラウザー同士 (どれも機能的にほぼ等価です) で比較しても、Opera の使用量は Firefox の約 3 分の 2 であり、Konqueror は Firefox の半分以下のメモリーしか使いません。

あまり要件が厳しくない場合には、完全機能のブラウザーと最小限の機能の Lynx との妥協点として、Dilloが妥当かもしれません。Dillo には GUI があります。ただしデフォルトの状態では非常に機能が制限されており、プラグインを追加しない限り SSL さえサポートされません。

また、共有メモリーの使い方を比較すると、Konqueror は Firefox よりもずっとパフォーマンスが高く、約 14MB も少ないメモリーで済むことにも注目してください。ただし合計使用量を見ると、Konqueror は相変わらず Firefox よりも優れていますが、それほど大きな差はなく、5MB ほど少ないだけです。これは、(私が KDE デスクトップを使っているため) Konqueror が共有 KDE ライブラリーを頻繁に使い、このライブラリーが多くのアプリケーションにロードされるためです。ただし私が他の KDE アプリケーションを何も使っていなければ、KDE よりも Opera の方が適切な選択肢です。これについては後ほど詳しく説明します。

ワード・プロセッサー

私はワード・プロセッサーをテストするために、最初のテストで使用したものと同じ Microsoft Word フォーマットの文書を、表 2 のワード・プロセッサーにロードしました。

こうした数字から明らかなように、OpenOffice Writer は、KWord や AbiWord よりもずっと多くのメモリーを使用します。OpenOffice 以外に、Microsoft Word フォーマットの文書を正確に描画するという点では、KWord が最高でした。AbiWord は文書を開くことはできましたが、正確な描画という点で、いくつかの問題がありました。そのため、Microsoft Office との互換性が重要な場合には OpenOffice を使った方が無難です。

インスタント・メッセージング・クライアント

インスタント・メッセージングをテストするために、表 3 に示す IM クライアントを使って私の MSN Messenger アカウントにログインしました。

私の関心は MSN に接続することのみなので、ここでは Kmess が私にとってベストであり、また妥当な選択でもありました。他のサービスが必要な人にとっては、Kopete が最善の選択肢のようです。ただし、他の IM プロトコルを使うと、アプリケーションが使用するメモリーが増える可能性があることに注意してください。また、Kmess は統合 KDE アプリケーションなので、もし KDE を使うのでない場合には、Gaim の方が適切かもしれません。

繰り返し検討する

これでアプリケーションが使用するメモリーの分析方法がわかったので、対象とするすべてのアプリケーション・タイプに対してこのプロセスを繰り返し、最もメモリー要件が小さく、しかも機能的な要件を満足する選択肢が見つかるまで、さまざまなオプションを試せばよいわけです。

先ほどの Web ブラウザーのセクションで気付いたかもしれませんが、多くの場合、最もメモリーを節約できるのは、使用するデスクトップ環境と緊密に統合されるアプリケーションを使った場合です。そうしたアプリケーションは、DE に組み込まれた、そしておそらく既にロードされた共有ライブラリーを頻繁に使用するからです。例えば、Konqueror は KDE のファイル・マネージャーであると同時に Web ブラウザーです。そのため Konqueror は、KDE システムで実行された場合には (機能の大部分は既に他のアプリケーションによってロードされているため) Firefox よりもずっと少ないメモリーしか使いません。同様に、もし RSS アグリゲーターを使いたい場合には、Akregator が適切な選択肢かもしれません。おそらく Akregator はこうした同じライブラリーをまた使うからです。

従って、メモリーの使用量が気になる場合には、こうしたテストを自分自身のシステムで行うことが重要です。一般的に、そのシステムにとってメモリー使用が少ないアプリケーションがどれかを、他の人のベンチマークを見ただけ判断するのは困難だからです。

これはつまり、DE の選択も影響するということです。例えば、どうしても Konqueror を使いたい場合には、DE として KDE を使うのがおそらく最も効率的です。同様に、GNOME ユーザーの場合には、目にとまった単純な KDE アプリケーションを使う前に、十分に検討する必要があります。そのアプリケーションでしか使われない、大量のライブラリーがロードされてしまうかもしれないのです。

上に戻る

ステップ 3: 不要なサービスや設定を削除する

ディストリビューションとデスクトップ環境、そしてアプリケーションを選択した後は、さらにメモリーの使用量を減らすために他に何をすればよいのでしょう。その質問の答えとして、さらに深く掘り下げ、システム構成を考える必要があります。exmap を使うと、システム上で何が実行されているかを分析することができ、また必要のないものを削除し、必要なことをするための構成を行うことができます。

手始めとして、システムが起動すると自動的に起動されるサービスを調べることです。ただしこの場合、システムの実行に必要なものを誤って削除しないように注意する必要があります。また、何が必要かはディストリビューションによって異なるため、そのディストリビューションに必要なものやサービスの構成について、少し調べる必要があります。ディストリビューションによっては、メモリーを大量に消費する Web サーバーなど、必要のないサービスを大量にデフォルトで起動するものがあります。

システム・サービスを調べ終わったら、DE の構成を調べる必要があります。必要のないサービスを DE が起動しているかもしれません。

私の Kubuntu マシンは必要のないサービスをそれほど多くは起動しないようですが、それでもプロセス・リストをちょっと見ただけでも、明らかに不要なものがあります。削除できたものは下記のとおりです。

• HPLIP (4.4MB): HP のプリンターとスキャナーのためのサービスです。そんな機器はこのコンピューターに接続されていないので、必要ありません。
• cupsd (1.1MB): プリンター・デーモンです。このコンピューターにはプリンターが接続されていないので、必要ありません。
• kbluetoothd (3.2MB): KDE の Bluetooth デーモンです。このコンピューターは Bluetooth 接続機能を持っていないので、必要ありません。
• klipper (1.7MB): KDE クリップボード・ツールです。私にとっては興味のないツールなので、無効にします。
• KMix (4.1MB): KDE オーディオ・ミキサーです。私は外部スピーカーで音量を調整しているので、常に実行している必要はありません。

たった 5 分間構成をいじるだけで、約 14MB のメモリーを節約できました。最初は約 77MB も使っていたことを考えれば、悪くはありません。

DE や大きなアプリケーションの設定は、十分に検討する価値があります。場合によると、使用するメモリーの量に影響する設定があるかもしれません。例えば、背景に大きなビットマップを使っている場合は特に、仮想デスクトップの数を減らすことでメモリーを少し節約できるかもしれません。見た目に楽しい視覚効果をいくつかオフすることも、効果があるものです。

上に戻る

ステップ 4: 過度な期待をしない

古いハードウェアを実行する場合には、そのマシンの制限を理解し、その制限に応じて作業することが重要です。例えば、写真のコレクションを編集しようとする場合、すべての写真を同時に開くべきではありません。そんなことをすると不必要にメモリーを浪費するだけです。1 つずつ写真を開いてから閉じた方がずっと安全です。同様に、ビデオをキャプチャーして編集する場合にも、大量のシーンを一度にキャプチャーしようとせず、個々のシーンをキャプチャーすることです。また、図を含む大きな文書を作成する場合には、テキストが終了してから図を追加するようにします。

上に戻る

ステップ 5: システムを最適化する

最後のステップとして、システムの内部に深く入り込み、どこかで少しでもメモリーを節約できないかを調べます。節約できる部分はいくらでもありますが、収穫逓減の法則が当てはまり、大部分の場合、苦労に見合うほどの成果は得られません。とはいえ、やはり考慮すべきことはあります。そのいくつかを下記にあげます。

• そのハードウェア専用のドライバーしか持たないようにカーネルを再コンパイルします。主流のディストリビューションの大部分は、広範な種類のハードウェアに対応できるように作られています。そのため、使われないハードウェア・サポートを大量に含んでいることがよくあります。それによる利点もいくつかありますが、実際には大部分のハードウェア・サポートはモジュール形式になっており、要求されなければロードされません。
• 一部のアプリケーションあるいはライブラリーを再コンパイルしてサイズを最適化し、また使用する特定の CPU に対象を絞ることで、多少のメモリーを得られる可能性があります。Gentoo ディストリビューションは、これに最適です。Gentoo では、コンパイル・フラグを厳密に選択することで、システムの一部あるいは全部を容易に再コンパイルすることができます。ただし残念ながら、このプロセスは古いマシンでは非常に長くかかる傾向にあります。
• 特定の機能を削除してからアプリケーションやライブラリーを再コンパイルすることも、メモリー要件を減らす上で有効です。この場合も、Gentoo が最適です。Gentoo には USE フラグの概念があり、これを利用すると、アプリケーションの機能を無効にしてシステムを容易にビルドすることができます。こうすることで、アプリケーションのサイズを大幅に削減することができます。アプリケーションは通常、多数のファイル・フォーマットやコーデックなどをサポートするようにしてリリースされますが、そうしたサポートを実際に提供するためのライブラリーがロードされてしまうことがよくあります。例えば、もし JPEG ファイルを読む必要がないことがわかっている場合には、それを Gentoo の中で (USE="-jpeg" によって) 指定します。すると、グラフィックスを処理するすべてのアプリケーションは JPEG サポートなしでコンパイルされ、それによってたいていの場合はメモリー・オーバーヘッドを小さくすることができます。
• 最新の 2.6 カーネルには、実行時に調整可能な swappiness パラメーターがあります。このパラメーターによって、キャッシュやバッファーを削減する代わりに、アプリケーションがスワップ用に移動される可能性を指定することができます。この記事の初めの方に行ったテストで、物理メモリーの大きい塊がキャッシュ用に予約されている一方で、アプリケーションがスワップ・アウトされることが一般的であることを見ました。スワップ・アウトされる傾向を減らすことでキャッシュが削減され、より多くのアプリケーションがメモリー中にとどまるようになります。ただし、これによって実際にマシンの実行が速くなるかどうかは、どんなアプリケーションを実行するかに大きく依存します。アプリケーション間で絶えずスワップが行われる場合には、これを行うことでアプリケーションがメモリーに常駐することが増えるため、マシンの応答が良くなったように見えるかもしれません。しかし、ディスクとの読み書きを大量に行うタスクの場合は、おそらく遅くなるでしょう。一般的に言って、swappiness の値を減らすと、対話型のアプリケーションではシステム応答が良くなりますが、全体的なスループットは低下します。

上に戻る

まとめ

この記事で紹介した考え方によって、古いマシンに新しい命を吹き込むことができ (場合によってはセキュリティーを追加することができ)、古いハードウェアでも Linux を活用できるようになるはずです。測定結果によれば、完璧に使用できる Linux デスクトップを 800-MHz/256-MB のマシンに収めることができ、E メールや Web ブラウジング、ワード・プロセッサーなどの軽量のオフィス処理や家でのちょっとした作業を行うことができます。少し細工を加え、実験で確認すれば、たとえ 128MB のマシンであってもデスクトップ・コンピューターとして十分快適に使用可能です。

この記事では、ある程度制約のあるハードウェアでも十分に機能するデスクトップを実現することに焦点を当てましたが、同じ原理を Linux の使い方全般に適用することができます。最新のスーパー・マシンがいくら大量のメモリーを搭載しているとしても、すぐにそれを使い切るような新しいアプリケーションが出てきます。ここで紹介した方法を適用することで、過負荷のサーバーから少し余計にパフォーマンスを絞り出せるかもしれず、あるいは皆さん自身のアプリケーションでのメモリーの使用について理解できるかもしれません。

参考文献

• Lubos Lunak にある 2 本の有益な記事を読み、メモリーの使用について学んでください。
  
  
• developerWorks の Linux ゾーンには、 Linux 開発者のための資料が豊富に用意されています。
  
  
• developerWorks technical events and Webcasts で最新情報を入手してください。
  
  

• メモリー分析ツール、Exmap について学んでください。
  
  
• この記事で紹介した下記のディストリビューションについて学んでください。
  • Ubuntu
  • Kubuntu
  • Xubuntu
  • Damn Small Linux
  
  
• 2枚組 DVD セット、SEK for Linux をご注文ください。DB2® や Lotus®、Rational®、Tivoli®、WebSphere® など、Linux 用の最新 IBM ソフトウェアの試用版が含まれています。
  
  
• IBM trial software を使って皆さんの次期 Linux 開発プロジェクトを構築してください。developerWorks から直接ダウンロードすることができます。
  
  

• developerWorks blogs から developerWorks のコミュニティーに加わってください。

著者について

		Martyn Honeyford は1996年にノッティンガム大学にてコンピューターサイエンスの理学士号を取得して卒業。それ以来、英国のハースリーにあるIBM UK Labsにてソフトウェア技師として勤務。現在の役割は、WebSphere MQ Everyplace開発チームでの開発者。プライベートの時間には、（あまり上手とは言えない）エレクトリック・ギターを演奏しているか、一般人から見て健全とは言えないほどにビデオゲームをプレイしまくっている彼の姿を見掛けることでしょう。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る