System i Performance Adjusterと共有メモリー・プールを最適化する
Performance Adjusterを正しく初期化してSystem i を最大限に活用
1988 年に AS/400 として導入されて以来、System i は極めて生産的で、ほとんどメンテナンス・フリーという、一種の自己管理プラットフォームとしての評判を得てきました。梱包を解き、床に置いて、電源を入れるだけでよかったのです。幸か不幸か、そのどちらでもないのか、その評判はある程度本当なのですが、ひとつだけ、サーバーが通常は、効率的に調整されていない状態で稼働するという問題があったのです。
長年に渡る私の経験から、「すぐに使用可能な」は大方「調整されていない」と同じ意味だと思っています。また、System i は最小限の保守要件で済むため、ほとんどの System i ショップは開発者が中心で、サーバー処理リソースを効果的に調整するための専門技術知識が社内にないことが、ときたまではなく頻繁に発生していました。単純にシステム値 QPFRADJ を変更してパッケージ済みの Performance Adjuster ツールを有効にすれば、パフォーマンス問題は解決し、サーバーが効率的に動作するという誤解があります。
この記事では Performance Adjuster に関する事実と誤解を説明し、さらに共有メモリー・プールと合わせて Performance Adjuster を正しく初期化し、パフォーマンスを最適化して System i に対する投資を最大限に活用し、Performance Adjuster の過剰反応による障害を防ぎ、有害無益にならないようにする方法を詳細に説明します。サーバーのワークロードを合理化し、Performance Adjuster の最小範囲と最大範囲を初期化するには、少なくとも時間と努力が必要ですが、それによりパフォーマンスを劇的に改善し、安定させることができます。これは、オペレーティング・システム・フォールティングだけでなく、アプリケーションの共有メモリー・プール・フォールティングの安定化を行って、パフォーマンスを予測しやすくする効果があります。
裏話
プラットフォームのパフォーマンスに影響を与える物理リソースは CPU、メモリー、ディスク・アーム、ネットワーク帯域幅ですが、後者は外部リソースにあたり、この記事の対象外です。サーバー・パフォーマンスは、その最も弱い処理リソース同様にしか成りえないため、それらをすべて効率的に測定し、調整することが大切です。パフォーマンスにマイナスの影響をもたらす非物理リソース要因として、データベース索引付けや獲得/ロック競合や権限検索などの例外処理があります。これらの非物理リソースの修正には別のスキル・セットが必要であり、物理リソースの基本的な調整が完了してから検討するのがよいでしょう。
CPU が 99% で動作していることは常に好ましくないという、すべてのプラットフォームについて大変一般的な誤解も存在します。対話式応答時間が許容範囲であり、バッチ作業が保守ウィンドウ内で完了している限り、それは必ずしも当てはまりません。上記のいずれかが当てはまらなくなったら、サーバーをより徹底的に調整して再評価したり、性能を発揮しきれていないコンポーネントをアップグレードする必要があります。とりわけ、作業管理、バッチ競合 (同時に実行しているジョブの数が多すぎる) と関連する収穫逓減、パフォーマンス・システム値、IFS 最適化技術、データベース・ジャーナリングの最適化、ハウスキーピング・ベスト・プラクティスなどの、その他の検討事項も重要な要因ですが、これもこの記事の対象ではありません。
買うか調整するか
正しい専門知識のない多数のショップは、パフォーマンスの低下は CPU をアップグレードする必要があるサインと想定する傾向があり、一般的に最も未調整のリソースである入出力を再評価しようとしません。すべての既存のリソースを効果的に測定し、調整するのではなく、役に立つか立たないかわからないような不要な処理リソースに、衝動的に資本投下する傾向があるのかもしれません。サーバーを調整する場合、これらのさまざまなリソースが同様に重要であり、メモリー・フォールティングやディスク・アーム使用率のような、一つのリソースのボトルネックを解消すると、以前は十分に活用されていなかったり、または効率的に動作していた CPU のような、別のリソースにボトルネックが発生することがあることを覚えておいてください。
水車を動力源とする工場で、小麦から小麦粉を製粉しているところを想像してみてください。水車は十分に活用されていないか、あるいは仕様の範囲内で機能していますが、小麦粉の生産量をアップさせるために、さらに高速で回転させる必要があります。水車の回転はそれに流れる水量によって異なりますが、上流のダムが原因で水量が制限されています。ダムが解放されるまで、水車を大型のものにアップグレードしても意味はありません。
水車を全力で稼働できない CPU と考えると、水はワークロード、ダムは入出力のボトルネックとみなすことができ、その例えに従えば、関連する入出力のボトルネックが修正されない限り、CPU をアップグレードしても意味がないことがわかるでしょう。メモリー・フォールティングや、過剰またはバランスが取れていないディスク・アーム使用率などの入出力ボトルネックが解消されれば、作業は流れ CPU を動かします。それまでは CPU を正確に測定して、CPU もアップグレードする必要があるかどうか判断することはできません。言い換えれば、上流の入出力ダムを開放するまでは、POWER7 水車にアップグレードするべきではないでしょう。
Performance Adjuster は何ができるのか
System i の Performance Adjuster はこの状況を管理するのに役立ちます。Performance Adjuster は、図 2 に示す Work with Shared Pools 画面内の図 1 に示すしきい値に依存しているシステム値 QPFRADJ を設定して有効にします。Performance Adjuster はこれらの共有プールしきい値を常時測定し、フォールティングの緩和のためメモリー・リソースを動的に再割り振りしたり、アクティビティー・レベルを調整して、安定した移行を行います。フォールティングや移行のしきい値になると、各共有プールについて定義された最小範囲と最大範囲に基づいてメモリー・リソースが再割り当てされます。そのまま使える Performance Adjuster の効果を制限する 2 つの問題として、ほとんどの作業は *BASE プールでデフォルトで実行されること、また Performance Adjuster の範囲はデフォルトで非常に低い最小範囲と高い最大範囲に設定されていることです。これは、制限がなさ過ぎるため、効果があるというよりむしろ害となるような過剰反応を引き起こすおそれがあります。
Performance Adjuster が最も効果的になるには共有プールが必要です。メモリー範囲の制限を取り払うと、上記の例えで言えば、ダムを勝手に開いたり閉じたりするようなことになってしまいます。これでは、リソースの利用率を予測することはできません。調整範囲を無制限にすると Performance Adjuster がアドホック対話式照会などの一時イベントに対して過剰反応を起こすおそれがあります。例えば、対話式イベントに反応し、アドホック・イベントが終了してからメモリーを共有プール *INTER に再割り当てし、結果的に逆に反応し、元の状態になる可能性があります。この場合、上限 (Max %) *INTER が高すぎて、他のプールが低くなりすぎるなど、事態がさらに悪化するおそれがあります。
これらの移行が原因で予期しない結果になり、パフォーマンスが測定しにくくなるおそれがあります。最小範囲と最大範囲を正確に決めることで、サーバーは日中の対話式集中型ワークロードから、業務時間終了後や週末のバッチ集中型ワークロードに安全に移行することができます。
アクティビティー・レベルを管理する
Performance Adjuster にはまた、アクティビティー・レベルの管理という仕事があり、そのまますぐに効率的に行われる唯一の仕事です。Performance Adjuster 以前の手動による調整が必要だった頃、アクティビティー・レベルが不適切だと図 3 に示すように Wait to Ineligible (Wait-Inel) 移行や Active to Ineligible (Act-Inel) 移行が Work with System Status (WRKSYSSTS) 画面で行われ、CPU にアクセスできないジョブが原因で重大なパフォーマンス問題が発生しました。
メモリー・プールのアクティビティー・ジョブまたはスレッドの数に比例してアクティビティー・レベルを維持することは極めて重要ですが、Performance Adjuster はそのままでは、ほとんど付加価値はありません。デフォルトでは、調整するメモリー・プールが最小限になるよう、サーバーはすべての作業が *BASE メモリー・プール不足で出荷されるためです。Performance Adjuster を非常に効果的にするには、異なる作業を個別の共有プールに分割することが重要な前提条件となります。
ここで、コミュニティーが、ボールルーム・ダンス、ライン・ダンス、ジャズ・ダンス、ディスコ・ダンスなど誰でも利用可能な 1 つの大きなフロア・スペースを確保したダンス・ホールを建てたと想像してください。参加者の人数、スペースや時間のニーズが各ダンス・スタイルで異なり、速度が異なる別の音楽で踊ります。これら異なるダンサーが同じフロア・スペースで同時に競技した場合に発生する混沌を想像してみてください。ダンサーが、特長が同じ他のダンサーとより小さなフロア・スペースを共有するよう、建物を適度な大きさの個室に分けるのが理にかなっているでしょう。
ダンス・ホールが System i のメモリーだと想像してみてください。そこではほとんどの作業が *BASE メモリー・プールでデフォルトで実行され、OS、バッチ、データベース、非同期などさまざまな種類の作業が、異なる優先度、タイム・スライス、スレッドを使用する同じリソースを求めて競合している場合、混沌とした結果になります。個別のダンス・フロアの場合同様、異なる種類の作業を合理化し、それらを自身の共有プールに経路指定する方が理にかなっているでしょう。そこでは、専用リソースが同様の作業特性を備えた他のジョブとともに実行されます。
共有プールを合理化して、実装する
Performance Adjuster を有効にする前に、サーバーを効果的に調整するためには、サーバーで動作している異なる種類の作業を合理化し、同様の特性を共有しているメモリー・プールに経路指定する必要があります。主な作業として、対話式、バッチ、そして非同期の 3 種類があります。バッチ作業は必ずしも開始と停止を行わず、アクティブな状態を保ち、作業が来るのを待機し、処理をしてからまた待機します。非同期作業は、バッチ作業とは異なる優先度で実行される場合があります。
非同期作業の良い例として、図 4 に示すサード・パーティーの独立系ソフトウェア・ベンダー (ISV) サブシステムがあります。これは、利用するリソースの量によって *BASE から移動する必要があったりなかったりします。以下のコマンドを使用して、サブシステム作業を *BASE プールから個別の共有プールへ経路指定できます。サブシステムごとに Change Subsystem Description (CHGSBSD) コマンドを 1 回実行する必要があり、また指定のサブシステムのルーティング・エントリーごとに Change Routing Entry (CHRRTGE) コマンドを 1 回実行する必要がある点に注意してください。
- バッチ作業を *BASE から Shared Pool 1 へ経路指定します
- CHGSBSD SBSD(QBATCH) POOLS((1 *BASE) (2*SHRPOOL1))
- CHGRTGE SBSD(QBATCH) SEQNBR(nnn) POOLID(2)
- 非同期作業を *BASE から Shared Pool 2 へ経路指定します
- CHGSBSD SBSD(&ASYNCHSBS) POOLS((1 *BASE) (2 *SHRPOOL2))
- CHGRTGE SBSD(&ASYNCHSBS) SEQNBR(nnn) POOLID(2)
- HTTP 作業を *BASE から Shared Pool 3 へ経路指定します
- CHGSBSD SBSD(QHTTPSVR/QHTTPSVR) POOLS((1 *BASE) (2 *SHRPOOL3))
- CHGRTGE SBSD(QHTTPSVR/QHTTPSVR) SEQNBR(10) POOLID(2)
Performance Adjuster を初期化する
Performance Adjuster の境界を支配し、実施する共有プールの特性を Work with Shared Pools (WRKSHRPOOL) コマンドを使用して対話式に、または Change Shared Pool (CHGSHRPOOL) コマンド経由でプログラムで初期化できます。WRKSHRPOOL コマンドにはビューが 3 つ (Pool Data、Tuning Data、Text) あり、コマンド実行後に F11 キーで切り替えます。WRKSHRPOOL コマンドは対話式にしか実行できませんが、すべての共有プールを一箇所に表示し、変更できる機能を提供しています。CHGSHRPOOL は対話式でもプログラムでも実行できますが、プール固有であり、一度に 1 つのプールしか操作できません。Change Shared Pool 画面の例を図 5 に示します。
以下の例では CHGSHRPOOL コマンドを使用して調整範囲の基本線を導入し、CPU 利用率、ディスク・アーム利用率、ボード間フォールティングを押し上げる可能性がある *MACHINE フォールティングをなくしています。これらの例は、特定のサーバーのニーズは異なる場合があることを理解しつつ、あくまでガイドラインとして利用されている点を覚えておくことが大切です。ベスト・プラクティスは、月末などピーク処理時間中の適度な上限境界を測定して判断することです。利用率がピークのときの許容範囲のパフォーマンスは、通常は利用率がピーク時以外の場合と同じであるためです。結局は、そのプールのフォールティングを 0 に保つ *MACHINE プール最小/最大 % 範囲を決めることをお勧めします。
- 調整範囲の基本線を導入します
- CHGSHRPOOL POOL(*MACHINE) MINFAULT(00.00) JOBFAULT(*DFT) MAXFAULT(*DFT) MINPCT(10.00) MAXPCT(20.00)
- CHGSHRPOOL POOL(*BASE) PAGING(*CALC) MINFAULT(25.00) JOBFAULT(*DFT) MAXFAULT(*DFT) MINPCT(10.00) MAXPCT(40.00)
- CHGSHRPOOL POOL(*INTERACT) PAGING(*CALC) MINFAULT(10.00) JOBFAULT(*DFT) MAXFAULT(100) MINPCT(10.00) MAXPCT(40.00)
- CHGSHRPOOL POOL(*SPOOL) PAGING(*CALC) MINFAULT(*DFT) JOBFAULT(*DFT) MAXFAULT(*DFT) MINPCT(1.00) MAXPCT(2.00)
- バッチ・メモリー・プール設定を初期化します
- CHGSHRPOOL POOL(*SHRPOOL1) PAGING(*CALC) MINFAULT(*DFT) JOBFAULT(*DFT) MAXFAULT(*DFT) MINPCT(10.00) MAXPCT(40.00)
- 非同期メモリー・プール設定を初期化します
- CHGSHRPOOL POOL(*SHRPOOL2) PAGING(*CALC) MINFAULT(*DFT) JOBFAULT(*DFT) MAXFAULT(*DFT) MINPCT(10.00) MAXPCT(20.00)
- HTTP メモリー・プール設定を初期化します
- CHGSHRPOOL POOL(*SHRPOOL3) PAGING(*CALC) MINFAULT(*DFT) JOBFAULT(*DFT) MAXFAULT(*DFT) MINPCT(10.00) MAXPCT(15.00)
パラメーターの説明
次に WRKSHRPOOL コマンドと CHGSHRPOOL コマンドの各パラメーターを簡単に説明します。これらのパラメーターは両方のコマンドで同じですが、WRKSHRPOOL コマンドの列と CHGSHRPOOL コマンドの行として表されます。
- プール ID: ストレージ・プールの名前 (*MACHINE、*BASE、*INTERACT、*SPOOL、*SHRPOOLn)
- ストレージ・サイズ: キロバイト (1KB = 1024 バイト) の倍数で表されるストレージ・プールの目的のサイズ
- アクティビティー・レベル: プールで同時実行できる最大スレッド数
- ページング・オプション: これは、パフォーマンスを最適化するためにシステムがストレージ・プールのページング特性を動的に調整する (*CALC) か調整しない (*FIXED)か を判断します。
- テキスト説明: このストレージ・プールに関連付けられた言い回し
- 最小ページ・フォールト: このストレージ・プールを調整するガイドラインとして使用する 1 秒あたりの最小ページ・フォールト
- スレッド当たりページ・フォールト: プールを調整するガイドラインとして使用するアクティブ・スレッドごとの 1 秒あたりの最小ページ・フォールト。各ジョブは 1 つ以上のスレッドで構成されています。
- 最大ページ・フォールト: このストレージ・プールを調整するガイドラインとして使用する 1 秒あたりの最大ページ・フォールト
- 優先度: 調整中の他のストレージ・プールの優先度に対して Performance Adjuster によりこのプールに指定された優先度
- 最小サイズ %: このストレージ・プールに割り振る最小ストレージ量で、主記憶合計量の割合で表します。
- 最大サイズ %: このストレージ・プールに割り振る最大ストレージ量で、主記憶合計量の割合で表します。
注意点を 1 つ
静的リソースを含む 1 つの LPAR での動的メモリー再割り当てに関してこの記事でお話した問題点を考慮してから、複数の LPAR 間の上限のないプロセッサーおよびメモリーのリソースなど、新しいハードウェア管理機能を考慮する必要があります。リソースが静的な場合に 1 つの LPAR でパフォーマンスを調整し測定するのは大変なため、物理リソースが複数の LPAR 間でいきなり動的になった場合にどのような問題が発生するおそれがあるか想像できます。キャパシティー・プランニングの努力をすることはもちろんですが、移動している目標に対して正確にパフォーマンスを分析するのは、不可能ではないにしても、難しくなります。例えば、CPU 稼働率が 90% の状態のある期間のパフォーマンス・データを参照している場合、指定の間隔でたまたま LPAR に割り当てられた CPU 量の 90% になったことが突如問題となります。ある LPAR 上のアドホック・イベントも複数の LPAR に一連のイベントを突然発生させ、物理リソースの再割り振りの競争という様相になるおそれがあります。これでは合理化は困難です。上限のないリソースを決して有効にしないと提案しているわけではなく、参加している LPAR 間の相互依存性、潜在的な悪影響を理解し、上限のないリソース割り振り境界を実装しようとしているだけです。物理リソースは連動しており、1 つのリソースを増減させると他のリソースにも影響が及ぶ可能性があります。そのため、物理 CPU およびメモリーのリソースを動的かつ個別に突然操作できるようにした場合は、注意が必要です。
最後に
サーバー調整の最も好ましい主たる目標は、常に優れたパフォーマンスを発揮させることです。非ピーク時に優れたパフォーマンスが発揮されるという前提で、処理ピークを扱うようサーバーを調整することがベスト・プラクティスです。例えば、予算の制約などの理由で処理リソースを追加獲得できないなど、それが単純に可能でない場合、業務とエンド・ユーザーの期待を管理するため、少なくともパフォーマンスを予測可能にすることが次の目標になります。低パフォーマンスはそれだけでも十分良くないのですが、唯一それより悪いのは低パフォーマンスを予測できないことです。
正しく実装された Performance Adjuster は過剰なフォールティングを修正し、エンド・ユーザーとバッチのパフォーマンスを安定させ、サーバーが対話式ワークロードとバッチ・ワークロード間を安全に移行できるようにします。また、その待望のサーバー予測可能性を達成するためドラスティックな移行を修正できます。
Performance Adjuster はパワフルなツールですが、過剰反応しないよう、リソースを調整する能力に境界を設ける必要があります。また、共有プールも最も効率的になるように実装する必要があります。共有プールと Performance Adjuster 範囲については恐れることなく新しいことにチャレンジしてみてください。
