[z/OS]

z/OS アプリケーションの設計およびパフォーマンスに関する考慮事項

アプリケーション設計は、パフォーマンスに影響する最も重要な要因の 1 つです。 このトピックを使用して、パフォーマンスに関連する設計要因の一部を理解します。

プログラム設計の悪さは、いろいろな面でパフォーマンスに影響します。 他のタスクのパフォーマンスに影響を及ぼしていても、プログラムのパフォーマンスは良好に見えることがあるため、これらの問題は検出が困難であることがあります。 以下のセクションでは、MQI 呼び出しを行うプログラムに固有のいくつかの問題を取り上げます。

アプリケーション設計について詳しくは、 IBM MQ アプリケーションの設計上の考慮事項を参照してください。

メッセージ長の影響

IBM MQ for z/OS® では、メッセージが最大 100 MB のデータを保持できますが、メッセージ内のデータ量は、メッセージを処理するアプリケーションのパフォーマンスに影響します。 アプリケーションのパフォーマンスを最大限に引き出すには、不可欠のデータだけをメッセージに入れて送信してください。 例えば、銀行預金口座に記入する要求では、クライアントからサーバー・アプリケーションに渡す必要のある情報は、口座番号と借方の金額だけです。

メッセージ持続の影響

持続メッセージはログに記録されます。 メッセージをログに記録すると、アプリケーションのパフォーマンスが低下します。 したがって、重要なデータの場合のみ持続メッセージを使用してください。 メッセージ中のデータが、キュー・マネージャーが停止もしくは誤動作したときに廃棄してもかまわないものであれば、 非持続メッセージを使用してください。

持続メッセージのデータは、ログ・バッファーに書き込まれます。 それらのバッファーは、次のような場合にログ・データ・セットに書き込まれます。
  • コミットが発生する
  • メッセージが取得されるか同期点外に置かれる
  • WRTHRSH バッファーが満杯になる
多くのメッセージを 1 つの作業単位で処理すると、メッセージが作業単位ごとに 1 つ処理される場合や、同期点外で処理される場合に比べて、入出力が少なくなります。

特定メッセージの検索

MQGET 呼び出しは、通常、キューから最初のメッセージを取り出します。 メッセージおよび相関 ID を使用する場合 ( MsgId および CorrelId ) 特定のメッセージを指定するためにメッセージ記述子で指定すると、キュー・マネージャーはそのメッセージが見つかるまでキューを検索します。 この方法で MQGET を使用すると、特定のメッセージを見つけるために IBM MQ がキュー全体をスキャンしなければならない場合があるため、アプリケーションのパフォーマンスに影響を与えます。

IndexType キュー属性を使用して、キュー上の MQGET 操作の速度を上げるために使用できる索引をキュー・マネージャーが保守するように指定できます。 ただし、索引の保守のためにわずかながらパフォーマンスが低下するので、索引は使用する必要がある場合にのみ生成するようにしてください。 メッセージ ID または相関 ID の索引を作成することも、 メッセージが順番に取り出されるキューについては索引を作成しないこともできます。 同じキー値で多くの項目を作るのではなく、異なるキー値を数多く使用してください。 例えば、 Balance1、Balance2、 Balance3 などのように分ける方が、 3 つとも Balance とするよりもよいでしょう。 共用キューの場合は、正しい IndexTypeが必要です。 IndexType キュー属性について詳しくは、 索引タイプを参照してください。

索引付きキューを使って、キュー・マネージャーの再始動時への影響を避けるには、 CSQ6SYSP マクロで QINDXBLD(NOWAIT) パラメーターを使用します。 これによって、キュー・マネージャーは、キュー索引の構築の完了を待機することなく再始動し、完了します。

IndexType 属性およびその他のオブジェクト属性について詳しくは、 オブジェクトの属性を参照してください。

可変長メッセージを含んでいるキュー

予期されるメッセージのサイズに合ったバッファー・サイズを使用して、メッセージを取得してください。 メッセージが長すぎることを示す戻りコードを受け取る場合、より大きなバッファーを取得してください。 取得がこの方法で失敗する場合、戻されるデータ長は、変換されなかったメッセージ・データのサイズです。 MQGET 呼び出しで MQGMO_CONVERT を指定し、データが変換中に拡張する場合も、 データがバッファーに収まらないことがあり、その場合はさらにバッファーのサイズを大きくする必要があります。

バッファー長ゼロの MQGET を送出すれば、メッセージのサイズが戻されるので、アプリケーションは、このサイズのバッファーを取得してから、取得を再送出できます。 キューを処理するアプリケーションが複数ある場合、オリジナルのアプリケーションが取得を再送出するときには、 別のアプリケーションがすでにメッセージを処理している場合があります。 大きなメッセージを持つことがある場合は、それらのメッセージのためだけに大きなバッファーを確保し、そのメッセージが処理されたらそのバッファーを解放する必要がある場合があります。 すべてのアプリケーションが大きなバッファーを確保すれば、 仮想ストレージに関する問題が減少することになります。

固定長メッセージを使用できないアプリケーションでこの問題を解決するには、 例えば MQINQ 呼び出しを使用して、そのキューが受け付ける最大メッセージ・サイズを見つけ、 その値を MQGET 呼び出しに使用することが考えられます。 キューのメッセージの最大サイズは、キューの MaxMsgL 属性に保管されます。 ただし、 MaxMsgL の値は 100 MB ( IBM MQ for z/OSで許可される最大値) に達する可能性があるため、この方法では大量のストレージを使用する可能性があります。
注: 大きなメッセージがキューに書き込まれた後に、 MaxMsgL パラメーターを小さくすることができます。 例えば、100 MB のメッセージを書き込んだ後に、 MaxMsgL を 50 バイトにすることができます。 つまり、アプリケーションが予期する以上の大きさのメッセージを取得できる、 ということです。

同期点の頻度

同期点の中で、 コミットせずに多くの MQPUT 呼び出しを行うプログラムは、 パフォーマンス上の問題を引き起こすことがあります。 対象となるキューが、当面使用できないメッセージでいっぱいになり、 他のタスクがそのメッセージを取得するために待ち状態を続けるという事態になりかねません。 これは、使用されるストレージの面からも、 メッセージを取得しようとするタスクでスレッドが拘束されるという面からも、 好ましいことではありません。

一般に、複数のアプリケーションが 1 つのキューを処理している場合、最高のパフォーマンスが得られるのは、通常、同期点ごとに以下のいずれかがある場合です。
  • 100 の短メッセージ (1 KB 未満)
  • より大きなメッセージ (100 KB) が 1 つ
:NONE. キューを処理するアプリケーションが 1 つしかない場合は、 作業単位あたりのメッセージ数がもっと多くなければなりません。

MAXUMSGS キュー・マネージャー属性を使用して、単一のリカバリー単位内でタスクが読み取りまたは書き込みできるメッセージの数を制限することができます。 この属性については、 MQSC コマンドの ALTER QMGR コマンドを参照してください。

MQPUT1 呼び出しの利点

MQPUT1 呼び出しの使用は、キューに書き込むメッセージが 1 つしかないときに限ってください。 複数のメッセージを書き込みたい場合は、まず MQOPEN を呼び出し、 続いて一連の MQPUT を呼び出して、最後に 1 回の MQCLOSE 呼び出しを行います。

キュー・マネージャーが保持できるメッセージの数

ローカル・キュー

キュー・マネージャーが保持できるローカル・メッセージの数は、基本的にはページ・セットのサイズです。 最大で 100 ページ・セットを持つことがでます (ただし、ページ・セット 0 とページ・セット 1 は、システム関連のオブジェクトとキュー用にすることをお勧めします)。 ページ・セットは拡張フォーマットで使用でき、ページ・セットの容量は増やすことができます。

共用キュー

共用キューの容量は、カップリング・ファシリティー (CF) のサイズに依存します。 IBM MQ は、基本ストレージ・ユニットがエントリーとエレメントである CF リスト・ストラクチャーを使用します。 各メッセージは 1 つのエントリーおよび複数のエレメントとして保管され、関連する MQMD とその他のメッセージ・データがそこに含まれます。 1 つのメッセージでコンシュームされるエレメントの数は、メッセージのサイズに依存し、さらに CFLEVEL(5) の場合は MQPUT 時に有効なオフロード規則にも依存します。 メッセージ・データが Db2® または SMDS にオフロードされる場合は、必要なエレメントの数が少なくなります。 メッセージが既にオフロードされた場合、メッセージ・データ・アクセスがより遅くなります。 メッセージ・オフロードに関連するパフォーマンスおよび CPU オーバーヘッドの詳しい比較については、Performance Supportpac MP1H を参照してください。

何がパフォーマンスに影響を与えるか

パフォーマンスは、どれだけ高速にメッセージを処理できるか、という意味の場合もありますが、メッセージ当たりに必要な CPU の量を意味することもあります。

何がメッセージの処理速度に影響するか

持続メッセージの場合、最も大きな影響は、ログ・データ・セットの速度です。 ログ・データ・セットの速度は、それを格納している DASD に依存します。 したがって、競合を減らすためにログ・データ・セットを使用頻度の少ないボリュームに配置する場合は注意が必要です。 MQ ログをストライピングすると、入出力ごとに複数のページが書き込まれたとき、ログのパフォーマンスが向上します。 また、Z High Performance Fibre 接続 (zHPF) には、入出力サブシステムが使用中の場合、入出力応答時間に対して優れたパフォーマンスを発揮します。

メッセージの取得および書き込み要求がある場合は、キューの整合性を保持するために、その要求の間はキューへのアクセスはロックされます。 計画を立案する場合は、要求全体に対してキューをロックすることを検討してください。 つまり、書き込み時間が 100 マイクロ秒で、毎秒 10,000 を超える要求がある場合は、1 秒の遅延時間が発生します。 実際にはこれよりも良くなりますが、原則としてはこれで十分です。 異なる複数のキューを使用してパフォーマンスを改善することができます。

これに対して考えられる理由は以下のとおりです。
  • すべての CICS® トランザクションが使用する共通応答キューを使用する
  • 各 CICS トランザクションには、キューに対する固有の応答が与えられます。
  • CICS 領域のキューへの応答と、 CICS 領域内のすべてのトランザクションがこのキューを使用します。
答えは、毎秒ごとの要求の数と、要求の応答時間によって異なります。

メッセージをページ・セットから読み取る必要がある場合は、メッセージがバッファー・プールにある場合と比較して遅くなります。 バッファー・プールに収容できないほど多くのメッセージがある場合、メッセージはディスクにあふれ出します。 そのため、必ずバッファー・プールは、寿命の短いメッセージに十分な大きさにする必要があります。 何時間も後に処理するメッセージがあると、それらのメッセージがディスクにあふれ出す可能性が高いので、これらのメッセージの取得には、メッセージがバッファー・プールにある場合よりも時間がかかることを予期しておく必要があります。

共用キューの場合、メッセージの速度はカップリング・ファシリティーの速度に依存します。 物理プロセッサー内の CF は、外部の CF よりも高速になる可能性があります。 物理プロセッサー内の CF の応答時間は、その CF の負荷に依存します。 例えば、Hursley システムの場合、CF の負荷が 17% のときの応答時間は 14 マイクロ秒でした。 この CF の負荷が 95% のときは、応答時間は 45 マイクロ秒でした。

MQ 要求で多くの CPU が使用されると、メッセージを処理する速度に影響する可能性があります。 論理区画 (LPAR) が CPU の制約を受ける場合、CPU を待つためにアプリケーションは遅延します。

メッセージ当たりの CPU 使用量

一般に、メッセージが大きくなると使用される CPU も多くなるので、可能であれば大きな (x MB) メッセージは避けてください。

キューから特定のメッセージを取得する場合は、そのキューに索引を付ける必要があります。 これにより、キュー・マネージャーは直接そのメッセージにアクセスできます (したがって、キューの全体スキャンが回避される可能性があります)。 キューに索引が付けられていない場合、そのキューは、メッセージを探しながら先頭からスキャンされます。 そのキューに 1000 個のメッセージがある場合、1000 個のメッセージをすべてスキャンする必要がある可能性があります。 この結果、必要以上に CPU が使用されることになります。

TLS を使用しているチャネルの場合は、メッセージの暗号化のために、さらにコストがかかります。

MQ V7 では、 CORRELID または MSGIDに加えて、セレクター・ストリングによってメッセージを選択できます。 すべてのメッセージを調べる必要があるため、キューに数多くのメッセージがある場合、これは高くつきます。

アプリケーションが PUT1 PUT1 よりも OPEN PUT PUT CLOSE を実行する方がより効率的です。

CICS でのトリガー操作

トリガーされたキュー宛のメッセージのメッセージ到着速度が低い場合、最初にトリガーを使用するのが効率的です。 メッセージ到着速度が毎秒 10 個のメッセージを超える場合は、最初のトランザクションをトリガーし、次にそのトランザクションで 1 つのメッセージを処理し、そして次のメッセージを取得する、というようにする方がより効率的です。 メッセージが短期間経過しても到着しなかった場合 (例えば、0.1 から 1 秒の間)、トランザクションは終了します。 スループットが高い場合、実行中の複数のトランザクションでメッセージを処理し、メッセージの蓄積を防止する必要があります。 この場合、作成されたすべてのトリガー・メッセージごとにトリガー・メッセージの書き込みと取得が必要になるので、メッセージのコストは実際には 2 倍になります。

サポートされる接続数または同時ユーザー数

各接続は、キュー・マネージャー内の仮想ストレージを使用するので、同時ユーザーの数が増えると、使用されるストレージも多くなります。 非常に大きなバッファー・プールと、多数のユーザーが必要な場合は、仮想ストレージの制約を受ける可能性があり、バッファー・プールのサイズを小さくする必要が生じる場合があります。

セキュリティーが使用されている場合、キュー・マネージャーは情報を長期間、キュー・マネージャー内にキャッシュします。 キュー・マネージャー内で使用される仮想ストレージの量に影響が出ます。

CHINIT は、最大で約 10,000 個の接続をサポートできます。 これは、仮想ストレージにより制限を受けます。 接続で使用されるストレージが多い場合 (TLS を使用する場合など)、接続ごとにストレージが増加するため、 CHINIT がサポートできる接続の数が少なくなります。 大きなメッセージを処理する場合は、 CHINIT がサポートするメッセージが少なくなるように、 CHINITのバッファー用に必要なストレージが多くなります。

リモート・キュー・マネージャーとの接続の方がクライアント接続よりも効率的です。 例えば、すべての MQ クライアント要求には、2 つのネットワーク・フローが必要です (1 つは要求用、もう 1 つは応答用)。 リモート・キュー・マネージャーへのチャネルの場合、応答が戻ってくるまでにネットワークで 50 回送信する可能性もあります。 大規模なクライアント・ネットワークを検討している場合は、分散ボックスでコンセントレーター・キュー・マネージャーを使用し、1 つのチャネルがコンセントレーターに入出力する方が効率が良くなる可能性があります。

パフォーマンスに影響を与えるその他の事項

ログ・データ・セットには、サイズとして少なくとも 1000 シリンダーが必要です。 ログがこれよりも小さいと、チェックポイント・アクティビティーの頻度が多くなりすぎることがあります。 負荷がかかっているシステムでは、一般にチェックポイントは 15 分ごと、あるいはそれよりも長くなりますが、スループットが非常に高い場合には、これよりも短くなる可能性があります。 チェックポイントが発生するとバッファー・プールがスキャンされ、「古い」メッセージおよび変更されたページがディスクに書き込まれます。 チェックポイントの発生頻度が多すぎる場合は、それによってパフォーマンスに影響が出る可能性があります。 LOGLOAD の値がチェックポイントの頻度に影響することもあります。 キュー・マネージャーが異常終了すると、キュー・マネージャーは再始動時に 3 チェックポイント戻って読み取りを行う必要があることもあります。 最適なチェックポイント間隔は、チェックポイントが取られたときのアクティビティーと、キュー・マネージャーの再始動時に読み取る必要がある可能性のあるログ・データの量の間のバランスです。

チャネルの始動時には、かなり大きなオーバーヘッドがかかります。 通常は、チャネルを頻繁に始動および停止するのではなく、1 つのチャネルを始動して、そのチャネルを接続したままにしておくことをお勧めします。