パフォーマンス・ツールを使ってSystem iを監視する
IBM iが搭載されたPOWERシステムのオーナーとして皆さんはパフォーマンス・データを収集して追跡するツールをすでにお持ちでしょうし、System i 6.1 (あるいはさらに一歩進んで7.1)へ移行された情報システム部門に勤務されているのであれば、システム、アプリケーション、ユーザーから見た応答時間などの謎を解くための機能がより強化されているでしょう。V5R4では独自の堅牢なパフォーマンス収集機能が備わっていますが、よりいっそう強化されたツールによりパフォーマンスに関する問題の診断と修正は、以後のリリースに比べるとずっと複雑なものになっています。
災害復旧と同様で、パフォーマンスを一定に保つにはシステム・レベルあるいはアプリケーション・レベルで保守計画を立てなければなりません。「System iNEWS」のＷｅｂサイトで作業管理と、システム内で作業をどのように動作させるかを オブジェクトを使用して制御する方法について述べています(「作業管理の復習」英文)。その記事ではシステムとシステム上で稼動しているアプリケーションのパフォーマンスの分析を始めるのに使えるしっかりとした知識を提供しています。
System i上ではコレクション・サービス(Collection Services)、ジョブ・ウォッチャ(Job Watcher)、ディスク・ウォッチャ(Disk Watcher)、パフォーマンス・エクスプローラ(PEX: Performance Explorer)の4種類のパフォーマンス収集機能が利用できます。この4種類の収集機能はいずれもすべてのシステムにおいて無償で提供されていますが、システムにパフォーマンスの問題が生じた際にパフォーマンス･ツールを持っていることでその問題を診断して修正のためのアクションを実行することができます。少なくともパフォーマンス･ツールはパフォーマンスのコンサルタントに対して、パフォーマンス･ツール・データベース中の生データを解析するよりも速くパフォーマンスの問題を識別して解決できるようにします。コレクション・サービスとベース･システムで収集されたデータを表示することができる一方、IBMパフォーマンス・ツール(5770-PT1)を使ってディスク・ウォッチャやジョブ・ウォッチャによって収集されたデータも表示する必要があります。パフォーマンス･ツールのパッケージ中ではディスク・ウォッチャが管理者機能のオプション1 (フィーチャー･コード0717)で、ジョブ・ウォッチャがオプション3 (フィーチャー･コード0548)となっています。パフォーマンス･ツールは無償ではありませんが、低価格の割には十分価値があるものです。P10ティア(ほとんどのお客様の要望に応えられます)では米国での定価が$2,370です。もちろん国によって価格は異なりますがパフォーマンス･ツールのパッケージには一度使えば十分元が取れる可能性があります。
パフォーマンス収集の4つの主な機能を理解することでシステムの動作状態についてより深い理解が得られ、今まで気づかなかったようなパフォーマンス上の問題を見つけて修正できるようになる可能性があります。
コレクション・サービス
コレクション・サービスはSystem iのパフォーマンス･データ収集手段の主要なものです。コレクション・サービスを使用することでシステムのパフォーマンスを時間に沿って追跡することができ、特定のパフォーマンスの問題が生じたときにそれを見つけることができます。パフォーマンス･データの収集には通常システム資源はほとんど使用しません。ライセンス済み内部コード(LIC: Licensed Internal Code)とオペレーティング･システムの低レベルでデータ収集が行われるからです。V5R4以降パフォーマンス･データの収集がシステムに影響を与えているのを見たことは個人的にはありません。パフォーマンス･データの収集が使用する主な資源はディスク空間です。平均的なコレクション・オブジェクトは*MGTCOLタイプで約400メガ･バイトです。通常はシステム上に30日間分のデータ(約11ギガ･バイト)を保持しておくようにお勧めしています。もしこのサイズが大きすぎるのであれば14日間分を保管するようにしてください。もっと長期間にわたるパフォーマンスの傾向を把握する必要がある場合は他の収集ツールの採用を検討してください。
パフォーマンス・エクスプローラ
パフォーマンス・エクスプローラ(PEX)はコレクション・サービスのさらに一歩上を行ってパフォーマンスに関するより詳細なデータを保持しています。驚くことではありませんが、パフォーマンス・エクスプローラはCPUと記憶空間の資源をいくぶん集中的に利用します。一般的にPEXで収集したデータは通常のコレクション・サービスで発見されたパフォーマンス上の問題をより深く調べるために使用します。PEXのレポートを印刷し、SQLを使用して収集したデータベースから情報を取り出すことはもちろんできますが、パフォーマンス・データ調査機能(PDI: Performance Data Investigator)を使用するほうが簡単です。この機能はIBMが提供するグラフィックなツールです。PEXは主として統計、トレース、プロファイルの三つの方法でデータを収集します。統計コレクションは単層コレクションと階層コレクションの両方を使って特定のプログラムに関する一般的な統計情報を提供します。前者が提供するのはプログラムとプロシージャのリストで、それぞれに個々の統計情報が付いています。後者が提供するのは収集したデータを呼び出しツリーの形式にして各ツリーやノードが実行するプログラムやプロシージャを正確に示し、サブ・プロシージャがどれくらいの頻度で呼び出されているのかを見たい場合に使用するしゃれた機能です。
トレース・コレクションはシステム上の一つ以上のジョブの履歴を記録したものです。この記録にはいつどういう順序でどんなイベントが起こったのかに関する情報も含まれます。トレース・コレクションは(ユーザーのジョブ情報に加えて)、LICのタスクとIBM iのジョブの両方の情報を保持します。トレース・コレクションは大量の情報を素早く収集しますのでそのスコープを制限しておくのが賢明です。
プロファイル・コレクションは高度な言語プログラム内の特定のコード・セクションを、そのプログラムの行番号のレベルでサンプリングするのに使用します。当然のことながらプロファイル・コレクションは特定のプログラムがどのように実行されているのかを調べるために使用します。プログラムのコードの変更前後でプロファイル・コレクションを使用してパフォーマンスを比較することは、(オンライン取引、処方箋の保険などといった)トランザクションの時間が重要となるようなパフォーマンスに細心の注意を払うべき操作にとっては有用です。
ディスク・ウォッチャ
ディスク・ウォッチャもSystem i 6.1以降のリリースに含まれているパフォーマンス・ツール・マネージャの機能の一つですが、V5R4をご使用であれば簡単なプログラム・フィックス(PTF)で使用できるようになります。ディスク・ウォッチャはさまざまな負荷のI/Oパフォーマンスをプログラム･レベルで評価します。I/Oキューイングの効果を示し、特定の負荷の間にディスクがどのように動作しているのかを見えるようにしてくれます。この機能を使用して、どのオブジェクトがディスクからデータを読み出し、ディスクにデータを書き出しているのか、どのジョブ、スレッドあるいはシステム操作がその動作を実行しているのかを知ることができます。また、ディスク・ドライブや制御カードを追加したり減らしたりしたときのシステム全体に渡る効果を予測することもできます。24台のディスク装置で問題なく稼動しているシステムは2倍の容量のディスク装置12台で十分に稼動するかもしれませんし、しないかもしれません。
ディスク・ウォッチャは大量のデータを収集します。I/Oに極度に依存したシステムでは、ディスク・ウォッチャの起動中にパフォーマンスに影響を与える場合があります。良い点としては、I/Oの問題を発見しそれをどう改善するのかについても支援してくれるということです。その改善策がディスク装置の台数を増やすべしという単純な対策になることもしばしばですが、このディスク・ウォッチャを使用すると管理費用の妥当性を示すのに必要な経験的証拠を得ることができます。
ジョブ・ウォッチャ
ジョブ・ウォッチャを使用するとジョブの情報をほぼリアルタイムに入手でき、かつそのジョブやジョブ・セットのさまざまなパフォーマンス情報を収集することができます。同機能はジョブ、スレッド、タスクごとのかなり詳細な情報を収集し、PEXコレクションやディスク・ウォッチャ・コレクションで得られる情報の大部分を含んでいます。それだけでもかなり素晴らしいことなのですが、ジョブ・ウォッチャは他のツールではできないことも実現しています。つまり、ジョブが何を待っているのかを知ることができます。あるバッチ・ジョブが数分間は問題なく実行されていたと思ったら実行速度が遅くなりそしてまた実行速度が上がるような場合は、何かの資源を待っているものと思われます。ジョブ・ウォッチャは、どのタイプのwaitなのか、オブジェクトのロック/占有条件は何かの詳細情報をリアルタイムで収集することにより、どの資源を待っているのかを知らせてくれますので、オペレーティング・システムによってロックされているオブジェクトまたはマイクロコードによって占有されているオブジェクトを見つけることができます。これによりジョブの実行速度を低下させているオブジェクトの競合時間を知ることができます。
ジョブ・ウォッチャを使用する最大の利点の1つはジョブへの変更前後での比較を行えることです。たとえばパフォーマンスが不十分な対話型のジョブがあったとしましょう。開発者がプログラムを整理してパフォーマンスを向上させましたが、そのジョブは実際のところ本当にパフォーマンスが向上したのでしょうか。ジョブ・ウォッチャはそのジョブに関するデータを収集してトランザクション時間の主要な部分を占めている箇所を発見できます。こうすれば開発者は改善を要するプログラム内のエリアだけにフォーカスすることができます。するとジョブ・ウォッチャは新しいデータを収集しますので、開発者は改善により問題が解決されたのかボトルネックをプログラムの他の部分に移動させただけなのかがわかります。
パフォーマンスの定義
パフォーマンス･データを収集するのに利用できるツールについては理解しましたので、良いパフォーマンスの定義を理解する必要があります。私にとって良いパフォーマンスとはジョブの機能と直接の相関があります。もしあなたが出荷待ちの商品の積荷を準備する出荷担当者で、運転手が出荷伝票の処理と出力を今かと待っているとしたら、瞬時の応答時間と本当にすばやく印刷するプリンタが必要でしょう。商品を出荷することはその組織にとって実際の収入となるわけですから、出荷担当者はシステムからの最速の応答時間を望んでいます。医療および調剤薬品メーカーも迅速な応答時間を必要としています。薬局が処方の保険適用情報を問い合わせるとき、その問い合わせのトランザクションは1秒以内に処理されて戻ってこなければなりません。それには薬局と処理しているプロセッサとの間の転送時間も含んでいます。
したがって良いパフォーマンスの定義はビジネスにとって良いかどうかで決まります。ベースラインを設定するために、150人のユーザーが顧客サービス、出荷、受け入れ、製造現場、倉庫、IT、総務(HRや会計)などに分散している企業を例に考えてみましょう。
IBMはすべてのトランザクションを1秒以内に処理すべきであると提唱しており、これには私も同意見ですが、出荷伝票の場合はどうでしょうか。プリンタの印刷速度だけが出荷現場での実際のパフォーマンスの指標になります。なぜならトラックの運転手は荷積めを待っている時間ではなく運搬している時間で給料をもらっているからです。顧客サービス担当者を待っている顧客は、担当者がキーボードをたたいて応答を待っている間に天気や今日の出来事について話しながらとてもイライラしているものです。これらのパラメータからすると、顧客サービスと出荷担当者はともにとても高速なオンライン応答を必要としていることがわかります。さらに出荷担当者は、印字速度が速いだけでなく出荷伝票がすばやく印刷可能な状態になるプリンタを必要としています。オンライン応答時間と印字時間が1秒以内であることがこの場合では不可欠です。しかしLAN/WANおよびローカルの装置が高速に機能するためには、応答時間の3分の1程度しかシステムの処理時間がなく、プリンタが2秒以内で印字するには、システムは全体のトランザクションを10分の3秒以内で完了させてローカルのコンピュータとプリンタにそれぞれのタスクを処理させる時間を与えなければなりません。
ウェブの応答時間はプリンタの応答時間とほぼ同様です。応答時間を許容範囲内に収めるために処理しなければならないタスクがいくつかあります。データベースのパフォーマンスが応答時間に影響を与える割合はほんのわずかです。影響するのはウェブ・サーバーとブラウザです。この三つのうち制御することが可能なのはデータベースとウェブ・サーバーです。ブラウザはほとんどのユーザーが制御できないものですので、IBM iサーバーからブラウザまでの間で工夫することをお勧めします。
バッチ応答時間は最も理解しやすくしかも最も制御しやすいものです。バッチ・ジョブは割り当てられた時間内で処理を完了するかしないかです。実行時間に対する期待値を変えるかI/Oパターンや待ち時間を調整するかのいずれかです。いずれにしろIBM iは応答時間を調整するのに必要なデータを収集してくれます。
まとめると、顧客が使用するプログラムの応答時間が印刷ジョブとデータベースのトランザクション(ウェブあるいはODBC/JDBCのいずれか)の両方を含んで10分の3秒以内であり、バッチ・ジョブが時間通りに終了すれば応答時間は良いはずです。
パフォーマンス・データの収集
さて良い応答時間の定義が済みましたので、次はそれをどう測るかです。パフォーマンス・ツールがなくてもコレクション・サービスを使ってパフォーマンス･データの収集を始めるのが良いでしょう。このツールにはSystems Director Navigator for i経由でアクセスできます(注記: Systems Director Navigator for iを使用するにはApacheサーバーのAdminインスタンスが起動されていなければなりません)。Systems DirectorをオープンしてPerformanceを選択します。次にShow All Performance Tasksをクリックすると図―1のようなダイアログが表示されます。ここからCollection Servicesをクリックしてダイアログを拡張します。次にCollection Services Statusをクリックしてシステムが現在収集しているものを確認します。図―2はシステムのステータスを表示しています。ここでデータが現在収集中であり、管理コレクション・オブジェクトがQPFRDATAライブラリに保存されていることがわかります。収集したいデータを構成するにはOKをクリックし、Configure Collection Servicesをクリックします。左側に、General、Data to Collect、Data Retentionの三つのメニュー項目があります。Generalメニューでは管理コレクション・オブジェクト(オブジェクト・タイプ*MGTCOL)を保存するライブラリとパフォーマンスのスナップショットをどれくらいの頻度で保存するかを選択できます。この例では、システムはコレクション・オブジェクトをQPFRDATAライブラリに保存し、15分毎にデータを収集しています(ともにデフォルトの構成)。毎日夜中に新しいコレクション・オブジェクトを収集しなおします。午後10時に開始され4時間実行される大きなバッチ処理がある場合、このサイクル時間を午後9:30に変更してバッチの実行が一つのコレクション内にすべて収まるようにすることを検討してみてください。大きな日次プロセスを複数のコレクション・オブジェクトに分けたくはないでしょう。データ・コレクションの連続性を保ちプロセス全体がパフォーマンスの要約からもっとも詳細なレベルにいたるまで一つのコレクション中になるようにしたいからです。こうしておくと後で行う分析作業を効果的に行うことができます。私は多くの顧客に対して、最初のシフトの開始時刻から始めて8時間おきに収集を開始するようにお勧めしています。これにより顧客はシフトごとにパフォーマンスに集中することができます。
Configure Collection Servicesダイアログボックス(図―3)には三つのチェック・ボックスがあります。最初のチェック・ボックスにチェックを入れるとパフォーマンス・ツールのデータ・ファイルが管理コレクション・オブジェクトから作成されます。ディスク空間を節約するために、私は必要となるまでファイルを作成しません。なぜなら必要ならばいつでもコレクション・オブジェクトに対してパフォーマンス・データを書き出させることができるからです。二番目のチェック・ボックスは実際の収集サイクルの際に要約データを作成させるものです。要約データで分析ツールを使用するとパフォーマンス･データベースの処理を高速にできます。実際にはそれほど時間の節約にはなりませんので、ディスク空間に余裕がないときはチェックをはずしておいてください。ディスク記憶域に問題がないときは(30日分のコレクションに約11ギガ･バイト必要となることを思い出してください)、要約データを収集することをお勧めします。8時間おきだけに収集サイクルを起動し、要約データを作成するような設定方法を図―3に示します。
Data to Collectタブはコレクション・サービスに対してシステムが保持すべきデータのタイプは何であるかを伝えるものです。Minimum、Standard、Standard Plus Protocol、Enhanced Capacity Planningの4つの事前に定義されているプロトコルがあります。ご想像の通り、Minimumというプロトコルは最小限のデータを保持し、それ以外のカテゴリはコレクションにより多くのデータを追加しています。Standard Plus Protocolは最も使用されるプロトコルだと思います。Customize Collection Profileラジオ･ボタンを選択してデータ・コレクションをカスタマイズする選択をすると、図―4に示す画面が表示されます。ここで好みのコレクション・タイプを選択することができます。このダイアログではDomino用のコレクションは表示されませんが、システム上にDominoが搭載されている場合Dominoのパフォーマンス・データを収集するオプションがあります。通常私はStandard Plus Protocolのデータしか収集しませんが、めったに使用しないEnhanced Capacity Planning (PEXプロセッサ効率)以外の必要なデータはほとんど含まれています。近々アップグレードを計画されていて負荷評価ツール(WLE)中のパフォーマンス・データをIBMに提供する必要があるのであれば、PEXデータを収集する必要があるかもしれません。左側の最後のタブはパフォーマンス・データをどれくらいの期間システム上に保持しておくかを決めます(図―5)。図―5ではコレクション・オブジェクトを30日間保持し標準パフォーマンス･データ・ファイル中のパフォーマンス･データを1日間保持するような設定になっています。月末の締めを過ぎたパフォーマンスをモデル化するにはこのデータで十分です。あとでコレクション・オブジェクトからパフォーマンス・ツール・ファイルをいつでも生成でき、パフォーマンス・ツール・ファイルの代わりに小さなサイズのコレクション・オブジェクトを保存できることを覚えておいてください。
データの分析
Active Collection Servicesを選択した場合、システム上のコレクション・オブジェクトのリストを確認することができます。あるコレクション上でダイアログをオープンし(図―6)、データを精査します。Propertiesオプションはデータが収集された時間とそのコレクションに何が含まれているかを表示するだけです。
Investigate Dataを選択すると収集されたデータをグラフで表示します(図―7)。ここでグラフ化したいデータのタイプを選択することができます。図―7ではディスクがビジーな割合、空間の利用率、CPUの利用率の三つの基準が選択されています。それぞれ別の色が使用されていて過負荷になっているものはないことがこのグラフに示されています。
私のお気に入りのグラフの一つがMemory Pools Health Indicatorsです。図―7に示すシステムはこのインジケータについて注意が必要なほど負荷が加わっていませんが、より高負荷なシステムではこのグラフを見ることですべてのメモリ共有プール間でのメモリのバランスを管理することが容易になります。私が頻繁に使用する二つの統計情報はMemory Pools Fault RatesとPhysical and Logical I/Oです。システム･レベルでは、これらの統計情報を分析することでシステムの状態とシステムがどのように動作しているのかをかなり把握できます。ここから特定のジョブの統計情報を詳細に見ていくことができます。
顧客システムにパフォーマンス･ツール･パッケージが導入されていない場合は、コレクション・オブジェクトを自分のシステムに読み込んでそこで分析します。パフォーマンス･ツールが導入されているシステムであれば他のシステムで収集されたパフォーマンス･データを評価することができます。
結論
すべてのシステムでパフォーマンス･データを収集することができます。多くの顧客が犯す最大の失敗はIBMのデフォルトのパフォーマンス収集機能だけに頼ることです。この機能はごく短期間データを保存しておくに過ぎません。問題が発生した当日に呼び出されたのであればデータを分析することはできますが、データがなくなってしまえばイベントは失われてしまいます。少なくとも14日間はデータを保持しておくようにご自分でシステムを設定してください。またツールを試しに使ってみてください。システムがどれくらい健全に動作しているのかをずっと正しく理解することができますし、パフォーマンス上の問題を発見して修正できる可能性もあります。
