PlayStation 3 での Linux 開発: 第 2 回 メモリーを有効に利用する

PS3 Linux でメモリーを大量消費する部分を特定する

ソニーの PlayStation 3 (PS3) は Linux® を実行することができます。しかし Linux を適切に実行させるためには少し調整が必要です。このシリーズの 2 回目である今回は Peter Seebach が、メモリーは一体どこに使われているのかを調べ、そうしたメモリーを有効に利用する方法について説明します。

Peter Seebach, Freelance author, Plethora.net

Peter SeebachPeter Seebach は長年にわたってゲーム機を収集していますが、それらの上で Linux を実行するようになったのはごく最近です。これがテレビゲームもできる Linux マシンなのか、あるいは Linux も実行できるゲーム機なのか、彼はいまだにわからずにいます。



2008年 3月 31日

このシリーズの第 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. デフォルトのランレベル
		 id:5:initdefault:

実際には、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 のようになります。

さらに空きメモリーを求める

chkconfigtop を使うと、大量にメモリーを使用しているプロセスを多数追跡することができ、それらが何を提供しているのかを明らかにした上で、必要なければそれらを削除することができます。では 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 環境を得るために何をすればよいのかを説明します。

参考文献

学ぶために

製品や技術を入手するために

  • developerWorks から直接ダウンロードできる IBM trial software を利用して皆さんの次期 Linux プロジェクトを構築してください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux, Open source, Multicore acceleration
ArticleID=305754
ArticleTitle=PlayStation 3 での Linux 開発: 第 2 回 メモリーを有効に利用する
publish-date=03312008