System iを愛するすべての人のためのコミュニティサイト

OS/400(i5/OS、i/OS)を運用する上で定期的なヘルスチェックはかかせません。

2005年にi Magazine 誌に掲載いただいた記事の転載です(許可取得済み)。内容的には今もあまり変わらないと思いますので、運用管理に携わる方には役に立つかも。なお、一部リンク切れしてますがご容赦を。

.

------------------ 以下転載 ------------------

OS/400のヘルス・チェック

OS/400は自らを自律的に最適化するように設計されており、OSそのものの運用においてユーザーの関与が必要な部分は他のプラットフォームと比較して非常に少ない。ここではより安全かつ効率的にシステムを運用するために、日常運用の中で一度はチェックすべきものについていくつかピックアップして解説する。

V5におけるパフォーマンス・データの収集と評価

OS/400のパフォーマンスの良し悪しを判断する際、対話型ジョブの場合は平均対話型応答時間(通常2～3秒以内)、バッチジョブの場合はジョブの実行時間(例えば夜間バッチが朝までに完了するか)が基準とされることが多い。

パフォーマンスに問題がある(目標値を満たさない)と判断された場合、次のステップはシステム資源の使用率を測定することである。OS/400の主要なシステム資源としてCPU、メモリー、ディスクがあり、これらがバランスよく構成されている必要がある。いずれかの資源にボトルネックが発生していると、他の資源に余裕があってもパフォーマンス(スループット：仕事量)が低下する。システム資源の使用状況を判断する際にもっとも良く利用されるのはWRKSYSSTSコマンドおよびWRKDSKSTSコマンドであるが、より詳細かつ継続的なパフォーマンス分析には収集サービスと、マネージメント・セントラルの「モニター」またはパフォーマンス・ツールが使用される。

システム資源の充足度を判断する最も簡便な方法は、IBMより提供されている各種ガイドライン(推奨値)と、評価対象システムのシステム資源使用率を比較することである。V5R3における性能調整を行う上でのハイレベルのガイドラインは例えば「iSeries パフォーマンス バージョン5リリース3」のページ24などに記載されている。以下のガイドラインはOS/400 V5を使用している場合の一般的な環境における推奨値であり、将来の能力計画立案やより詳細な分析を行う前段階における、あくまでも「目安」としてご理解いただきたい。

• CPU
  • システム全体のCPU使用率が頻繁に継続して90%を超えるようであれば、CPU資源が不足している可能性がある。(前述の「iSeries パフォーマンス」参照)
  • 対話型CPU使用率が対話型フィーチャーの70%を超えると、対話型応答時間が悪化する可能性が高くなる。(後述の「Performance Update」参照) 
     
• メモリー
  • マシンプールの非データベース不在は10未満が望ましい。これを超えるとシステム全体のパフォーマンスが低下する場合がある。(「iSeries パフォーマンス」参照)
  • V5ではユーザープールに関する一意的な指標は提供されていない。多少手順は複雑(メモリープールごとに計算が必要)であるが、後述の「Performance Update」や「Performance Capabilities Reference」を使用すべきであろう。なお、V4では、「V4R4実行管理の手引き」のページ286に、プール毎のページ不在レベルの最小/最大が記載された表がある。 
     
• ディスク
  • 大まかな指針値として、ディスク・アームの稼働率は40%が、ディスクIOPの稼働率は60%が限界値。(「iSeries パフォーマンス」参照)

より詳細なレベルのガイドラインが必要であれば「iSeries Technical Overviews」の「Performance Update」に下記項目についての評価手順が記載されている。

• CPU Utilization Guidelines (ページ65)
• Number of Disk Arms Sizing (ページ77)
• Page Fault Considerations (ページ82)

さらに、包括的なOS/400のパフォーマンス関連情報は「Performance Management」にまとめられているので、必要に応じて参照すると良いであろう。

長期にわたるパフォーマンスの傾向分析や、アプリケーション/ジョブレベルでの詳細な分析にはPM iSeries、iDoctor for iSeriesなどのツールの検討をお勧めする。また、SQLのパフォーマンス評価にはiSeriesナビゲーターの標準機能であるSQLパフォーマンス・モニターとVisual Explainが使用できる。パフォーマンス評価の目的に合わせて適切なツールを選択されたい。

システムの制限値

OS/400には各種の「最大値」(あるいは制限値)が存在する。ほとんどの場合、ユーザーがこれらを考慮する必要は無いが、大規模システムや特殊なアプリケーションにおいて、これらの上限に抵触するケースが散見される。システムを設計・運用する際に、これら制限値を一読することをお勧めする。各バージョン/リリースごとの制限値の記載先を下記に示す。

• V4R5 
• V5R1 
• V5R2 
• V5R3 

リリース毎に制限は緩和されているが、ここではV5R3を前提としていくつかの項目について解説する。

• 「Communications limits」の「Recommended maximum number of devices allocated to an interactive or communications subsystem」
  

対話型あるいは通信サブシステムに一時点で割り振られる装置数は250～300台が推奨(「制限」ではない)されている。サブシステムはシリアル(順次)に装置を割り振ろうとするため、推奨装置数を越えると装置の接続に長時間を要し、最悪の場合タイムアウトと回復処理が多発するという状況が発生する。多数の対話型端末、あるいは通信装置を単一のOS/400に接続する場合はサブシステムの分割を検討すべきである。なお、推奨装置数とマシン(区画)の能力との間に関連はないとされている。

• 「Work management limits」の「Maximum number of jobs on the system」
  

OS/400上に存在できるジョブの上限は485,000である。この数はV5R1で追加されたシステム値QMAXJOBで変更可能であり、デフォルトでは163,520(V4R5までの最大値)に設定される。現在どれだけのジョブがシステム上に存在するかはDSPJOBTBLコマンドで確認できる。OS/400ではジョブは完了した後でも、これと関連付けられた印刷出力(ジョブログなどのスプールファイル)が残っていると、ジョブの情報はシステムに保持される。大量のジョブを生成するシステムでは、こまめにジョブログや不要な印刷出力を削除するか、V5R2で追加されたジョブ属性である「SPLFACN」に*DETACHを指定し、ジョブとスプールファイルとの紐付けを除去するのが望ましい。

• 「Security limits」の「Maximum number of entries for a user profile」および「Maximum number of objects that can be secured by an authorization list」
  

単一のユーザー・プロフィールが所有あるいは私用権限を有するエントリーの最大数は10,000,000、単一の権限リストで管理できるオブジェクトのエントリー(1オブジェクトが複数のエントリーを消費)の最大数は2,097,070である。大規模なシステムで大量のオブジェクトを少数のユーザー・プロフィール、もしくは権限リストで管理している場合、これらの分割によって制限を回避する必要がある。ユーザー・プロフィールのエントリー使用率はPRTPRFINTコマンドで、権限リストのエントリーはDSPAUTLOBJ(権限リストで保護されるオブジェクト)あるいはV5R2/3にPTFとして提供されるAPI  QSYRTVAI(エントリー数)で確認できる。

SMAPPの回復時間設定と保護対象の選定

SMAPP (System-managed access-path protection：システム管理によるアクセス・パスの保護)はV3R1で追加された機能であり、自動的にバックグラウンドでシステム上のアクセス・パスをジャーナルすることによって異常終了後のIPL時間を大幅に短縮する。EDTRCYAPコマンドで動作を制御可能であり、デフォルトで有効とされている。「システム・アクセス・パス回復時間」は当初150分に設定されていたが、より高い可用性を提供するために図2のようにリリースごとに設定値が小さくされている。

図2

 

------------------------------

(囲み記事)

ADDPFRCOL、CHGPFRCOL、STRPFRCOL、WRKPFRCOL、ENDPFRCOL、STRPFRMON、ENDPFRMON

1. OS/400のコマンドラインから「GO PERFORM」を実行し、「2. パフォーマンス・データの収集」を選択
2. パフォーマンス収集が行われていない場合、「収集サービス状況」が「停止」と表示されるので、「1. データ収集の開始」を選択
3. 「データ収集の開始」でパラメーターを設定(例えばライブラリーに「QMPGDATA」を、収集間隔に5分を指定)し、パフォーマンス収集を開始する。
4. 正常に開始されると指定したライブラリーに*MGTCOLオブジェクトが作成され、ここにパフォーマンス・データが記録される。収集状況は「GO PERFORM」の「2. パフォーマンス・データの収集」で確認できる。「収集サービス状況」の「状況」が「開始」となり、収集開始時に指定したパラメーターが表示される
5. パフォーマンス収集の完了時に「GO PERFORM」の「2. パフォーマンス・データの収集」からオプション「2. データ収集の停止」を実行し、収集を停止   

V5R3におけるパフォーマンス・データの取得方法

CLコマンドでパフォーマンス・データの収集を可能とするため、V5R3では次のコマンドが追加された。

• パフォーマンス収集開始 (STRPFRCOL)
• パフォーマンス収集終了 (ENDPFRCOL)
• パフォーマンス収集の構成 (CFGPFRCOL)
• パフォーマンス収集の検査 (CHKPFRCOL)

1.  コマンド「WRKOBJPDM LIB(QMPGDATA)」で*MGTCOLの名前を確認。PDMのオプション「8= 記述の表示」で、いつ作成されたものかを確認しておく
2. コマンドCRTPFRDTAで*MGTCOLをパフォーマンス･ツールの形式に変換
3. レポートを出力する。例えばシステム全体の資源利用状況概要を把握するには下記のコマンドで「構成要素報告書」を印刷。詳細についてはhttp://publib.boulder.ibm.com/html/as400/v5r1/ic2962/info/rzahx/rzahxcollectdatacs.htm を参照
   

> PRTCPTRPT MBR(Q292160237) LIB(QMPGDATA)
ジョブ 629780/QSECOFR/PRTCPTRPT がライブラリー QGPL のジョブ待ち行列
QBATCH に投入された。

なお、パフォーマンス・ツールが利用できない場合は「Calculating Performance Metrics」に記載されている方法で、パフォーマンス・データベースから各種使用率を求める事ができる。