2019.01.10



Dawn May著

収集サービスを構成する

収集サービスは、パーティションや稼働しているワークロードについての有益な情報を収集します。多くの人が収集サービスをパフォーマンス データとして考えていますが、実際にはシステム管理データであり、何らかの時点で、そのデータが必要になることがあります。収集サービスは、システムで稼働している全体的なワークロードおよび経時的なトレンドについて把握するのに役立ちます。収集サービスは、時間を遡って現在に至るまでの経過を把握できるようにし、他の様々な疑問点を解明するためのデータを提供してくれます。

収集サービスはデフォルトでオンになっているため、そうと知らなくても収集サービスは実行されています。収集サービスはオフにしないでください。オフにした場合は、もう一度オンにしてください。システム出荷時点で収集サービスのデフォルトの構成は適切なものになっていますが、さらに適切な構成にするために変更することもできます。

以下では、収集サービスの重要な構成パラメーターについて見て行きますが、それらのパラメーターの一部については、考慮に入れる必要がある、稼働環境の面で注意が必要な点がいくつかあります。収集サービスを構成する際にお勧めのインターフェースは、Navigator for i Webコンソールです。CFGPFRCOLコマンドも使用できますが、このコマンドは過去何回かのリリースを経てより複雑化しています。

次のスクリーン キャプチャーは、「Configure Collection Services(収集サービスの構成)」タスクが、Navigator for i 内でどこからアクセスできるかを示しています。このタスクは、「パフォーマンス」タスクの一部です。

hint01

次のスクリーン キャプチャーは、「Configure Collection Services(収集サービスの構成)」タスクの「一般」タブの画面です。重要な4つのパラメーターに番号を振ってあります。

hint02

検討するべき1つ目のパラメーターは、収集間隔です。デフォルトでは15分です。コンピューターの時間では、15分というのは極めて長い時間です。当初、IBMは、収集サービスのデータによって使用されるディスク容量を考慮して、問題がなさそうな値としてこのデフォルト値を選択しました。今日では、ディスクの容量が大量にあるショップがほとんどであるため、収集間隔をより短く調整するようにしたほうがよいでしょう。IBMでは5分の収集間隔を推奨していますが、筆者もIBMの推奨値で適切だと思います。15分の収集間隔と比べて約3倍多くのディスク領域が必要となりますが、これは一般的にはトレードオフとしても問題なさそうです。時間が経つと、システムは収集データを自動的に失効させるため、時間の経過とともに大量のデータが蓄積する心配はありません。

2つ目のパラメーターでは、いつ収集を循環させるかを指定します。収集の循環を行うと、現行の収集が終了し、新たな収集が開始されることになります。日単位でパフォーマンス データの確認を行う場合は、一般にデフォルトで問題ないでしょう。ただし、循環の時刻および間隔を変更したい場合には、重要な考慮事項が2点あります。

  1. 毎日の循環の時刻。収集を循環させるデフォルトの時刻は、深夜の12時です。深夜12時をまたいで実行される重要なアプリケーションがある場合は、循環の時刻を変更する必要があります。重要なアプリケーションの途中で収集を循環させないためです。たとえば、午後11時00分から午前1時00分まで実行されるバッチ アプリケーションがある場合は、午後11時以前または午前1時以降になるように循環の時刻を変更したほうがよいでしょう。
  2. 循環間隔。デフォルトでは24時間間隔であり、これは1日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)

これで、収集サービスの構成が改善されました。収集データを様々な目的のために使用できます。それらの使用法については今後の記事で取り上げる予定です。

ページトップ

ボタン