Dave Boutcher, Erwin Earley, Larry Loen 著

LinuxはiSeriesシステム上で簡単に実行させることができます。プロセッサーの10分の1、64 MBのメモリー、そしてLinuxをインストールするに足る十分なディスク・スペース―これが必要となる最低限のリソースです。実際にシステムでLinuxを実行させてどうなるか見てみたいというのであれば、これで十分なのです。ただし、Linuxをお使いの環境の機能の一部として活用したいのであれば、これ以外のリソースも準備しなければなりません。実際、LinuxをiSeriesで使おうとすると、LinuxとOS/400の両方に対してパフォーマンスに関する考慮事項が数多く発生します。この記事ではこれらパフォーマンスの考慮事項を追求すると同時に、Linuxの導入に際してiSeriesの構成やチューニングをどのようにすればよいかについての指針を明らかにしたいと思います。

ディストリビューション

まず最初に考慮しなければならないことのひとつに、どのLinuxディストリビューションをインストールするべきか、ということが挙げられます。IBMはRedHat, SuSEおよびTurboLinuxと共同でiSeriesをサポートするLinuxディストリビューションを作り上げてきました。これら3つのディストリビューションはすべて新しいバージョンが頻繁にリリースされています。詳細については、iSeriesのウェブ・サイト上にあるLinuxのページ、http://www.ibm.com/iSeries/linux （英語サイト）にアクセスして「Distribution」リンクをクリックしてみてください。

一般的に、これらディストリビューション間に著しいパフォーマンスの違いはありません。が、PowerPC向けの64ビット・カーネルが既にSuSEから発売されており（詳細はhttp://www.suse.com/us/products/suse_business/sles/sles_iSeries_pSeries/index.html（英語サイト）をご覧ください）、他のディストリビューションは本年中にその他のLinuxメーカーから発売される予定になっています。これにより、ディストリビューションの性能が向上する可能性もあります（アプリケーションによっては、特に512 MBを越えるメイン・ストアを必要とするアプリケーションでは、32ビット・カーネルより64ビット・カーネルの方が速い場合があります）。

カーネル

Linuxが最初にiSeriesで使用できるようになったときは、既存のLinux PowerPCサポートのごく1部分を変更したものでした。その当時、PowerPC向けの唯一のLinuxインプリメンテーションが32ビットだったのです。現在では、iSeriesシステムとpSeriesシステムの両方に64ビットPowerPCプロセッサーが搭載されているため、IBMは、PowerPC 向けにLinuxの64ビットをインプリメントできるよう積極的に努力してきました。ソース・コードも含め、この企画に関する詳細についてはhttp://linuxppc64.org（英語サイト）をご覧ください。

64ビットに対するサポート提供は、2つの段階をへて行われます。最初の段階とは、既存の32ビット・アプリケーションでも稼動する64ビット・カーネルを提供することです。

このことは、Linuxの側から見れば、既存の任意の32ビットのLinuxディストリビューションをインストールした後でも、カーネルを64ビット・カーネルに置き換えることができる、ということを意味します。32ビットPowerPCアプリケーションとしてコンパイルされているすべてのアプリケーション（「ソリテア」ゲームのプログラムからApache Webサーバーに至るまでのすべて）は、変更する必要もなくそのまま継続して稼動されるわけです。今年の終わりまでには、完全な64ビット環境（カーネルおよびアプリケーション）が提供される予定です。

64ビット環境が提供する最大の利点は、改良されたメモリー・アクセスです。32ビット・カーネルがうまく機能するメモリーは、わずか512 MBまでです。これを越えるメモリーもLinux “Highmen”サポートを使えば活用できないことはありませんが、最初の512 MBを越えてメモリーにアクセスすると速度が落ちてしまいます。メモリーに大きく依存しないアプリケーションの場合、32ビット・カーネルだろうと64ビット・カーネルだろうとパフォーマンスに大差がないのが実情です。

プロセッサー

長い間、iSeriesは著しく堅固でスケーラブルなI/Oインフラストラクチャーに依存してコマーシャル・ワークロードを提供してきました。ところが、Linuxアプリケーションの多くが、I/Oインフラストラクチャーではなくプロセッサーにより制限を受けているのです。頻繁なコンパイルを必要とするグラフィック・アプリケーションや開発環境などがその良い例でしょう。

純粋なCPU制約のアプリケーションについては、iSeries PowerPCプロセッサーのパフォーマンスは、同等の速度（MHz）を持つPentium IIIプロセッサーのパフォーマンスに匹敵します。換言すれば、ある量のメモリーを持つ700 MHz Pentium IIIプロセッサーで実行されているアプリケーションは、同程度のメモリーを持つ700 MHz PowerPCプロセッサーで実行されてもほぼ同様のパフォーマンスを示すと言えます。どちらの環境においてもアプリケーションとLinuxオペレーティング・システムの両方におけるソース・コードの99.9%は同等のワークロードであることも忘れないでください。OS/400のコマーシャル・ワークロードにおいて速度（MHz）はそれほど重要ではありませんが、Linuxにとっては重要なのです。

プロセッサーの部分的な共有

iSeries Linuxのインプリメンテーションによって、ハイパーバイザー（iSeriesのハードウェアの区画化を可能にするソフトウェア）が区画間でプロセッサーを共用できるようになります。ある論理区画が特定のプロセッサーの固定部分を所有し、別の区画がそれ以外の部分を1つまたは複数個所有するというのがその考え方です。こうすれば、複数の区画が単一プロセッサーをさまざまな部分に分割でき、たとえば、3.9 CPUを1つの区画に、0.1 CPUを別の区画に割り当てるなどすれば、対称マルチプロセッサー（4waySMP）を分割できるようになります。Linuxを稼動することができるiSeriesのモデルや機構の中には、プロセッサーをLinuxと共有できる追加機能を持たないものもあります。

プロセッサーの部分的なパフォーマンスは、計算で求められる値と大差ありません。600 MHzのプロセッサーの半分（0.5）のパフォーマンスは300 MHzのプロセッサーのパフォーマンスと等しいことになるわけです。プロセッサーの共有を行えば、いくらかのオーバーヘッドはありますが、利用できる処理能力全体の10％を大きく下回るはずです。

最近、筆者たちは、10個のプロセッサーを8個のLinux区画で共有するテスト環境を設置しました。各Linux区画に1.25個の共有プロセッサーを割り振る方と、各区画ごとに1個の専用（共用でない）プロセッサーを搭載させる方のどちらが効果的かを見極めたかったのです。共用のオーバーヘッドのため、共有プロセッサー1.25個は専用プロセッサー1.0個とは同等でないことが判明しました。

ハードウェアのマルチタスキング

パフォーマンスに影響を及ぼすもう一つのiSeriesプロセッサーの機能がハードウェア・マルチタスキングです。システム値QPRCMLTTSKがこの機能を制御しますが、システム全体（すなわち全区画）に対してオンかオフのいずれかを指定しなければなりません。

ハードウェア・マルチタスキングにより、各CPUは通常の演算プロセッサーとメイン・ストアからの取り出しおよび取り込み機能を持つことになります。ただし、レジスター・セットは2つあります。これにより、オペレーティング・システムは2つの異なるジョブまたはスレッドをロードし、それぞれが同じ物理CPU内にある別個のレジスター・セットに入ることになります。一方のレジスター・セットで表わされるジョブが停止すると（通常はキャッシュ・ミスのため）、もう一方のレジスター・セットが引き継ぎ、最初の操作が完了するまで実行を続けます。ハードウェア制御によるこの「2点間の行き来」によって、アプリケーションのほとんどで今までにない卓越したスループットが実現されるようになります。

アプリケーションのすべてがハードウェア・マルチタスキングの恩恵に浴せるとは限らないため、システムではこの機能のオンとオフを制御できるようになっています。モデルや機構の中には、ハードウェア・マルチタスキングの機能を使用可能にした状態では、Linuxのようなゲスト・オペレーティング・システムを実行できないものもあります。

Linuxへの効果は、ハイパーバイザーが実プロセッサー1つ1つに対して2個の仮想プロセッサーを提供することにあります。例外的に一部のアプリケーションには全く効果がない場合もありますが、QPRCMLTTSKをオンに設定するとスループットが10〜25%アップするというのが典型的なケースです。

単一プロセッサーとSMP

最終的に、Linuxカーネルは単一プロセッサー・モードまたはSMPモードのいずれにも組み込むことができます。これは、カーネルが構築される時点で区別されます。単一プロセッサー・モードだと、Linuxは（想像どおりだと思いますが）プロセッサーを1つしか使用しません。SMPモードにあるLinuxは複数のタスクを同時に実行します。

現行のディストリビューションはすべてSMPカーネルで出荷していますが、単一プロセッサー・カーネルの方がSMPカーネルより優れたパフォーマンスを示したという状況は一例も見ていません。ただし、状況によっては、プロセッサーのある部分で実行されている特定のアプリケーションが、単一プロセッサー・カーネルの方でより優れたパフォーマンスを示す可能性は充分にあります。

メモリー

現在ほとんどすべてのオペレーティング・システムにおいて、Linuxに割り振られるメモリー・サイズもプロセッサー容量と同程度にパフォーマンスに影響します。Linuxは最小64 MBでも稼動しますが、128 MBまたは256 MBの方がより効果的です。前述したように、32ビット・カーネルで良好な操作状況を得られる最大のメモリー・サイズは512 MBです。

Linuxは、仮想ディスクに対するメモリーの「スワッピング」や「ページング」をサポートします。この機能を使うには、Linuxがページングできるよう、Linuxのディスクに「スワップ・ディスク」、すなわち区画をセットアップしなければなりません。Linuxカーネルのメモリー管理アルゴリズムは、近年最も迅速に変化してきた領域のひとつとは言え、実メモリーの2倍のスワップ・スペースを割り振らなければならないという共通の経験則に変わりはありません。入手可能な3種類のiSeries Linuxディストリビューションのいずれも、メモリーのサイズにかかわらず一定のスワップ・ディスク・スペースをインストール中にセットアップします。

スワップ・スペース作成のために仮想ディスクを区画化するよりも、Linux仮想ディスクを別途に割り振ってスワップ・スペースを提供する方が簡単かもしれません。その理由のひとつは、スワップ・ディスクをバックアップ戦略に含む必要がないからです。またもうひとつの理由として、削除したり別のサイズに変更できる別途の仮想ディスクへの保管が可能になれば、必要に応じて簡単にスワップ・スペースのサイズを変更できるということが挙げられます。

十分なスワップ・スペースの重要性を示す例として、最近のユーザー会議のiSeries研究でLinuxを実行してみました。15グループに同時に1つのLinux区画にログオンさせ、Linuxのグラフィック・デスクトップ（多くのグラフィックやツールバーを搭載）を始動させてみたのです。残念ながら、12グループがデスクトップの始動を完了した時点で、Linuxはメモリーもメモリーの移動先であるスワップ・スペースも使い果たし、アプリケーションも好ましくない状態になり、正しく動作しなくなりました。（Linuxは、この例ではランダム・プロセスを選択し、それらを強制終了しています。）

メモリーに対するもうひとつの考慮事項とは、iSeries論理区画（LPAR）の構成に関するものです。各区画に対しては、現行のメモリー・サイズと割り振られるメモリーの最小および最大サイズを構成することができます。最小値や最大値への変更を有効にするには、システムIPLを実行しなければなりません。

区画内ではページ・テーブルが作成されて必要メモリーの最大サイズを処理します。最大値として非常に大きな値（たとえば2 GB）を設定すると、ページ・テーブルが区画のメモリーのうち相当量を消費してしまう可能性が出てきます。したがって、最大メモリー値を設定するときは、必要性と過度なメモリー消費の危険性の両方を考慮しなければなりません。

通信

通常、LinuxはLAN接続を介したTCP/IPを使って外界と通信します。iSeriesは、実LANカード（10/100 Mbpsイーサネット、Gigabitイーサネットおよびトークンリング）を用いるLinuxと、区画同士を接続する仮想LAN上の区画間の通信を可能にした仮想LANカードを用いるLinuxの両方をサポートします。区画同士の通信には、仮想LANの方がより高いパフォーマンスを提供します。が、他システムとの通信には、通常、実LANカードの方がより優れたパフォーマンスを示します。

場合によっては、仮想LANと実LANを組み合わせて区画を他システムと接続するとよいでしょう。このような場合、最低でも1つの区画に実LANカードがなければならず、その区画が仮想LANから実LANへのTCP/IPトラフィックの経路を指定します。図1はLinux区画を外界に接続する代替方法を示すもので、1区画を経由して実LANカードとの経路を指定することもできれば、Linux区画のそれぞれに固有のLANカードを提供してもかまいません。

仮想LANと実LANを接続するブリッジング区画として、OS/400ではなくLinuxを使うこともできます。各区画に専用のLANカードさえあれば、通常の構成方法ははるかに簡単です。それ以外の代替方法ではより複雑なTCP/IP構成によって、区画間のトラフィックを正しく経路指定しなければならなくなります。

どの接続方法を使う場合でも、TCP/IPの「最大転送単位」（MTU）パラメーターを調整すればお使いの環境でのパフォーマンスを向上できるようになっています。仮想LANは最大9,000バイトまでのMTUサイズをサポートしています。ほとんどのイーサネット・ネットワークで使われているデフォルトは1,496バイトです。MTUを不適切に設定すると診断困難なネットワーク上の問題を生じる原因となりますが、場合によっては（仮想LAN上の2区画間でのデータ・フローを最大限にしたいときなど）、両端のMTUを最大値に設定することでスループットを増やすこともできます。

もうひとつの典型的な構成とは、Linuxをファイアウォールとして使用することです。図2では、Linuxファイアウォールは3つのLANセグメント―外部LANセグメント、内部LAN（たとえばオフィス向けLANなど）、およびLinuxをOS/400に接続する仮想LANセグメント―を接続しています。Linuxファイアウォールが、これらLANセグメント間のトラフィックを経路指定し、トラフィックを適切に制限しているのです。また、OS/400とLAN接続のPC （PC1など）の両方を外部LANに接続できるようにしています。

この例では、システムを内部LANに接続している2枚目のLANカードがOS/400に接続でき、PC1と外部LANとの間のトラフィックをOS/400とLinuxファイアウォールを介して経路指定することもできることに注目してください。ただし、この場合、各パケットには、OS/400によって仮想LANを介してファイアウォールへ1度、ファイアウォールそのものによって1度の計2度の経路指定が必要です。ここで示す構成のファイアウォールは、各パケットに対して正しい宛先を1度だけ経路指定すれば済みます。（一般的には、ビジネス・クリティカルなOS/400プログラムをパケットの経路指定のような日常的な作業には使わない方がよいでしょう。）

Linuxファイル・システムの考慮事項

Linux向けには複数のファイル・システムがあり、それぞれに利点やパフォーマンスに関する考慮事項があります。Linuxのバージョン別にどのファイル・システムがサポートされるかは、Linuxカーネルが構築（コンパイル）されたときに決定します。iSeriesディストリビューション上のLinuxは、“ext2”, “ext3”, “reiserfs”および“JFS”をサポートします。

ext2ファイル・システムが、ここ数年Linuxオペレーティング・システムで使用されている標準型です。最大4 TBのファイル・システム・サイズ、最大2 GBのファイル・サイズ、最大255文字までのファイル名サイズなどがその特徴です。ただし、ext2にはいくつか問題があり、特にシステム破損後の回復に時間がかかるという難点があります。ext3, reiserfsおよびジャーナル・ファイル・システム（JFS）の3つは比較的新しいファイル・システムで、ext2の問題を解決するために開発されました。これらのうちどれがLinuxのインストール時の有力ファイル・システムとなるかは、まだ分かりません。

システム管理者は、ファイル・システムを作成するときにブロック・サイズ・パラメーターを十分に考慮する必要があります。ブロック・サイズは、物理ディスクそれぞれの読み取り時に読み取られるバイト数を制御します。一般的なブロック・サイズは、248バイト、406バイト、1,024バイトのいずれかです。ブロック・サイズが大きくなると、ファイルにアクセスする入出力要求が少なくなる（したがって、ディスク・ヘッドの検索も少なくなる）ため、入出力の速度がアップします。ただし、Linuxは整数ブロックを使用するため（つまり、データの残量にかかわらずディスク・スペース・ブロックの全単位を割り振るため）、ブロック・サイズを大きくするとディスク・スペースを無駄にすることになってしまいます。

ext2ファイル・システムを使って操作されるLinuxツールがいくつか用意されています。tune2fs（システム・ファイル・パラメーターの変更に使用）、e2fsck（ファイル・システム・チェッカー）、debugfs（ファイル・システム・デバッガー）などがその例です。

前述したように、ext3ファイル・システムは、ext2ファイル・システムの拡張セットです。ext3ファイル・システムには、可用性、データの完全性、速度などext2ファイル・システムを上回る利点があります。主な改善点のひとつが、原因不明のシステム遮断が発生すると、ファイル・システム・チェック（e2fsck）が完了しない限りext2ファイル・システムはマウントされない、という点です。e2fsckプログラムが費やす時間は、主にファイル・システムのサイズで決まりますが、今日のように比較的大きなファイル・システムが使われていれば、費やされる時間も相当なものになるはずです。

一方、ext3ファイル・システムはファイル・システム・チェックを必要としません。つまり、原因不明のシステム遮断が発生した後にext3ファイル・システムが回復に費やす時間は、物理ディスク・リソースのサイズではなく、整合性の維持のために使われるジャーナルのサイズによることを意味します。

reiserfsファイル・システムは、Linuxで使用できるもうひとつのジャーナリング・ファイル・システムです。reiserfsには、迅速なジャーナル処理、多数のファイルを管理するより優れたアルゴリズム、ディスク・スペースのより効率的な使用など、強力な機能が搭載されています。

ディスク

iSeries LPARで実行するLinuxは、ネイティブのDASDデバイスへのアクセスはもちろん、OS/400で維持され制御されるディスク・リソースへの仮想アクセスもサポートします。ネイティブのDASDデバイスと稼動するように構成されたLinuxは、ディスク・デバイスに直接アクセスするため、OS/400のシステム呼び出しの介入を受けることはありません。

仮想ディスク・リソースと稼動するように構成されると、統合ファイルシステム（IFS）内のファイルは、Linuxに物理ディスク・リソースを示すために使われます。仮想ディスク・リソースへは、仮想入出力ハードウェア抽出を介してアクセスされます。

通常、仮想ディスクの管理はネイティブ・ディスクの管理よりも簡単です。仮想ディスクがあれば、管理者は、OS/400コマンドを使ってディスクを作成したり削除したりできます。同様に、仮想ディスクのバックアップや回復もOS/400経由で実行されます。ネイティブ・ディスクだと、Linuxで使用できるディスク・スペースの量は、入出力アダプターやディスクの物理的な構成によって決定し、バックアップや回復を含むそのスペースの管理はすべてLinux経由で実行しなければならなくなります。

仮想ディスクがあれば、OS/400がディスク装置にあるデータの実際のストレージを管理します。これにより、LinuxはOS/400の機能を利用してさまざまなディスク・ドライブを介した操作を展開できるようになります。OS/400に多数のディスク・ドライブ（たとえば10台以上）があるシステムでは、仮想入出力を使うとネイティブ・ディスクをはるかに上回るすばらしいパフォーマンスが得られるはずです。仮想ディスクの操作が、システムに分散するあらゆるディスクに展開されるからです。OS/400で使用するディスク・ドライブが少ない場合、この利点はなくなり、ネイティブ・ディスクから得られるパフォーマンスの方が高くなります。

OS/400への影響

OS/400がLinuxの活動によって影響を受ける領域は、仮想LANを使った通信と仮想ディスクの2つです。OS/400が仮想LANを実LANに接続するルーターとして稼動している場合、OS/400はLinuxから送信される各パケットを調べ、適切な経路を指定しなければなりません。このオーバーヘッドは、TCP/IP関連活動など、他の低レベル活動と同じパフォーマンス・リポートで紹介されることになっています。

仮想ディスクの操作は、OS/400のパフォーマンスにわずかに影響します。OS/400は、仮想ディスクへのアクセスをそれ以外の単一レベルのストア・オブジェクトへのアクセスと同様に扱うため、仮想ディスクは、Linuxがデータにアクセスする前にメモリーにページングされなければなりません。仮想ディスクへのアクセスに使われるメモリーは、マシン・プールから確保される必要があります。パフォーマンス・リポートでは、仮想ディスクの活動は、“VIOD”で始まるタイトルのタスクで紹介されています。

その他のリソース

Linuxでの作業を始めてみると、Linuxの問題を解決するにはピア・サポートが必要であると直ちに痛感されることでしょう。Linuxを使って仕事をしている人たちは、ウェブを検索したり、ニュース・グループやメーリング・リストに参加したりして答を得ようとしているのです。iSeries Linux利用者のメーリング・リストに参加したい方は、http://lists.linuxppc.org （英語サイト）にアクセスしてみてください。パフォーマンスの問題に悩んでいたり、さまざまな体験を同じ境遇の人たちと分かち合いたいと思う皆さんのご参加をお待ちしています。

著者の紹介

David Boutcherは、IBM Rochester開発研究所のiSeries Linux開発に従事する技術者です。
Erwin Earleyは、IBM Rochester開発研究所でiSeries Linuxに従事するソフトウェア・エンジニアです。
Larry Loenは、IBM Rochester開発研究所でiSeriesでのLinuxパフォーマンスを研究するシニア・プログラマーです。