Richard Theis著

I5/OS IFS (統合ファイル・システム)は、堅固、スケーラブルで極めて安全かつ利用価値のあるファイル・システムです。パフォーマンスも高いのでしょうか。いいえと答えた方は、この記事を読んでください。あなたの思い込みを変えるようなIFSパフォーマンスのヒントをいくつかご紹介します。はいと答えた方も、この記事の後半でIFSパフォーマンスの調整に役立つあまり知られていないヒントをいくつか見つけることができるでしょう。

これは、IFSパフォーマンスの向上と調整のヒントを紹介した2部構成の第1部です。第1部では一般的なパフォーマンスとディレクトリーのパフォーマンスのヒントについて、第2部ではストリーム・ファイルのパフォーマンスのヒントについてご紹介します。全体として、両方の記事で説明するヒントは一般的なものから固有のものまであり、IFS操作における全体とアプリケーション固有のパフォーマンス両方の向上について説明しています。しかし、パフォーマンス・データに関する一般的な警告については、本記事最後の特記事項を参照してください。

IFSは10個の固有のファイル・システムで構成されていますが、一般的なIFSパフォーマンス事項となると通常、ルート(/)、QOpenSys、ユーザー定義ファイル・システム(UDFS)が伴います。その結果、第2部と本記事を含む今後の記事ではヒントと「ファイル・システム」という用語はこれら3種類のファイル・システムに適用されます。

一般的なパフォーマンス向上のためのヒント

ファイル・システムの全体的なパフォーマンスと恐らくはシステム全体のパフォーマンスを向上させるには、以下の一般的なヒントが第一歩として最適でしょう。

1. UDFSとASPを使用する
UDFSは、同じ基礎となる物理ファイル・システム・アーキテクチャーの上に構築されているという点でルート・ファイル・システムおよびQOpenSysファイル・システムと似ています。事実、両者は非常に似ているため多くのユーザーがUDFSについて、UDFSの実行内容、またはUDFSの使用理由などを正確に把握していません。このため、いくつかの重要な固有機能を備えているにもかかわらず、UDFSの使用率は一般的に低くなっています。まず、ユーザーが自分の好みに応じて作成したり、ほとんどどこにでもマウントできるためより高い柔軟性と制御を提供しています。また、ユーザーおよびASP (補助記憶域プール)両方のストリーム・ファイルおよびディレクトリーにアクセスする唯一の方法でもあります。最も重要な点は、UDFSにはパフォーマンス上の利点があるということです。

UDFSの使用率が低くなっている結果、ファイル・システムのユーザー・データがシステムASP (ASP 1番など)のルート・ファイル・システムに存在することが多いのです。さらに、オペレーティング・システム・データもほとんどがシステムASPにあります。このデータすべてを単一のASPに置くことは、ユーザー・データとシステム・データ間のディスク・ドライブ競合が発生しやすいことを意味しており、その結果、通常、システム全体のパフォーマンスが低下します。
通常ディスク・ドライブの競合は、複数のジョブがデータを同時に読み書きするときに発生します。競合が発生すると、ディスクが他の要求でビジー状態になるため、データの読み書きができるようになるまで、1つ以上のジョブが待たなければなりません。例えば、システム・データの書き込みとユーザー・データの読み取りでディスクがビジーの場合、待たなければなりません。通常、待機は短時間ですが、短時間の待機でも多数集まるとシステム全体のパフォーマンスに悪影響を及ぼします。

使用率の高いデータをシステムASP (1)ではなく、ASP (2-255)のUDFSに移動することで、ASPのディスク・ドライブがデータ専用になり、パフォーマンスを改善します。また、他のオペレーティング・システム・アクティビティーがディスク・ドライブを競合することがなく、ファイル・システムとシステムの一般的なパフォーマンスを改善します。

UDFSパフォーマンスの利点を利用するには、ASP (2-255)を追加してシステムをセット・アップする必要があります。セット・アップ後は、UDFSでの作業は単純です。まずUDFSを作成し、それをマウントするのです。UDFSのマウント後(IPLするたびに再マウントが必要)、UDFSのデータで標準IFS操作を行うことができます。また、ユーザーがそのデータを操作しないようUDFSをアンマウントすることもできます。UDFSの作成、マウント、およびアンマウントはすべてiSeriesナビゲーター、またはCRTUDFS (Create User-Defined File System)、MOUNT (Add Mounted File System)、およびUNMOUNT (Remove Mounted File System) CLコマンドで行うことができます。

例えば、図 1では、/dev/QASP02ディレクトリーにUDFS (example.udfs)を作成してあります。これによりUDFSデータがASP 2に置かれます。Where Mountedプロパティーは、UDFSが/fooディレクトリーにマウントされていることを示します。これは、/fooディレクトリーまたはそのサブツリー内のオブジェクト上で実行されたIFS操作は、実際はASP 2のUDFSのオブジェクト上で行われていることを意味します。

UDFS (ナビゲーション・バーでFiles and file systems|Integrated file system|Work with file systems|User-defined file systemsの順にクリック)およびASP (Systems management|Disk management|Disk management concepts|Disk poolsの順にクリック)の詳細については、V5R3 iSeries Information Center (publib.boulder.ibm.com/html/as400/infocenter.html)をご覧ください。

2. ファイル・システム・オブジェクトの競合を最小限に抑える
ファイル・システム・オブジェクトの競合は、2つ以上のスレッドまたはジョブが同じ内部ファイル・システム・リソースに同時に要求を出すときに発生します。複数のスレッドが同じファイル・システム・データを同時に操作する場合というのが共通のシナリオになります。以下の例で、オブジェクト競合の理解を深めることができるはずです。

図 2では、/Buildディレクトリーがマルチスレッド・アプリケーションで使用されているものとしています。アプリケーションの各スレッドが/Buildディレクトリー内のそのストリーム・ファイル・セットを素早く作成、書き込み、クローズ、および削除し、顧客情報のデータベースを素早く構築します。この設計の結果、/Buildディレクトリーでオブジェクト競合が発生します。ストリーム・ファイルの作成および削除時に競合が発生します。これらの操作では、リンク更新を行うために/Buildディレクトリーの同じ内部ファイル・システム・リソースを必要とするためです。これらのリソースに競合が発生すると、リンク更新を実行する前にスレッドの順番待ちが発生します。このボトルネックの結果、アプリケーションのパフォーマンスが低下します。

図 2の/BuildBetterディレクトリーの設計の方が優れています。この設計では各スレッドは、/BuildBetterディレクトリー下の/ThreadXという自らのディレクトリーで動作します。この設計により、スレッドは共通の親ディレクトリーのリソースを競合することなく、オブジェクト競合をなくし、ボトルネックを改善して、アプリケーションのパフォーマンスを向上させます。

パフォーマンス・テストの結果、/BuildBetterディレクトリー設計によりオブジェクト競合をなくすことで、例にあるアプリケーションのパフォーマンスが平均で約23パーセント向上したことがわかりました。パフォーマンス・テストはそれぞれ、1,000個のストリーム・ファイルの作成、書き込み(16 KBデータ)、クローズ、および削除を行う5つのスレッドで構成されていました。オブジェクト競合テストでは、スレッドはすべて/Buildという同じディレクトリーで動作していました。競合なしテストでは、スレッドはそれぞれ/BuildBetter下の自分のディレクトリーで動作していました。

オブジェクト競合を最小限に抑えるための第一歩は、ファイル・システム・データの使われ方を分析することです。(複数スレッドがストリーム・ファイル内の同じバイトを同時に読み書きしていたり、複数スレッドが同時に同じディレクトリー内のリンクを追加、削除、または名前を変更しているなど)複数スレッドが同時に動作できるデータがある場合、オブジェクト競合が発生する確率は高くなります。 競合を最小限に抑えることは、それを発見するより多少困難なことです。土台となる修正は、スレッドが同じファイル・システム・データを同時に操作しないようにすることです。しかし、言うは易し、行うは難しです。問題解決には、前述の例のようにファイル・システム・データを多少再構築しなければならない場合もあります。アプリケーションを変更しなければならないケースもあるでしょう。しかし全体としては、ファイル・システム・オブジェクトの競合を最小限に抑えることはパフォーマンス改善に不可欠なステップです。

3. ユーザー・ジャーナリングと監査のパフォーマンスを合理化する
ファイル・システムのユーザー・ジャーナリングと監査は、しばしば行うべき重要な機能です。しかし、これらの機能に関わるオーバーヘッドはファイル・システムとシステムのパフォーマンスに影響を与えます。したがって、ユーザー・ジャーナリングと監査を合理化することは重要です。一般的に、ユーザー・ジャーナリングと監査に必要なものを減らし、ユーザー・ジャーナリング全体のパフォーマンスを改善することでこれを行うことができます。

ユーザー・ジャーナリングのパフォーマンスを改善するために、STRJRN (Start Journal)コマンドのopen、close、およびfsyncジャーナル・エントリー[OMTJRNE(*OPNCLOSYN)など]を省略できます。これらのエントリーはオブジェクトのリカバリーのほとんど必要ないためです。また、new objects inherit journaling属性をYesに設定するときに注意してください。これは、著しく多数のオブジェクトが同じジャーナルにジャーナリングされ、ディスク・ドライブ競合の原因となる可能性があるためです。また、ディスク・ドライブ競合を減らすために、ジャーナル・レシーバーを自ASPに分離する必要があります。

監査については、対象操作のみ監査されていることを確認します。すべてを監査するとエントリー数の増大と多量のオーバーヘッドが発生します。

これら固有のヒントをインプリメントすると、パフォーマンスが改善されるはずです。しかし注意してください。システムのユーザー・ジャーナリングと監査を高可用性(HA)とセキュリティー要件を満たさなくなるところまで減らさないようにしてください。

一般的なユーザー・ジャーナリング・パフォーマンス(Systems management|Journal management| Local journal management|Journal management concepts|Journal management and system performanceの順にクリック)および監査(Systems management|System values| System value categories|Auditingの順にクリック)の詳細については、V5R3 iSeries Information Centerをご覧ください。

4. 保存およびリストアのパフォーマンスを合理化する
ファイル・システムがより多くのデータを保持するにつれて、データの保存およびリストア(S/R)パフォーマンスが重要になります。結果として、IBMエンジニアはファイル・システムのS/Rパフォーマンスが増え続けるデータ量に対応できるよう一所懸命取り組んできました。まず、ファイル・システムS/Rパフォーマンスの妥当な期待値を設定するために、V5R2 and V5R3 iSeries Performance Capabilities Reference （http://www-03.ibm.com/servers/eserver/iseries/perfmgmt/resource.html）の第15章を参照してください。これらの参考マニュアルにより幅広いファイル・システムS/Rパフォーマンス・データが提供されます。

パフォーマンスがマニュアルに記載されたパフォーマンス値より低くなった場合、改善の余地があるということでしょう。まず、*TYPE2ディレクトリーを使用し(これについては記事の後半で詳細に説明します)、S/R中の監査とスキャンを最小限に抑えるかなくすことから始めます。さらに、V5R3 iSeries Information CenterのIFSバックアップ経験レポートに詳細を記載したファイル・システムS/Rパフォーマンスの(Files and file systems|Integrated file system|Related information|Experience reports|Backing up the Integrated File Systemの順にクリック)にも従う必要があります。これらのヒントのいずれも期待する結果を生み出さない場合、より高速なハードウェア(ディスク・ドライブまたは磁気テープ装置など)が必要かもしれません。

ディレクトリー・パフォーマンス向上のヒント

ディレクトリー・オブジェクトはファイル・システムをまとめるための接着剤のようなものです。結果として、ほとんどすべてのファイル・システム操作では操作中に1つ以上のディレクトリーの読み取りまたは更新をしなければなりません。このため、ディレクトリー・パフォーマンスはファイル・システム・パフォーマンス問題の重要な部分になっています。以下のヒントは、ファイル・システム全体のパフォーマンスを上げるための最適な出発点です。

1. *TYPE2ディレクトリーを使用する
*TYPE2ディレクトリーは、ルート、QOpenSys、およびユーザー定義各ファイル・システムの*TYPE1ディレクトリー・オブジェクトの内部を再設計した結果です。新しい*TYPE2ディレクトリー設計は、*TYPE1先行ディレクトリーの信頼性とパフォーマンスを向上させるために最適化されています。*TYPE2ディレクトリーはほとんど全体に渡って*TYPE1ディレクトリーよりパフォーマンスが優れています。*TYPE1ディレクトリーに対する*TYPE2ディレクトリーのパフォーマンス改善のいくつかを以下に示します。

・ ディレクトリーの作成: 最大12から13倍高速
・ ディレクトリーの削除: 最大3から4倍高速
・ ディレクトリーの読み取り: 最大4倍高速
・ ディレクトリーのオープン: 最大2倍高速
・ レクラメーション処理: 最大1.5から2倍高速
・ S/R: 最大2倍高速
・ ファイルのオープン: 最大1.5倍高速

システムが*TYPE2ディレクトリーを使用していない場合、ファイル・システムの変換を検討する必要があります。V5R1で変換する場合、まずQP0FCVT2 (Convert Directory) APIを使用してシステムが*TYPE2ディレクトリーを使用しているかどうか判断します。V5R2およびV5R3では、CVTDIR (Convert Directory)コマンドを使用してこのチェックを行います。V5R2やV5R3に適切なコマンドを実行してください。

CALL PGM(QP0FCVT2) PARM(*LIST)
CVTDIR OPTION(*CHECK)

図 3にコマンド出力の様子を示します。1つ以上のファイル・システムが*TYPE2ディレクトリーを使用していない場合、変換するのがよいでしょう。V5R1では、QP0FCVT2 APIを使用して変換を行います。V5R2ではCVTDIRコマンドを使用します。V5R3では、オペレーティング・システムが変換を処理します。

*TYPE2ディレクトリーおよびディレクトリーの変換の詳細については、iSeries Information Center (V5R3: Files and file systems|Integrated file system|Convert directories from *TYPE1 to *TYPE2. V5R2: File systems and management|Integrated file system|Concepts|Directory|*TYPE2 directories. V5R1: Database and file systems|File systems and management |Concepts|Integrated file system concepts|*TYPE2 directoriesの順にクリック)をご覧ください。

2. 短いリンク名およびパス名を使用する
ディレクトリー・オブジェクトはリンクを接着剤としてファイル・システムをまとめます。単一のディレクトリー内でリンク同士識別するために、リンクにはそれぞれ名前が指定されています(「リンク名」はファイル名とも呼ばれることがあります)。結果的に、少なくとも1つのリンク、つまり1つのリンク名がすべてのファイル・システム・オブジェクトに存在することになります。

ファイル・システムのリンク名は、パス名構築のため組み合わされているため、非常に重要で、パス名はオブジェクトの識別と場所を見つけるために使用されます。例えば、ストリーム・ファイルがディレクトリー/home/fredにある場合、/home/fredディレクトリーからストリーム・ファイルへのリンクが存在します。このリンクの名前をfooとしましょう。このストリーム・ファイルにアクセスするには、/home/fred/fooなどそのファイルへのパス名を構築する必要があるでしょう。図 4 にこの例を図示します。

現在リンク名は16文字以内、パス名は20文字以内なら短いとされています。短いリンク名とパス名を使用する場合、パス名解決のパフォーマンスを15パーセントほど改善できる内部ファイル・システム・キャッシュ・メカニズムをいくつか利用できます。長いリンク名とパス名はこれらのキャッシュを利用できません。

さらに、24文字を超えるリンク名を使用する場合、ディレクトリー・オブジェクトも余分なストレージ・プールを作成および管理する必要があります。これにより、ディレクトリー・オブジェクトが消費するストレージ量が増え、パス名解決中に別のページ・フォールトを発生させる可能性があります。その結果、ファイル・システム全体のパフォーマンスが低下します。一般的に、短いリンク名とパス名はファイル・システムのパフォーマンス改善に寄与します。

3. カレント作業ディレクトリーを使用し、層が深いサブツリーを避ける
カレント作業ディレクトリー(CWD)はオペレーティング・システムがキャッシュに入れるディレクトリーです。デフォルトでシステムにサインオンする場合、ユーザー・プロファイルのホーム・ディレクトリーをCWDとして使用します。相対パス名(MyDir/MyFileなど斜線文字のないパス名)を使用する場合は必ず、CWDはオペレーティング・システムがパス名解決を開始する最初のディレクトリーになります。CWDの概念は現行ライブラリーの考えに似ており、現行ライブラリーのように必要に応じてCWDを変更および表示できます。CWDを変更および表示するには、それぞれCHGCURDIR (Change Current Directory)コマンドとDSPCURDIR (Display Current Directory)コマンドを使用します。2個の対応するAPI、chdir()とgetcwd()が存在するので、それらも使用できます。

どのジョブやプロセスにも、効率的に使用した場合にパス名解決を早めるCWDがあります。例えば、図 5では/Level1/Level2/Level3/ Level4/Level5/Level6/Level7という完全修飾パス名を持つ/Level7ディレクトリーを考慮しています。ジョブがディレクトリー/Level7で多数のストリーム・ファイルを作成する必要がある場合、ストリーム・ファイル作成前に/Level1/Level2/Level3/Level4 /Level5/Level6/Level7をジョブのCWDに設定するのがよいでしょう。これにより、ストリーム・ファイル作成時に相対パス名(Stmf1など)を使用できます。ストリーム・ファイル作成時に完全修飾パス名(/Level1/Level2/Level3/Level4/Level5/Level6/ Level7/Stmf1など)を使用する場合、作成ごとにシステムは、ディレクトリー/Level7の完全修飾パス名を解決する必要があります。

過度なパス名解決は、パス名解決中にシステムは多数のステップを処理するために多くの余分なオーバーヘッドが発生します。ユーザーにパス名のすべてのディレクトリーに実行(*X)権限があり、すべてのディレクトリーの監査レコードをデポジットし、シンボリック・リンクを解決することを確認してください。このオーバーヘッドを軽減することで、特に、システムが多数のパス名解決を行っている場合に著しくパフォーマンスが改善するでしょう。例えば、前記の例を使用したパフォーマンス・テストは、/Level1/Level2/Level3/Level4/Level5/Level6/Level7/Stmf1ストリーム・ファイルの情報を(stat() APIで)取得する、または(open() APIで)オープンする場合にCWDを使用すると平均して、完全修飾パス名を使用するより約3倍から4倍高速になることを示しています。

すべてのパス名解決でCWDを使用するのは不可能でしょう。そのような場合は、できるだけディレクトリーのサブツリーを浅くするほうがよいでしょう。浅いサブツリーに対して深いディレクトリー・サブツリーになる正確な数はありません。したがって、(100レベルなど)あまり深くもなく、(同じディレクトリーにすべてのファイル・システム・オブジェクトがあるなど)浅くもない、バランスのとれたサブツリーを維持するのが最適です。結局、パス名解決を最小限に抑えるようなバランスよく編成されたファイル・システムがファイル・システム・パフォーマンスを向上させます。CWDの詳細についてはV5R3 iSeries Information Center(Files and file systems|Integrated file system|Concepts|Directoryの順にクリック)をご覧ください。

ヒント

これらのIFSパフォーマンス改善と調整のヒントをトレーニングしてください。他人よりあなたの置かれた状況に役立つようなヒントもあるはずです。あなたにとって最適なヒントを判断するために、パフォーマンス問題の分析とアプリケーションによるIFSデータの処理方法の分析が最適なアイデアである理由はそこにあります。少しの改善しかもたらさないヒントを見逃さないでください。多くの小さな改善が積み重なって、あなたの求めるパフォーマンス全体の向上につながるからです。

Richard Theis: IBMロチェスター研究所のファイル・システム部門のソフトウェア・エンジニア