IBIS Internationalロゴ

コラム：　GSの特長を生かした性能評価とは


ホーム コンサルティング＆サービス 会社概要 お問合せ 技術情報 内部統制 サイト情報 用語辞典 ライブラリ

　富士通メインフレーム(GS21,GS,PRIMEFORCE、以下GSと略す)のハードウェアは、1990年代と比べると進歩をしています。
　1995年にはCMOSプロセッサを採用したGS8000シリーズ、2002年にはGS21シリーズが発表されました。
　ディスク装置については、初のアレイディスクとして1995年にF6493、1997年にはF6495、2003年にはETERNUS6000が出荷されています。
　搭載メモリ量は、最小構成で見ても1995年頃のGS8200シリーズで28MB〜252MBだったのが、現在のPRIMEFORCE4000シリーズでは256MB〜4GBに
　拡大しています。
　性能評価の基本は不変ですが、ハードウェアの特性によりボトルネックになりやすい箇所は変化しています。
　もしも1990年代の性能評価を続けていると、問題ないところを深く分析していたり、一番大切なところを見落としたりする危険性が高くなります。
　本コラムでは、GSの特長を生かした性能評価について紹介します。

● (1)　ページング過負荷、スラッシング
　システム（OS）のオーバヘッドを評価することは性能評価の基本ですが、GS上では問題となることは滅多にありません。
　特に、ページングによるCPUオーバヘッドはほとんど気にする必要はありません。その理由を以下に示します。
　・中小規模システム　　標準のメモリ搭載量、増設単位が大きくメモリに余裕がある。経験上、メモリが余っているシステムが過半数を占めている。
　　　　　　　　　　　　　　　CPUが小さくても、数10回/秒程度のページングなら問題なく処理できる。　(*A)
　・大規模システム　　　　搭載メモリ量が大きくなり、昔よりもページングが起きにくくなった。
　　　　　　　　　　　　　　　CPU能力が高いため、数100回/秒程度のページングは余裕で処理ができる。

　*Aについて具体例を示します。
　　GS8300　メモリ254MB　OS:XSP　・・・　PAGE-IN/OUT 54回/秒のときページングで費やしたCPU使用率は4.8%
　　GS8800　メモリ110MB　OS:XSP　・・・　PAGE-IN/OUT 49回/秒のときページングで費やしたCPU使用料は3.3%
　　　（XSPでは20%になるとシステム過負荷と認識します。）

　単純にページングがどの程度発生しているのか、それは妥当なのか評価し、
　もしも異常であれば、メモリを多量に使っているジョブを特定し、その原因を調査することが重要です。

（2011.6.2 加筆）
　GS上で動くジョブ（オンライン、バッチ、TSS/AIFすべて）が必要とする仮想メモリサイズ（≒リージョンサイズ）は普通1〜6MB程度です。
　SymfoWARE/RDBを使うとジョブ内共用バッファ、SQLスタック域、OPL域（SQL文実行環境保持域）などでリージョン（EREGION）を10MB程度
使用することもあります。
　システム内で異常に大きなリージョンを使用するジョブがあるときには、以下のような観点でチェックする必要があります。
　　・データベースに関するバッファを異常に大きく定義していないか。
　　・プログラムがAIMの規約通りに作られているか。
　　・オンラインジョブであれば、タスク数やSMQNなどの環境がどうなっているか。

　ご意見・ご質問等は 専用フォーム からお願いします。

<< ホームへ


● (2)　ディスク装置のI/Oレスポンス
　F6493以降、ディスクアレイになったので、I/Oレスポンス時間にシーク時間や回転待ち時間という概念は存在しません。

 （2011.6.2 加筆）
　例えると、今のネット環境を説明するとき、ダイアルアップの仕組みとその速度について語っているようなものです。
　あなたはそんな話、聞きますか？

　従来のディスク装置（F642xなど）のI/Oレスポンスは20〜30msでしたが、ディスクアレイでは数ms、速いものは1msを切っています。
　そのため、特定のボリュームがボトルネックになることも滅多にありません。（意図的にボトルネックにする方がむずかしい）

　I/O回数が少ないとき、キャッシュヒットしにくいのでI/Oレスポンスが遅くなるのは当然です。
　プログラムのローディング、バックアップユーティリティ、シーケンシャル処理等はデータをまとめて処理する（1I/Oのデータ転送量が多い）ので
　I/Oレスポンスが長くなります。

　I/Oが頻繁に発生し、かつI/Oレスポンスが遅い（10msはかなり遅い）ときには、キャッシュのヒット率、チャネルビジーによる影響（特にXSP）、そして
　デバイス待ち（UCB待ち）を調査します。
　
　このとき、I/Oを多量に発行しているジョブとデータセットを特定し、その原因を調査することが重要です。

 （2011.6.2 加筆）
　具体的な調査の仕方を知らないのに、調査をすることを推奨しますと言って知らんぷりすることがよくあります。
　そんなときには、「では調査してください」、「具体的にはどのように調査するのか教えてください」と返してみてみると面白いでしょう。

　ご意見・ご質問等は 専用フォーム からお願いします。

<< ホームへ


● (3)　ピーク日の選定
　ピーク日と口で言うのは簡単ですが、ピーク日の選定はむずかしく慎重に行う必要があります。
　業務のピーク日とシステムのピーク日がずれることも珍しくありません。

　オンライン業務の時間帯とバッチ業務の時間帯を定め、この時間帯の総CPU時間が最大の日をピーク日とすることがあります。
　選出したピーク日が間違っていれば、性能評価の意味がなくなってしまいますので、選出したピーク日が妥当なのか検証することが重要です。
　・業務のピーク日とずれていないか。
　・オンライン業務の時間帯であっても、CPUはバッチ処理で使われていないか。
　・バッチ業務の時間帯であっても、本番以外のジョブや異常な動きのジョブがCPUを多量に使っていないか。

　検証がむずかしいときは、ピーク日を２，３日設定したり、CPU以外のデータ（I/O回数、トランザクション件数等）からもピーク日を設定するなどの
　対応を行うべきです
　パフォーマンスグループごとに集計することもありますが、想定外のジョブが動作して多量のリソースを使っていないか検証することも重要です。

　ご意見・ご質問等は 専用フォーム からお願いします。

<< ホームへ


● (4)　ジョブの多重度
　昔は、システムが過負荷にならないようにジョブの多重度には気をつけていました。
　今のシステムではほとんど気にすることはありません。
　メモリネックだといっても、REGIONサイズ数MBのバッチジョブをスワップアウトしても効果は小さいでしょう。
　システムパラメタが不適切で、多重度が十分にあがらない方が問題です。

　SDM説明書にはバッチジョブの処理時間を以下の式で表しています。イニシエータ待ちはこの前のフェーズになります。
　　　 CPU使用時間＋CPU待ち時間
　　＋I/O使用時間＋I/O待ち時間
　　＋ページンイン待ち時間
　　＋ENQ待ち時間
　　＋物理スワップイン待ち時間
　　＋多重度調整時間

　もう少し細かくみると、多重度調整以外のスワップアウト時間、装置待ち、データセット待ち、データベースの排他待ちなども考えられます。
　バッチジョブの処理時間を評価するとき、CPU待ち、I/O待ち以外の待ちが発生していたら、この原因を調査し改善することが重要です。
　処理時間の基本はCPU使用時間、CPU待ち時間、I/O使用時間、I/O待ち時間です。
　SDMのパラメタの設定ミスは直すべきですが、本番業務の多重度を抑えようというチューニングは得策ではありません。

 （2011.6.2 加筆）
　そもそも対象のシステムはバッチジョブが何多重でCPUが100%になるのか知ることが重要です。

　ご意見・ご質問等は 専用フォーム からお願いします。

<< ホームへ


● (5)　PDLを使った性能評価
　昔はPDLを見ればよかったのですが、今ではそれ程簡単な話しではありません。
　PDLというのは、基本的にシステム資源（CPU、メモリ、DASD、バッファなど）の使用状況を取得する製品です。

　a) 日々の性能管理にて
　システム資源にボトルネックが無ければそのことがわかります。(a1)
　システム資源にボトルネックになりそうな事象があれば、それを検知することができます。(a2)

　仮にCPU使用率が100%だったとして、「CPU負荷が高いから注意しろ！」、「CPUの増強が必要！」と言われても困りませんか。
　まず、何で100%なのか原因を知ることが大切です。

　PDLだって調査できるよと思われた方、すばらしいです。
　MSPのP3レポートがあれば、ジョブの特定ができるかもしれません。PDLでP3レポート(MSP)は必須です。
　CPUを使っているパフォーマンスグループを特定しようとするかもしれません。PDLでV1レポート(MSP)、X4レポート(XSP)は必須です。
　但し、そのパフォーマンスグループでどのジョブが動いていたかはPDLではわかりません。このパフォーマンスグループはXX業務で使うと決められて
　いても、実際にそうなっているのか検証することが重要です。

　PDLだけ見ても、ボトルネックになりそうな事象の原因は簡単にはわかりません。
　並行して他の性能データの調査が必要となります。

　b) 性能上の問題が起きているとき
　その時間帯のPDLを調査することにより、システム資源上の問題があるか把握することができます。(b1)
　これが性能上の問題の原因であるかどうかは慎重に分析する必要があります。

　システム資源上の問題が見つからないこともよくあります。(b2)
　このときには仮説を立て、PDLの再調査、または他のデータを調査することが有効です。
　PDLは他の性能データと合わせて評価することでその効果が上がります。

 （2011.6.2 加筆）
　c) 年に一度の診断
　システムの特徴、脆弱性やリソースの無駄を把握するのに有効です。

　ご意見・ご質問等は 専用フォーム からお願いします。

<< ホームへ


● (6)　PDLを使った性能評価（その２）
　PDL/PDAを編集するツールは、お客様独自で作ったものから製品まで色々なものがあります。
　どのツールにもそれぞれの目的があり、価値があります。
　ツールを使われているお客様への提案です。
　一度、PDL/PDAのリストを出して、頭から眺めてみてください。（PDL/PDAに関する情報）
　必ず、知らなかったものが見えてきます。

　GSの性能評価の技術者は、ツールで編集されていないPDA/PDAを使います。
　多くのツールは、PDLの全ての情報を網羅していません。
　PDLもまた、システムの情報を網羅するものではありません。

　ご意見・ご質問等は 専用フォーム からお願いします。

<< ホームへ


2009年8月作成、2011年6月更新
株式会社アイビスインターナショナル
代表取締役　有賀　光浩
株式会社 アイビスインターナショナル株式会社 アイビスインターナショナル　134-0003 東京都江戸川区春江町4-17-12
All rights reserved, Copyright (c) IBIS International Inc. 2005-2015