【2008/10/21 original author TAKAO】
思想
パフォーマンスチューニングというと、「とにかく早くなるんだろーな」と素人は考えがちです。自宅のパソコンなら早くするためになんでもやれます。オーバークロック、高価なグラフィックカード、早いディスク、等等。
が、仕事でやるパフォーマンスチューニングは違います。まず、「どこまでチューニングすることがゴールなのですか？」をはっきりさせることです。チューニングはボトルネックを発見し、解消に努めます。しかし、ひとつのボトルネックを解消すると次のボトルネックは必ず起きます。それゆえゴールがひつようなのです。
以上を踏まえて、以下の個別要素でボトルネックが起きているかを検討してください。
スケジューリング
汎用機はその名のとおり、汎用ではあります。古（いにしえ）の昔はひとつのプロセッサーで、バッチもオンラインもTSOも動かしており、それらにリソースを絶妙に配分するためにSRMのパラメータをいじるのが偉い、とされていました。プログラミングでもいかにメモリを使わないかでずいぶんトリッキーなことをやっていました。しかし時代は変わりました。CPU資源は潤沢にあり、メモリーはディスク並みの容量を誇ります。こういう時にスケジューリングとは何を考えるべきでしょうか？基本的な「CPUバウンダリー（いっぱい使う、くらいの意味）」なジョブなのか「I/Oバウンダリー」のジョブなのかの考慮くらいかなぁ、と思います。そのMVSシステムで動かすのは主にどちらだろ？くらいは把握しましょう。これは大事なことで、I/Oバウンダリーは後述する、I/Oのチューニングで解決しますが、CPUバウンダリーでCPUが100%を振り切るとそれ以上リソースがない、ことは考慮すべきです。あちこちをチューニングして、100%CPUが使われるようになってしまったら、これ以上の負荷はかけられない、ということです。大きな意味でのジョブのスケジューリングをするしかなくなります。また、最近、VM、LPARの使用が多いと思いますが、魔法の杖ではありません。システム全体として負荷を考慮するべきであることはいうまでもありません。
DASD I/O
友人のDisk屋がいっていたことですが、「CPU(ナノ単位)を1秒とすれば、Disk(ミリ単位)の返事は1日」それゆえ効果がもっとも出やすいです。しかも汎用機はオープン系と違いチャネルの力により相当なI/Oをこなせます。とはいえ、ページングと一般のI/Oについてはよく考えたほうがいいです。
ページングはページデータセットの置かれたボリュームにほかのデータへのI/Oがないのであれば、通常のI/Oとは異なる方法がとられます。MVSはCCW（チャネルコマンド）を作りチャネルに実行させますが、必要な処理を行わせた時点でチャネルにストップをかけます。そしてさらにページングが必要な場合、CCWを作りチャネルをスタートします。つまりチャネルからすると無限に続くCCWを実行しているようなイメージになります。しかもページデータセットは４K単位のスロットから構成されているため、データをもってくる場所を計算で割り出せます。それゆえページングは抜群に早いI/Oなのです。10年以上前、私が現役でチューニングをやっていた時ですらVMテストシステムでは一秒間に200ページングしていてもゲストOSユーザーはまったく不満を感じていませんでした。ページングはディスクの場所さえ慎重に考えれば恐れることはないのです。VSAMリニアデータセットなどは、まさにこの動きを利用したファイルシステムです。ページングの回数よりも、レスポンスタイムを監視しましょう。
通常のI/Oはそこまではいきません。例外なのはDBMSのライトアヘッドログ（トランザクションコミットの度に一時的に書かれるデータセット）で、これらはたいていヘッドの動きを最小限にし、独自のCCWで読み書きするようになっています。ヘッドが動かない分、ミリ秒単位での猛烈な速度で動きます。RAIDであれば、キャッシュをオーバーフローしない範囲でしょうか。
さて、通常のI/Oについて考えるのであれば、レコードフォーマットがどうであれ、転送の単位はブロックですからブロックはできるだけ大きくとったほうが、一度の転送でのデータ量は増えます。昔はトラック上にブロックがどうレイアウトされるかも考えていましたが、RAIDになってから無意味なので気にしなくていいと思います。ただし、データセットのエクステンションがめちゃくちゃに多く、実はディスクのヘッドが飛び回っているということもありますので、エクステントが多いデータセットは時々「Defrag」じゃなく、アロケーションサイズを見直し、コピーしてあげましょう。（除くDB）
その他のI/O
RMFでI/Oキューの長さは調べておいてください。たとえばコンソールは遅いデバイスです。にもかかわらずコンソールのメッセージがはけないと、MVSは新しい作業を開始しません。めちゃくちゃにメッセージが出力されていて足をひっぱっていることはあります。対策は、EXITやMPFLSTなどによりメッセージを削減することです。
メモリ
これはチューニングするというよりも、現状を把握しておいてください。安直にページ固定していないかを調べておきましょう。ページングは恐れることはないですが、ページ固定をバンバンかけられるとページングが不必要に増えることは、簡単に予測できるでしょう。ボトルネックは以外にこういうところにあります。なお、一時的に大量にページが要求される状態（フリーのページスロットが極端に減ってしまう場合）に陥った場合、なんとかジョブのスケジュールを変更してください。いくらMVSといえども、リアルメモリーがなくなってしまうとどうしようもありません。
CPU
CPUのチューニングというものは、バッチ処理以外には、あまり意味がないように思います。シスプレックス構成をとって、システム全体でディスパッチを考える場合にはいるときでしょうが、それはすでにこういうチューニング入門を超えた議論になるかと思います。バッチの場合、長くかかりそうなものはパフォーマンスグループを分けてディスパッチのプライオリティをあらかじめ下げます。理由はスループットをを早くしたいからです。スループットというのは、「一定時間に何件処理したか」という考え方です。対する考え方は「ターンアラウンドタイム」です。これは「とあるジョブがどれくらいの時間で終わったか」です。
一般的に長いジョブであればあるほど、1秒はどうでもよくなります。それゆえ、長いジョブには率先してCPUを割り当てる必要はないのです。TSOでもバッチをサブミットするのであれば、パフォーマンスグループは下げておきましょう。
CPUのチューニングについては、むしろ毎月の平均とピークの使用率を監視しましょう。キャパシティの管理をすることはきわめて重要です。なんとなく、通常時で３０％程度、ピークで８０％なんていうオープン系ののりで見ていてもいいのではないでしょうか。
サブシステム（IMSとか)
あらかじめいっておきますが、サブシステムのトランザクション処理が遅い場合、OS側でできることは限られます。というのも、各々自分の中でトランザクションのスケジュールを行っているからです。(SUSPEND,RESUMEマクロなんてもんを使いまくってます）用件をまとめてもらわないと、なかなか対処しずらいところです。
これらのことは、RMFがあればできることで、高価な測定ツールは管理職には受けるでしょうが、チューニングにはあまりいらないように思います。
【2008/10/21 original author TAKAO】