レベル: 初級 深澤 剛, テックライン, IBM
2008年 3月 01日
更新 2009年 9月 02日 好評の記事、「MQ虎の巻」の久々の改訂版(V7対応）です。今回は第9回「キャパシティ・プランニング」を改訂いたしました。
1 必要な情報
今回は分散プラットフォームにおけるWebSphere MQ V7.0のキャパシティ・プランニング方法について説明します。
キャパシティー・プランニングを行う際に必要な以下の情報について順番にご説明していきます。
- 事前調査項目
- 見積もるべき項目
- 参考情報（パフォーマンス・レポート）
1.1. 事前調査項目
キャパシティー・プランニングにあたり、最低限知っておくべき情報をまとめます。
| MQオブジェクト | キュー・マネージャー数 | システム内のキューマネージャーの数です。 |
|---|
| キュー数 | キューマネージャーごとのキューの数です。 | | チャネル数 | キューマネージャーごとのメッセージチャネルおよびMQIチャネルの数です(*1)。 | | メッセージ | メッセージ平均サイズ | ユーザー・アプリケーションが扱うMQメッセージの平均サイズです。 |
|---|
| メッセージの永続性 | 永続メッセージと非永続メッセージに分類します。 | | 最大メッセージ滞留数 | キュー内に滞留する最大のメッセージ数です。 | | アプリケーション | アプリケーション数 | キューマネージャーに接続するアプリケーション数、接続数です。 |
|---|
| ピーク特性 | ピーク時間帯のメッセージ処理量です。 | | API発行数 | アプリケーションが発行するMQI(MQGET、MQPUTなど)の数です。 |
(*1)メッセージチャネルはキューマネージャー間接続、MQIチャネルはMQクライアント接続で用いられるチャネルです。
詳しくは本講座の第2回 「WebSphere MQの特長と主な機能（後編）」をご覧下さい。
1.2. 見積もるべき項目
以下の項目を見積もりの対象とします。
| ディスク容量 | プロダクト、MQオブジェクト、ログなどのディスク使用量です。 |
|---|
| メモリー容量 | キューマネージャー、チャネル、ユーザー・アプリケーションなどのメモリー使用量です。 |
|---|
| その他のリソース | CPUなどのリソースを見積もります。 |
|---|
1.3. 参考情報（パフォーマンス・レポート）
Webサイトにて、WebSphere MQ Family製品群の性能測定結果を「パフォーマンス・レポート」として公開しています。
特定条件下でのCPU使用率・スループット・レスポンスタイム等が記述されており、机上での見積もりを行う際の参考情報として役立ちます。
Business Integration - WebSphere MQ SupportPacs
上記URLを開き、「Category 2 - Performance Reports」を選択してください。
一例として、AIXプラットフォーム上でのWebSphere MQ V7.0のパフォーマンス・レポートをご紹介します。
詳細については、以下のページより実際のレポートをご覧下さい。資料はPDF形式となっています。
MP6N: WebSphere MQ for AIX V7 -Performance Evaluations Version 1.1
CONTENTS
- Overview
V6とV7の性能比較の概略です。
- Performance Headlines
接続形態、メッセージの永続性の異なるテスト・シナリオを設定し、接続アプリケーション数をパラメータとした性能測定結果を記載しています。
- Large Messages
2章と同様のテスト・シナリオで、メッセージ・サイズをパラメータとした性能測定結果を記載しています。
- Application Bindings
2章と同様のテスト・シナリオで、アプリケーション・バインディングの違いによる性能の違いを記載しています。
- Short & Long Sessions
キューマネージャーとの接続/切断の間のメッセージが少数のケースについて測定結果を記載しています。
- Performance and Capacity Limits
チャネルのキャパシティ試験の結果を記載しています。
- Tuning Recommendations
キューマネージャー、アプリケーション、OS等のチューニングポイントについて記載しています。
- Measurement Environment
測定に使用したアプリケーション、ハードウェア、ソフトウェアなどについて記載しています。
- Glossary
テストケースの名称付与のルールや用語について説明しています。
2 ディスク容量
MQが使用するディスク容量の見積もりを行います。
2.1. 対象項目
以下の項目についてディスクの使用量を見積もります。
| 製品コード(2.2で説明) | バイナリコード、ライブラリ、サンプルコード等 |
|---|
| 作業データ | 構成ファイル、デフォルト・オブジェクト、エラーファイル等(2.2で説明) |
|---|
| キューファイル(2.3で説明) | | ログファイル(2.4で説明) |
2.2. 製品コード、および作業データ(構成ファイル、デフォルト・オブジェクト、エラーファイル等)
製品コードの導入に必要となるディスク容量は、プラットフォーム、導入コンポーネントによって異なります。
また、プラットフォームによっては作業データも含めた形でディスク容量が記載されています。
必要となるディスク容量についてはご使用のプラットフォーム向けのスタートアップ・ガイドを参照ください。
スタートアップ・ガイドは、 MQのマニュアル(オンライン・ドキュメント) に含まれています。
ご参考までにAIXプラットフォームのストレージ要件は以下のとおりです。
詳細については スタートアップ・ガイド(AIX) を参照ください。
製品コード
サーバー ：325 MB
クライアント ：276 MB
作業データ(構成ファイル、デフォルト・オブジェクト、エラーファイル等)
サーバー ：最低 50 MB
クライアント ：最低 15 MB
以下のものが使用するストレージも別途必要となります。
- 前提条件ソフトウェア
- オプションのソフトウェア
- アプリケーション・プログラム
なお、トレースファイルや、重大エラーやリカバリー不能なエラー等が発生した場合に生成されるFDCファイル(障害の情報が記録されたファイル)を保持するためのディスク容量も運用方式に応じて加味してください。
(参考文書) スタートアップ・ガイド(AIX)
[サーバー]
製品コード ：サーバーの章の サポートされる稼働環境の確認
作業データ ：サーバーの章の 作業データ用のファイル・システムの作成
[クライアント]
製品コード ：クライアントの章の サポートされる稼働環境の確認
作業データ ：クライアントの章の 作業データ用のファイル・システムの作成
2.3. キューファイル
キューに必要となるディスク容量を見積もります。
メッセージ平均サイズ、メッセージ・ヘッダーのサイズ、最大メッセージ滞留数をもとに概算します。
以下はこれまでの算出の考え方を踏まえた概算のための式です。
キューごとに必要サイズを概算し、積み上げて、ディスク容量を見積もります。
<ディスク容量> = <最大メッセージ滞留数> × <メッセージ平均サイズとメッセージ・ヘッダーのサイズ(500bytes)の合計を 512bytes で切り上げたサイズ>
最大メッセージ滞留数には、例えばネットワーク障害でキューからのGET処理が進まない場合に許容値として想定する滞留件数などを当てはめます。
2.4. ログスペース
ここでは、キューマネージャーの再起動やオブジェクト損傷からの回復時に用いられるログファイルのサイズを見積もります。
ログサイズの見積りの考え方は、ログのタイプ(循環ロギング/リニアロギング)により異なります。
リニアログと循環ログの違いなどについては、本講座第6回 「MQ運用管理と監視」を参照ください。
(参考文書) システム管理ガイド
メッセージの消失を確実に回避する (ログ)
循環ロギング使用時のログスペースの見積もり方法
循環ロギングはログファイルを再利用します。
二次ログファイル生成時を除きログサイズが増加することはありません。
ログスペースは以下のようになります。
<一次ログスペース> ＋ <二次ログスペース>
<一次ログスペース>、<二次ログスペース>の見積り方法については2.4.1を参照ください。
リニアロギング使用時のログスペースの見積もり方法
リニアロギングはログファイルを再利用しません。
一次ログスペース、二次ログスペースに加え、非アクティブな(=再始動リカバリに不要になった)ログファイルを保持するスペースも加味する必要があります。
ログスペースは以下のようになります。
<一次ログスペース> ＋ <二次ログスペース> ＋ <非アクティブなログファイルを保持するスペース>
非アクティブなログファイルを保持するスペースは運用に応じて見積もり方針を検討する必要があります。
以下は非アクティブなログファイルを定期的にログスペースから削除する運用の場合の見積もり方針の例です。
(見積り方針)
- 定期的なログファイルのメンテナンス処理の間(例えば1日)に発生するログの書き込み量から必要となるスペースを概算し、ログファイルサイズで切り上げたサイズを算出します。
(これを<一次ログスペース>と<非アクティブなログファイルを保持するスペース>に必要となるサイズと見込みます)
- <二次ログスペース>分を加えたサイズをログスペース全体のサイズとします。
パフォーマンスの観点から二次ログファイルは使用されない方が望ましいので、二次ログスペースはログ書き込み量から概算したスペースに含めず、別途そのスペースを見込むことをお勧めします。
<一次ログスペース>、<二次ログスペース>の見積り方法については2.4.1を参照ください。
ログファイルへの書き込み量の見積り方法については2.4.2を参照ください。
2.4.1 一次ログスペース、二次ログスペースの見積もり方法
一次ログスペース、二次ログスペースのサイズは、ログファイルサイズ、一次ログファイル数、二次ログファイル数によって決まります。
これらの属性はキューマネージャー作成時に指定できます。
<一次ログスペース> ＝ <ログファイルサイズ> × <一次ログファイル数>
<二次ログスペース> ＝ <ログファイルサイズ> × <二次ログファイル数>
ログファイルサイズは、一次ログファイル、二次ログファイルで同一となります。
二次ログファイルは、一次ログスペースが足りなくなった場合に生成され、一時的に使用されます。
ログファイルサイズ、一次ログファイル数、二次ログファイル数のデフォルト値と指定可能な最大値は以下のとおりです。
| | デフォルト値 | 割り当て可能な最大値 |
|---|
| UNIX | Windows |
|---|
| ログファイルサイズ | 16 MB | 約 256 MB | 約 256 MB | | 一次ログファイル数 | 3 | 510(*1) | 254(*2) | | 二次ログファイル数 | 2 | 509(*1) | 253(*2) | | 合計のログスペースサイズ | 80 MB | 約 128 GB | 約 64 GB |
(*1)一次ログファイルと二次ログファイルの合計数の最大は511となります。
(*2)一次ログファイルと二次ログファイルの合計数の最大は255となります。
(参考文書) システム管理ガイド
WebSphere MQ のログのデフォルト
スリープ処理やDBアクセス待ちなどによる長時間にわたるトランザクションは、ログファイルの開放タイミングに影響します。
(未完了のトランザクションのログを含むログファイルは開放されません)
メッセージのサイズや、長時間にわたるトランザクションの有無などにより一次ログスペース、二次ログスペースに必要になる容量は異なります。
以下は一次ログスペース、二次ログスペースの見積り方針についての一例です。
- 通常運用において二次ログを必要としない十分なスペースを一次ログスペースに割り当てる。
- 想定以上のログ出力や、ログファイルの開放の遅れに対してどの程度の範囲を許容すべきかを考え二次ログスペースを検討する。
ログファイルへの書き込み量の見積り方法については2.4.2を参照ください。
以下の参考文書のログファイルサイズ、ログファイル数についてのガイドに基づいた設定を検討のスタート・ポイントとする方法もお勧めです。
トランザクションレートによっては大きすぎる、または小さすぎる可能性がありますので、想定のトランザクションレートを照らし合わせの上、検討ください。
参考文書に記載の推奨のスタート・ポイント
ログファイルサイズ：約 256 MB(ログファイルの最大サイズ)
一次ログファイル数：10
二次ログファイル数：10
合計のログスペース：約 5 GB
(参考文書) Configuring and tuning WebSphere MQ for performance on Windows and UNIX
2.4.2 ログファイルへの書き込み量の見積り方法
ログファイルへの書き込み量の見積りは、それぞれのログレコードのサイズの積み上げによって行います。
ログレコードのサイズは操作によって異なります。マニュアルに記載の表にもとづいて概算します。
(マニュアル抜粋)
| 操作 | サイズ |
|---|
| 持続メッセージの書き込み | 750 バイト + メッセージ長
メッセージが大きい場合、これは 15700 バイトのセグメントに分割され、それぞれのセグメントに 300 バイトのオーバーヘッドがかかります。 | | メッセージの読み取り | 260 バイト | | 同期点、コミット | 750 バイト | | 同期点、ロールバック | 1000 バイト + 12 バイト (ロールバックされる読み取りまたは書き込みごとに) | | オブジェクトの作成 | 1500 バイト | | オブジェクトの削除 | 300 バイト | | 属性の変更 | 1024 バイト | | メディア・イメージの記録 | 800 バイト + イメージ
イメージは 260 000 バイトのセグメントに分割され、それぞれのセグメントに 300 バイトのオーバーヘッドがかかります。
| | チェックポイント | 750 バイト + 200 バイト (各アクティブ作業単位ごとに)
パフォーマンス上の理由でバッファーに入れられている、コミットされていない書き込みまたは読み取り用に、さらに他のデータがログに記録される可能性があります。 |
(参考文書) システム管理ガイド
ログのサイズの計算
ログ書き込みが発生する契機を以下の3つに分け、ログレコードのサイズや考慮点について説明します。
- メッセージの読み書き(MQPUT/MQGET)により発生するログレコード(2.4.2.1で説明)
- 運用管理オペレーションにより発生するログレコード(2.4.2.2で説明)
- チェックポイント生成により発生するログレコード(2.4.2.3で説明)
2.4.2.1. メッセージの読み書き(MQPUT/MQGET)により発生するログレコード
以下のログレコードが対象になります。
- 持続メッセージの書き込み
- メッセージの読み取り
- 同期点、コミット
- 同期点、ロールバック
持続メッセージの書き込み/メッセージの読み取り
(ローカル接続およびクライアント接続の場合)
業務アプリケーションの読み書きのログ出力量を見積もります。
- 業務アプリケーションによる1MQPUTに対して、1MQPUTのログレコード出力を見込みます。
- 業務アプリケーションによる1MQGETに対して、1MQGETのログレコード出力を見込みます。
(キューマネージャー間接続の場合)
業務アプリケーションの1MQPUTに対して、送信側MCAによる1MQGET(トランスミッションキューからのMQGET)、受信側MCAによる1MQPUT(宛先キューに対するMQPUT)が発生します。
業務アプリケーションの読み書きに加え、MCAの読み書きのログ出力量を見積もります。
- 業務アプリケーションによる1MQPUTに対して、1MQPUT+1MQGETのログレコード出力を見込みます。
(業務アプリケーションによるMQPUT発行後、MCAがトランスミッションキューに対しMQGETを発行している分を加味します)
- 業務アプリケーションによる1MQGETに対して、1MQPUT+1MQGETのログレコード出力を見込みます。
(業務アプリケーションによるMQGET発行前、MCAが宛先キューに対しMQPUTを発行している分を加味します)
なお、非永続メッセージはログ出力の対象とはなりません。
1回の操作あたりのログレコード量は、以下のとおり見積もります。
MQPUT： 750 bytes ＋ メッセージ長 (分割されない場合)
MQGET： 260 bytes
同期点、コミット/同期点、ロールバック
ロールバックの場合、トランザクションに含まれるMQPUT数、MQGET数によって見込まれる出力量は異なります。
1回の操作あたりのログレコード量は、以下のとおり見積もります。
コミット： 750 bytes
ロールバック： 1,000 bytes ＋12 bytes × <1UOW内のMQPUTとMQGETの数>
2.4.2.2. 運用管理オペレーションにより発生するログレコード
以下のログレコードが対象になります。
- オブジェクトの作成
- オブジェクトの削除
- 属性の変更
- メディア･イメージの記録
オブジェクトの作成、削除、属性の変更
一般的には、通常運用においてオブジェクトの作成、削除、変更は、発生しない、または頻繁には発生しないと考えられるので、多くの場合考慮は不要です。
発生頻度が高い場合は、見積もることを検討ください。
1回の操作あたりのログレコード量は、以下のとおり見積もります。
オブジェクトの作成： 1,500 bytes
オブジェクトの削除： 300 bytes
属性の変更： 1,024 bytes
メディア･イメージの記録
メディア・イメージの記録はログのタイプがリニア・ロギングの場合にのみ実行できます。
この操作を行う場合は、ログ出力量を見積もることを検討ください。
ログ出力量の一般的な見積もりのガイドはありません。
2つの見積りの方法例を紹介します。運用などを踏まえて見積りの方法を検討ください。
なお、メディア・イメージには滞留メッセージも含まれます。メディア・イメージの記録は、できるだけキュー内のメッセージを取り除いた上で取得することをお勧めします。
(例1)キューファイルサイズからログ出力量を見積もる
多くのメッセージが滞留している状態でのメディア・イメージの記録も想定し、キューファイルサイズに安全率を加味したサイズをログ出力量として見積もる。
(例2)実際にメディア・イメージの記録を行いログ出力量を見積もる
メディア･イメージの記録によるログファイルの切り替え回数からログ出力量を概算し、安全率を加味したサイズをログ出力量として見積もる。
2.4.2.3. チェックポイントによるログサイズの増加
以下のログレコードが対象になります。
チェックポイントとは、ログに記述されているレコードとキューのレコードが一致する時点 (ポイント) で、以下のような条件で発生します。
- 10,000回のログ・レコード出力ごと
- キューマネージャーの起動・停止時
- ログ・スペースが不足してきたとき
(参考文書) システム管理ガイド
チェックポイント機能を使用してリカバリーの完了を確認する
1回の発生あたりのログレコード量は、以下のとおり見積もります。
750 bytes ＋ 200 bytes × <アクティブなUOWの数>
<ログ出力量の概算見積り例>
業務アプリケーションの稼動により、1日に出力されるログの出力量を見積もる例です。
(見積もり前提)
- キューマネージャーの起動/停止は日次運用項目ではない
- オブジェクトの作成・削除・属性変更は発生しない
- メディア・イメージの記録は行っていない
- キューマネージャー間接続はない
(業務アプリケーションの特性)
- すべてのMQPUT,MQGETがUOWに含まれており、永続メッセージである
- メッセージの平均サイズ(メッセージ・ヘッダー含む)：2 KB
- 1日あたりのMQPUTのトランザクション数：7,200
- 1UOWに含まれるMQPUTの数：4
- バックアウトが発生するMQPUTのトランザクションの割合：5%
- 1日あたりのMQGETのトランザクション数：7,200
- 1UOWに含まれるMQGETの数：4
- バックアウトが発生するMQGETのトランザクションの割合：5%
- アクティブなUOW数(平均)：4
(A)メッセージの読み書き(MQPUT/MQGET)により発生するログ出力量
ログ出力量
＝ <持続メッセージの書き込みによるログ出力量> ＋ <メッセージの読み取りによるログ出力量>
＋ <コミットによるログ出力量> ＋ <ロールバックによるログ出力量>
＝ ( 750 + メッセージの平均サイズ ) × <MQPUT回数/日> ＋ 260 ×<MQGET回数/日>
＋ 750 × <コミット回数/日> ＋ ( 1000 ＋ 12 × <1UOWあたりのMQPUT数/MQGET数> ) × <ロールバック回数/日>
＝ ( 750 ＋ 2,048 ) × 28,800 ＋ 260 × 28,800 ＋ 750 × 13,680 ＋ ( 1,000 ＋ 12 × 4 ) × 720
＝ 80,582,400 ＋ 7,488,000 ＋ 10,260,000 ＋ 754,560
＝ 99,084,960
(B)チェックポイントにより発生するログ出力量
ログ出力量
＝ ( 750 bytes ＋ 200 bytes × <アクティブなUOWの数> ) × <チェックポイント発生回数(*1)>
＝ ( 750 + 200 × 4 ) × 8
＝ 12,400
(*1)チェックポイント発生回数
＝ <1日に出力されるログ・レコード数> ÷ 10,000
＝ ( <MQGET数> ＋ <MQPUT数> ＋ <トランザクション数(コミット、およびバックアウトの数)> ) ÷ 10,000
＝ ( ( 7,200 × 4 ) ＋ ( 7,200 × 4 ) ＋ ( 7,200 ＋ 7,200 ) ) ÷ 10,000
＝ 7.2
≒ 8
1日のログ出力量
ログ出力量
＝ (A)メッセージの読み書き(MQPUT/MQGET)により発生するログ出力量 ＋ (B)チェックポイントにより発生するログ出力量
＝ 99,084,960 ＋ 12,400
＝ 約95 MB
3 メモリー容量
MQが使用するメモリー容量の見積もりを行います。
3.1. 対象項目
以下の項目についてメモリーの使用量を見積もります。
- キューマネージャーのシステム・プロセス
- チャネル・プロセス
- キュー
- ログ・バッファー
- ユーザー・アプリケーション
設定値や接続アプリケーション数、メッセージ・サイズなどによりメモリーの使用量は変動するものであり、正式なメモリーの使用量の見積もり方法、算出式はありません。
机上での見積もりはあくまで参考値として捉え、精度の高い見積もりが必要な場合には、検証環境でのテストの結果等を踏まえた検討が必要です。
以下の文書の情報を引用していますので、詳細な情報につきましては、こちらを参照ください。
(参考文書)
WebSphere MQ for AIX V7.0 - Performance Evaluations(MP6N)
Configuring and tuning WebSphere MQ for performance on Windows and UNIX
3.2. キューマネージャーのシステム・プロセス
プラットフォームによっても異なりますが、起動直後の状態で数十MB程度使用します。
パフォーマンス・レポートによれば、AIXではデフォルト設定の場合に起動時に 90 MB 程度のメモリーの使用が見込まれます。
3.3. チャネル・プロセス
チャネル・プロセス(MCA)によるメモリー使用量は以下のような条件で変動します。
- チャネルの種類：MQIチャネル/メッセージチャネル
- 受信方法：runmqlsr/inetd
- メッセージ・サイズ
全チャネル・プロセスのメモリー使用量を積み上げて概算値を求めます。
MQIチャネル
パフォーマンス・レポートによれば、AIXでは 100 KB 以下のメッセージにおいてチャネルあたり 1 MB 以下のメモリーの使用が見込まれます。
メッセージチャネル
1つのキューマネージャーとの接続に対して1対のメッセージ・チャネルとトランスミッションキューのメモリーの使用を見込みます。
トランスミッションキューのキュー・バッファーのサイズにもよりますが、MQIチャネルの2倍+トランスミッションキュー分と考え、1つのキューマネージャーとの接続に対してMQIチャネルの2～3倍程度のメモリーの使用を見込む見積もり方法が考えられます。
パフォーマンス・レポートのテストにおいて、AIXでは 2 KB の非永続メッセージを処理する際のメモリー使用量は 690 KB でした。
3.4. キュー
キューは、オープンされるとメモリーを使用します(オープンしているアプリケーションの数には依存しません)。
よって、同時にオープンされるキューの数から使用量を積み上げて概算値を求めます。
キューのメモリーの使用量はキュー・バッファーのサイズをもとに見積もります。
キューはそれぞれ非永続メッセージ用のキュー･バッファーと永続メッセージ用のキュー・バッファーを持ちます。
キュー･バッファーのデフォルトサイズは以下のとおりです。
| | 32bitキューマネージャー | 64bitキューマネージャー |
|---|
| 非永続メッセージ用キュー・バッファー | 64 KB | 128 KB | | 永続メッセージ用キュー・バッファー | 128 KB | 256 KB |
キュー・バッファーのサイズはパフォーマンスに影響を与える場合があります。
キュー･バッファーのサイズに応じて見積もってください。
なお、キューはキュー･バッファーとは別に、滞留しているメッセージ数に応じたサイズのメモリーを使用します。
経験上、1メッセージあたり数百バイトと考えられますが、そのサイズについての正式な記述はありません。
多くのメッセージ滞留が想定される場合は、この点も考慮して、大きめのサイズを見積もってください。
3.5. ログ･バッファー
ログ・バッファーのデフォルトのサイズは 2 MB で、最大サイズは 16 MB です。
ログ・バッファーのサイズはパフォーマンスに影響を与える場合があります。
可能な限り大きな領域を割り当てることを推奨します。
3.6. ユーザー・アプリケーション
ユーザー・アプリケーションがMQと通信することで発生するメモリー使用量についての正式な算定式はありません。
チャネルはトランスミッションキューからMQGETしたり、宛先キューにMQPUTする「MQアプリケーション」の一つと考え、
チャネル・プロセスのメモリー使用量と同等と仮定して計算する方法が1つの方法と考えられます。
例えば、チャネル・プロセスのメモリー使用量を1MBと見積もっている場合、
同時接続アプリケーション数が100の場合、ユーザー・アプリケーションのメモリー使用量を 100 × 1 MB ＝ 100 MB と見積もります。
4 その他のリソース
CPUなどその他のリソースに対し検討します。
スループット、レスポンスタイムといった性能要求を満たすためには十分なリソースを用意する必要があります。
4.1. 見積もり方法
パフォーマンス・レポートや検証環境でのテスト結果をもとに、実際の環境に一番近いテストケースを選び、マシンスペックの比率から処理性能を見積もります。
CPU数が倍になったからといって、システム全体としての処理性能が倍になるとは限りませんので、余裕を持った見積もりが必要となります。
以下、レスポンスタイムやスループット向上のために必要なリソースを考える上で、注意すべきポイントを挙げます。
4.2. リソース見積もりに関する注意点
4.2.1. CPU
システムの処理性能がCPUの処理能力に依存するのは、特に以下のようなケースです。
- 非永続メッセージを扱う
ディスクアクセスをせず、メモリー上で処理を行うためです。
- キューへのメッセージ滞留がない
非永続メッセージでも、キュー・バッファーを超えた分についてはディスクI/Oが発生し、この影響を受けます。
テストケースを元にして必要な処理性能を概算するには、CPUのOLTP値やSPEC INTなどのベンチマーク実績値を使用します。
例えば、12CPUのOLTP値が120で4CPUのときの値が40だった場合、
12CPUのときに60件/秒の処理性能があれば、4CPUでは 60 × ( 40 ÷ 120 ) ＝ 20件/秒
の処理性能を想定します。
一般的にCPU数の追加は、並行処理能力を高め、スループットの向上が期待できます。
一方、より処理能力の高い(動作周波数が大きい、内部アーキテクチャが優れている)CPUの使用は、レスポンスタイムの向上が期待できます。
必要に応じてCPUリソースを増強できるようなモデル選択が重要となります。
なお、スリープ、DBMSのロックによるアクセス待ちなどが発生している場合は、CPUを増強してもトータルとしての処理性能の向上は見込めません。
4.2.2. ディスクI/O
ディスクI/Oが処理性能に大きな影響を与える場合があります。
- 特に永続メッセージを扱う際には必ずログ書き込みが発生するため、高速なディスク装置の使用を検討してください。
- I/Oを並列化して速度向上を図るため、ログを配置するディスクとキューなどのデータを配置するディスクは極力分けてください。
- ディスクI/Oをl極力抑えるため、各種バッファーについて適正なサイズの検討を行ってください。
4.2.3. ネットワーク
ネットワーク帯域がレスポンスタイムに大きな影響を与える場合があります。
- メッセージのサイズ、ピーク時のレート(件/秒)からピーク時のトラフィック量を算出し、必要となるネットワークの帯域(実効帯域)を検討してください。
参考文献
著者について  | | | 深澤 剛, テックライン, IBM |
記事の評価
| 
