レベル: 中級 Peter Seebach (developerworks@seebs.plethora.net), Freelance author, Plethora.net
2008年 3月 31日 ソニーの PlayStation 3 (PS3) は Linux® を実行することができます。しかし Linux を適切に実行させるためには少し調整が必要です。このシリーズの 2 回目である今回は Peter Seebach が、メモリーは一体どこに使われているのかを調べ、そうしたメモリーを有効に利用する方法について説明します。
このシリーズの第 1 回では、PS3 (PlayStation 3) の Linux について、また開発環境としての PS3 Linux の優れているところと弱点とを紹介しました。この第 2 回では、PS3 システムが Linux を実行する上でのパフォーマンスに大きな影響を与える可能性のある、いくつかの項目について説明します。
ここで説明する助言のすべてが全員にとって有効なわけではありません。グラフィックスの作業を行うのであれば、X なしでシステムを実行するということはできません。その一方、グラフィックスを扱わないのであれば、X を使わなくてすむため、システムのメモリー・フットプリントに大きく影響するものはありません。
スワップ・ドライブをマウントしなくても快適に動作するデスクトップ・システムに慣れている人にとっては、メモリーに焦点を当てることは奇妙に思えるかもしれません。しかし実際のところ PS3 は、そのままの状態で最近のデスクトップ Linux を快適に使いこなすために十分なほどのメモリーを備えていません。デフォルトの Fedora 7 がインストールされた状態で、システムはかなりの時間を (そして皆さんの時間を) スワッピングに費やしてしまいます。スワッピングはどのようなシステムにも大きな不利益をもたらします。ハイパーバイザーを介してアクセスされる 2.5 インチのディスク・ドライブを中心に構成され、メイン・メモリーは大部分のデスクトップに見られるものよりも大幅に高速な PS3 システムでは、スワッピングによる影響は通常のデスクトップ・システムの場合と比べると遥かに大きいものがあります。
もう 1 つ、注意点を挙げておきます。私のテスト・システムでは、元々インストールされていた 2.6.21 カーネルを使うとリブートの動作に信頼性がありませんでした。2.6.23 カーネルでは、PS3 アドオン CD から入手できるバージョンを使うか、あるいは標準の Fedora アップデーターから入手できるバージョンを使うことで、この問題を修正することができます。一般的に言って、おそらく最も確実なものは PS3 アドオン CD から入手できるカーネルです。
メモリーの使用量を減らす
 |
このシリーズについて
この 3 回シリーズの記事では、開発環境という視点から PS3 Linux を調べます。
最初の記事では、第 1 回として、基本的な構成のための PS3 特有の調整項目やウィジェットを紹介し、それらを効果的に使うための方法を説明し、そしてパフォーマンスの改善や使いやすい表示を実現するための、ちょっとした細工を提言します。
第 2 回と第 3 回は、パフォーマンスとチューニングの問題をいくつか掘り下げ、そうした問題への対応はどのシステムにでもあてはまるものの、PS3 を概念検証デモから実際に動作するシステムに変える上で特に有効であることを解説します。
|
|
このトピックは重要な場合もあり、重要でない場合もあります。大部分のデスクトップ Linux のユーザーにとって、メモリーの使用量を減らすために実際に何かをする必要がある、という感覚は遠い昔の記憶にすぎません。しかも、プロセスは利用可能なメモリー空間を使い切るように進化していく傾向があるため、64MB のメイン・メモリーを搭載したマシンが強力なサーバーだと思われていた当時でも、大した量のソフトウェアは実行されておらず、マシンもそれほどメモリーを必要としませんでした。しかし PS3 はメモリーの使用量が大きく影響するシステムの 1 つであり、また Fedora 7 は魅力的ではあるものの、少量のメモリーしか搭載していないシステム用に設計されたものではありません。
メモリーの使用量を減らすためには、まずメモリーを最も大量に消費する部分を特定する作業から始めます。これを容易に行う方法として、システム上のプロセスをライブで表示できる、top を使う方法があります。top はデフォルトで、さまざまなプロセスを CPU 使用率でソートして表示します。これは他の種類のパフォーマンス・チューニングには便利ですが、メモリーを大量に消費する部分を追跡するためには最善の方法ではありません。そこで top がメモリー使用量の要約を表示することに注目してください。例えば、X を実行する、(ただしいくつかのサービスをオフにした) ある 1 台の PS3 では次のような結果が得られます。
リスト 1. 実際にそんなに大量のメモリーを使用しているのでしょうか
Mem: 219192k total, 213692k used, 5500k free, 7232k buffers
Swap: 4192956k total, 0k used, 4192956k free, 89468k cached
|
top を起動し (シェルで top と入力して実行します)、次に O (大文字の O で、order by (～の順に) を表します) を、そして q を入力し、最後に Enter キーを押します。この場合、q は「常駐サイズ」を意味し、このプロセスがメモリーを実際にどれだけ使用しているかを表します。もう 1 つの選択肢としては、「仮想サイズ」(オプション o) が考えられます。
これによってプロセスの一覧が、物理的に実際に使用されているメモリー量の順に表示されるはずです。以下に示すのはそうした一覧からの抜粋です (これもテスト・マシンの例です)。
リスト 2. どうやら実際に大量のメモリーを使用しているようです
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3259 root 20 0 65424 36m 4996 S 2 17.2 0:01.39 Xorg
3422 seebs 20 0 92900 24m 20m S 0 11.6 0:01.22 nautilus
3439 seebs 20 0 58600 24m 22m S 0 11.5 0:00.36 nm-applet
3473 seebs 20 0 56620 24m 14m S 0 11.4 0:01.22 /usr/bin/sealer
3420 seebs 20 0 50248 21m 18m S 0 10.2 0:01.90 gnome-panel
3476 seebs 20 0 48988 14m 10m S 1 6.9 0:00.64 gnome-terminal
3445 seebs 20 0 33104 14m 9464 S 0 6.7 0:00.40 puplet
3453 seebs 20 0 45764 13m 12m S 0 6.4 0:00.22 gnome-power-man
3414 seebs 20 0 41920 9696 8052 S 0 4.4 0:00.29 gnome-settings-
3418 seebs 20 0 22200 8996 7316 S 0 4.1 0:00.33 metacity
3297 seebs 20 0 40544 8384 7088 S 0 3.8 0:00.32 gnome-session
3432 seebs 20 0 20076 6120 5244 S 0 2.8 0:00.10 bluetooth-apple
3444 seebs 20 0 14692 6060 3532 S 0 2.8 0:00.24 python
|
メモリーを大量に使用している上位 10 位ぐらいまでは、すべて X に関係しています。これが、本当にメモリーを解放したい場合の最初の選択肢の 1 つが X をシャットダウンすることである理由です。これらのアプリケーションの多くが GNOME 特有のものであることに気付くと、KDE を試したくなるかもしれませんが、それは解決になりません。PS3 での KDE のメモリー・フットプリントは GNOME と同程度です。
実際のところ、どうしても X が必要であれば、最善の選択肢は X のログイン・ウィンドウに用意されている X セッションの環境を使わないことです。つまり X セッションの環境を使う代わりにコンソールからログインし、ウィンドウ・マネージャーを小さく、また追加プログラムを少なくして X を起動するのです。しかし、そのためにはどうすればよいのでしょう。最初のステップは、top を終了し、そしてプロンプトに戻ることです。そこで q を押します。
ランレベルを利用する
ランレベルは大部分の Linux ユーザーにとって、今まで特に学ぶ必要がなかった機能です。ランレベルは基本的に System V UNIX® から継承されたものですが、当然ながら、System V UNIX と Linux とではいくつかの違いがあります。ランレベルというのは、同時に実行されるシステム・サービスのセットを定義したものです。Gnome または KDE といったグラフィカル・ログイン・プログラムを持つ、通常のデスクトップ Linux 環境は、歴史的な理由から、ランレベル 5 と呼ばれます。X を持たない、従来のスタンドアロンのワークステーションは、多くの場合はランレベル 2 で実行されます。理論的には、/sbin の中にある init コマンドを使ってシステムのランレベルを直接変更するだけで、ランレベルを簡単に変更することができます。例えば、(root として) /sbin/init 2 を実行すると、システムに対してランレベル 2 に移行するように命令していることになります。(この移行は通常、ランレベル 2 で使用されないサービスをすべて停止し、次にランレベル 2 で使われるすべてのサービスを起動することで行われます。)
デフォルトのランレベルは /etc/inittab ファイルの中の 1 行によって設定されます。この 1 行は次のようなものです。
リスト 3. デフォルトのランレベル
| |
ランレベル
実際には、0 から 6 まで 7 つのランレベルがあります。0 は「停止」であり、その動作はシステムに対してシャットダウンを指示した場合と同じです。1 は「シングル・ユーザー・モード」であり、このモードが使われるのは診断や修理の場合がほとんどです。2 はマルチユーザーであり、3 はマルチユーザー「プラス・ネットワーク」(通常は NFS を意味します) です。4 は使われず、5 は XDM、そして 6 はリブートです。
/etc/inittab ファイルに記述されているように、システムのデフォルトのランレベルを 0 または 6 に設定してはいけません。0 または 6 に設定してしまうと、そこから回復することは困難なことが多いのですが、優れたブート・ローダーやリカバリー CD を使えば修復できるはずです。ランレベルを使用する最近のデスクトップ Linux システムでは、大部分がデフォルトとしてランレベル 5 を使用しています。一部のシステムには他の起動機構が使われていますが、Fedora 7 で使われているのはランレベル 5 です。
|
|
この行のフォーマットは歴史的なものであり、これを変更して実際の効果を得るためには、5 を 2 または 3 に変更できる、ということだけ知っていれば十分です。5 を 2 または 3 に変更すると、次回システムがブートした時にはシステムは X は起動されず、テキスト・コンソールにログイン・プロンプトが表示されます。
単純な事実として、メモリーに制限のある開発システムにとって、テキスト・コンソールはフル装備の X 環境よりも適切な選択肢です。よい機会なので、少しいじりながら何を削除できるか調べてみましょう。/etc/inittab の initdefault の値を 3 に変更してリブートします。(実際には init コマンドを使ってランレベルを移行することもできますが、稀に、その方法ではうまく行かないことがあります。) すると、システムがそれまでよりもずっと早く起動することが、すぐにわかるでしょう。ログインしたら、すぐに再度 top を実行してみます。結果はさまざまに異なるかもしれませんが、メモリーはおそらく半分ほどしか使われておらず、ほとんど完全に使用されているということはないはずです。これは大きな前進です。
それでもまだ大量のメモリーが使われています
100 メガバイトの空きがあることは確かに素晴らしいことですが、このシステムではおそらくもっとメモリーを有効に使えるはずです。再度 top を実行すると、メモリーを大量に消費しているものが、さらにいくつか表示されます。
リスト 4. 私が希望して使用しているわけではありません
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2204 root 39 19 30056 12m 5632 S 0 5.7 0:00.70 yum-updatesd
1825 root 20 0 19220 5052 972 S 0 2.3 0:00.00 python
2238 haldaemo 20 0 6648 2728 2180 S 0 1.2 0:00.27 hald
1909 root 20 0 13480 2236 1564 S 0 1.0 0:00.02 cupsd
2015 root 20 0 12352 1976 1272 S 0 0.9 0:00.02 console-kit-dae
1958 root 20 0 12132 1796 748 S 0 0.8 0:00.01 sendmail
2301 root 20 0 5548 1792 1484 S 0 0.8 0:00.02 login
2141 xfs 20 0 5388 1776 884 S 0 0.8 0:00.05 xfs
2425 seebs 20 0 5392 1732 1480 S 0 0.8 0:00.08 bash
2371 seebs 20 0 5392 1728 1480 S 0 0.8 0:00.08 bash
1966 smmsp 20 0 10356 1576 696 S 0 0.7 0:00.00 sendmail
2221 avahi 20 0 3772 1520 1344 S 0 0.7 0:00.07 avahi-daemon
1751 root 20 0 11332 1348 588 S 0 0.6 0:00.43 pcscd
1796 root 20 0 29652 1304 1032 S 0 0.6 0:00.02 automount
|
一番大きなプログラムが yum-updatesd なのは明らかです。yum-updatesd はおそらく、システムの yum アップデーターに関係するデーモンです。(ドット・コムの時代には、こうした深い洞察ができると、国中のどこへ行っても仕事があったものです。) 幸い、このプログラムも、ないと困るものではありません。必要になったら手動で yum を実行すればよいのです。
ランレベルを編集する
残念ながら、「yum-updatesd がないこと以外はランレベル 3 と同じである」ようなランレベルはありません。これはつまり、いよいよ手動でサービスを削除しなければならない時が来た、ということです。そのための方法はいくつかあります。各ランレベルは、そのランレベルに対応する、/etc/rc.d の中の rcN.d という名前のディレクトリーによって定義されます。例えば、ランレベル 3 は /etc/rc.d/rc3.d の中のファイルによって定義されます。(Fedora 7 のシステムでは、これらのディレクトリーへのシンボリック・リンクも /etc の中にありますが、フルパスを使用した方が習慣としては適切です。)
そうした各ディレクトリーには、多少暗号じみた名前の「K74nscd」や「S88nasd」といったファイルがいくつか含まれています。この命名規則は単純です。K で始まる名前は、(大きな数字のランレベルから) このランレベルに入る際に停止する必要のある (それまで使用されていた可能性がある) サービスであり、また S で始まる名前は、このランレベルに入る際に起動する必要のあるサービスです。2 桁の数字はサービスをソートするために使われています。S13rpcbind は S14nfslock よりも前に起動され、そして S14nfslock は S25netfs よりも前に起動されます。単純であり、かつ効果的です。
実際には、これらは通常はファイルではなく、/etc/rc.d/init.d に保存されているスクリプトへのシンボリック・リンクです。通常、対象のサービスを起動、あるいは停止できる 1 つのスクリプトがあり、そして次にそのスクリプトへのリンクが適切に作成されます。init はレベルを変更すると、指定されたとおりに「start」あるいは「stop」という引数を付けてそのスクリプトを呼び出します。
もし皆さんが手っ取り早くサービスを削除したい場合には、必要のない S リンクあるいは K リンクを単純にランレベルのディレクトリーから削除します。同様にして、新しいリンクを追加することもできます。もう 1 つの選択肢は chkconfig ユーティリティーを使う方法です。chkconfig は、これらのシンボリック・リンクを維持管理してくれる非常に柔軟で強力なユーティリティーです。ただし注意点として、もし非常に重要なシンボリック・リンクを削除してしまうと、システムを再度ブートできるようになるためには、何らかのレスキュー CD (例えば Fedora のインストール・ディスクなど。「参考文献」を参照) を使う羽目になるかもしれません。何がどうなっているのか、そして削除しようとしているシンボリック・リンクに依存しているのは何か、を十分に理解してから、シンボリック・リンクの削除を行ってください。
一例として、ランレベル 2 から yum-updatesd プログラムを削除したい場合には、単純にリンク /etc/rc.d/rc2.d/S97yum-updatesd を削除します。chkconfig を使ってランレベル 2 から削除したい場合には、コマンドは /sbin/chkconfig yum-updatesd off のようになります。
さらに空きメモリーを求める
chkconfig と top を使うと、大量にメモリーを使用しているプロセスを多数追跡することができ、それらが何を提供しているのかを明らかにした上で、必要なければそれらを削除することができます。では Python プロセスはどうかというと、Python サービスは見つかりませんが、ps コマンドを使うと、以下のようにさらに詳しく調べることができます。
リスト 5. Python を探り出す
$ ps ax | grep python
1825 ? S 0:00 python ./hpssd.py
|
起動スクリプト群に対して grep を実行すると、このプロセスが「HP Linux Imaging and Printing」を提供する hplip サービスの一部であることがわかります。これは HP の一部のプリンターやスキャナーを使う際には使われるかもしれませんが、それ以外の場合には必要ありません。そこで、まだこれをオフしていなければ、今ここでオフします。
きわめて典型的な専用の開発システムでは、最終的に使用されているメモリーの合計は、最初の 213,692KB から下がって 49,896KB でした。空きメモリーが 5,500KB から 169,296KB に増え、これはコンパイラーを実行するための空きメモリー容量としては大幅な改善です。この改善による違いは作業負荷によって異なります。バックグラウンドで実行される多くのデーモンは、いったんスワップ・アウトされるとスワップ・アウトされたままとなり、システムの応答性はこれらのデーモンがない場合とほとんど同程度になります。そして長期間で考えると、コンパイル時間のわずかな違いでも、それを合計すれば大きな時間の節約になります。
次回は、使用に適した X 環境を得る方法を説明します。
ご覧のとおり、不必要な、あるいは使用されていない機能をいくつか犠牲にする気になれば、大量のシステム・メモリーを節約することができ、コンパイラーを実行したりコードを開発したりするために十分なメモリーを得ることができます。しかし多くのユーザーにとっては、X を完全に失うことは代償が大きすぎるものです。このシリーズの次回、第 3 回の記事では、コンパイラーを実行する機能を失うことなく、簡単なグラフィック作業を行うための、使用に適した X 環境を得るために何をすればよいのかを説明します。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について | 
| | Peter Seebach は長年にわたってゲーム機を収集していますが、それらの上で Linux を実行するようになったのはごく最近です。これがテレビゲームもできる Linux マシンなのか、あるいは Linux も実行できるゲーム機なのか、彼はいまだにわからずにいます。 |
記事の評価
| 
