収集サービスを構成する
収集サービスは、パーティションや稼働しているワークロードについての有益な情報を収集します。多くの人が収集サービスをパフォーマンス データとして考えていますが、実際にはシステム管理データであり、何らかの時点で、そのデータが必要になることがあります。収集サービスは、システムで稼働している全体的なワークロードおよび経時的なトレンドについて把握するのに役立ちます。収集サービスは、時間を遡って現在に至るまでの経過を把握できるようにし、他の様々な疑問点を解明するためのデータを提供してくれます。
収集サービスはデフォルトでオンになっているため、そうと知らなくても収集サービスは実行されています。収集サービスはオフにしないでください。オフにした場合は、もう一度オンにしてください。システム出荷時点で収集サービスのデフォルトの構成は適切なものになっていますが、さらに適切な構成にするために変更することもできます。
以下では、収集サービスの重要な構成パラメーターについて見て行きますが、それらのパラメーターの一部については、考慮に入れる必要がある、稼働環境の面で注意が必要な点がいくつかあります。収集サービスを構成する際にお勧めのインターフェースは、Navigator for i Webコンソールです。CFGPFRCOLコマンドも使用できますが、このコマンドは過去何回かのリリースを経てより複雑化しています。
次のスクリーン キャプチャーは、「Configure Collection Services（収集サービスの構成）」タスクが、Navigator for i 内でどこからアクセスできるかを示しています。このタスクは、「パフォーマンス」タスクの一部です。
次のスクリーン キャプチャーは、「Configure Collection Services（収集サービスの構成）」タスクの「一般」タブの画面です。重要な4つのパラメーターに番号を振ってあります。
検討するべき1つ目のパラメーターは、収集間隔です。デフォルトでは15分です。コンピューターの時間では、15分というのは極めて長い時間です。当初、IBMは、収集サービスのデータによって使用されるディスク容量を考慮して、問題がなさそうな値としてこのデフォルト値を選択しました。今日では、ディスクの容量が大量にあるショップがほとんどであるため、収集間隔をより短く調整するようにしたほうがよいでしょう。IBMでは5分の収集間隔を推奨していますが、筆者もIBMの推奨値で適切だと思います。15分の収集間隔と比べて約3倍多くのディスク領域が必要となりますが、これは一般的にはトレードオフとしても問題なさそうです。時間が経つと、システムは収集データを自動的に失効させるため、時間の経過とともに大量のデータが蓄積する心配はありません。
2つ目のパラメーターでは、いつ収集を循環させるかを指定します。収集の循環を行うと、現行の収集が終了し、新たな収集が開始されることになります。日単位でパフォーマンス データの確認を行う場合は、一般にデフォルトで問題ないでしょう。ただし、循環の時刻および間隔を変更したい場合には、重要な考慮事項が2点あります。
- 毎日の循環の時刻。収集を循環させるデフォルトの時刻は、深夜の12時です。深夜12時をまたいで実行される重要なアプリケーションがある場合は、循環の時刻を変更する必要があります。重要なアプリケーションの途中で収集を循環させないためです。たとえば、午後11時00分から午前1時00分まで実行されるバッチ アプリケーションがある場合は、午後11時以前または午前1時以降になるように循環の時刻を変更したほうがよいでしょう。
- 循環間隔。デフォルトでは24時間間隔であり、これは1日1回の収集ということであり、これもデフォルトで問題ないでしょう。ただし、大規模で高負荷なシステムでは、収集データがかなり大きくなることがあります。1日に複数回、収集を循環させるようにすると、作業対象となる収集データは小さくなります。データを分析するためにクエリーを実行する場合に、より小さい収集データでより迅速に実行できます。ただし、その場合のデメリットとしては、まる１日分のデータを確認するには、複数に分かれた収集データをまとめることが必要になる点が挙げられます。
検討するべき3つ目のパラメーターは、ヒストリカル データを作成するオプションです。ヒストリカル データは、7.3リリースで導入され、デフォルトではオフになっています（これは良くないデフォルト）。ヒストリカル データの収集はオンにするようお勧めします。システムは自動的にヒストリカル データを管理し、経時的にデータを要約します。また、ヒストリカル データの保存期間を延長できるようにするために、必ず、PM Agent を実行しておくことも必要です。これにより、重要な指標を経時的に視覚化できるため、ワークロードが時間の経過とともにどのように増大するかを把握できます。ヒストリカル データは、ハードウェアのアップグレードやアプリケーション変更のロールアウトを行う前には非常に有益なデータとなります。
4つ目のパラメーター、「create database files during collection（収集時にデータベース・ファイルを作成）」については、必ず、デフォルトの*YESのままにしてください。これにより、ほぼリアルタイムで収集サービスのデータを調査できるようになります。Performance Data Investigator（今後、記事を掲載予定）では、分析のためにデータがDb2ファイル内にあることが求められます。
その他のタブにも、数多くの収集サービスの構成パラメーターがありますが、それらのほとんどは、デフォルト値で問題ないと思われます。「データ保存」タブで設定を確認してみましょう。収集サービスの標準データ（または管理収集オブジェクトのデータ）は、必ず10日間以上（ディスク容量に余裕がある場合はより長い期間）、システム上に保存されるようにしてください。また、重要な時間帯に収集された基準的な収集データを参照用に保存しておくとよいでしょう。
以下に示すサンプルのパフォーマンス収集の構成（Configure Performance Collection）（CFGPFRCOL）コマンドでは、収集間隔を5分に、循環の時刻を午後11時に変更し、12時間ごとに収集を循環させ、ヒストリカル データを作成するパラメーターを使用しています。
CFGPFRCOL INTERVAL(5.0) CYCTIME(230000) CYCITV(12) CRTPFRHST(*YES) CRTHSTDTL(*YES)
これで、収集サービスの構成が改善されました。収集データを様々な目的のために使用できます。それらの使用法については今後の記事で取り上げる予定です。
