SysAdmin's Group システム管理者の会
日本最大規模の
システム管理者のネットワーク

運用ノウハウを学ぶ

システム管理に関わるベーシック情報やトレンドをご案内します!

富士通メインフレームの本質を見る~性能改善の現場 第6回 B社での事例(3)~CPUのムダを無くす
2009年03月18日 12:44

 1990年代、オープン化の波が押し寄せメインフレームが目に見えて減り始めた頃の話しです。私はCPUのダウングレードを支援するサービスを企画し上司に提案したのですが、話しを聞くまでもなく却下されました。移行パス(CPUリプレースの考え方、第1回を参照)に従ってリプレースを推進することが原理原則であり、ダウングレードなど考えることすら許されないことを知りました。

 私がメーカを離れて最初に着手したことはCPUダウングレードの方法論とそのときの性能を予測する手法を確立することでした。今ではCPUの性能を落としてもサービスレベルをコントロールして運用できるのがメインフレームの強みだと考えています。

6.1 業務と直接関係ない処理で意外とCPUを使っている
 基幹系のシステムであっても業務と直接関係のない処理で大量のCPUを使っていることがよくあります。今まであった例を紹介します。

    • 本稼動直後、異常なく動いているかを見たくてコンソールをたくさん立ち上げた
    • CPU負荷の高い繁忙期に、現場で今日の売上進捗を確認するためにENTERキーにシールを貼って画面を更新させていた
    • 業務担当者にリアルタイムモニタを開放していた
    • サーバとファイル転送をするとき、ホストで文字コード変換を行っていた
    • 使わないログを取得していた   等
ハードウェアの性能がよくなり問題が表面化しにくくなったため、運用担当者は意外と気付かないものです。CPUのムダを探し改善を進めた事例を紹介します。

6.2 アプリケーションでのCPUのムダ
 COBOL言語を使ってファイルやデータベースを読み、処理ロジックを通り、結果をファイルやスプールに出力しようとすると、富士通のメインフレーム上では(*1)、CPUとI/Oのバランスにシステム共通の傾向が出ることを発見しました。これが度々登場しているCPU/IO頻度分析の基本となる考え方です。技術者の経験から築かれたDNAのようなものであり、意図的にバランスを崩そうとしても簡単にはできません。

 CPU頻度が高くなる原因としては以下のようなものがあります。

    • 非効率なテーブルサーチ
    • 不必要なループ
    • 無駄なデータベースマクロの発行
    • 適切でないSQL命令の発行   等
実際には、COBOLソースから見えないところでもCPUとI/Oのバランスがくずれることがあります。代表的な原因を表4にまとめます。
表4 CPUとI/Oのバランスがくずれる原因
image10.PNG
*1 ハードウェアのアーキテクチャ、OSやミドルウェアの作りを考慮した考えかたであり、オープン系では残念ですが適用できません。
*2 今も時々対応しますので内容を紹介します。
COBOLでNORENT(省略値、目的プログラムに再入可能属性を与えない)、LKEDでRENT(ロードモジュールに再入可能属性を与える)、DYNAMIC(動的リンク属性を与える)にしてモジュールを呼ぶと2回目以降も直接分岐ができずSVC45を発行してしまいます。
6.3 バッチ処理でのCPU削減
 B社ではオンラインの性能改善が完了した後、バッチの性能改善に着手しました。夜間バッチ時のCPU使用状況を図13に示します。
090318_1.png
図13 夜間バッチ処理時のCPU使用状況
 目的は夜間バッチ時間の短縮ですが、CPUに十分な余裕がないため、並行してCPUのムダを削減する必要がありました。

 今までは結果的にCPU時間を削減したところはありましたが、今回はCPU頻度の高いジョブをターゲットにして、CPU時間を削減するという挑戦的な試みです。CPU頻度が高いということはCPUの使い方にムダがあり、改善できる確度が高いと判断しています。

 CPU時間の長いジョブについてCPU/IO頻度を算出した結果を表5に示します。
表5 CPU時間の長いジョブのCPU/IO頻度
image12.PNG
    (1) CPU時間が最も長くCPU/IO頻度も非常に高いためチューニングの第一候補にあがりましたが、ロジックを追える人が退職してしまい保留となりました (よくあることです)
    (2) ループしているプログラムロジックを改善。CPU/IO頻度も790→29に改善
    (3) SORT処理を改善
    (4) 参考 前回紹介したオンラインジョブ。CPU/IO頻度は193→83になったがまだCPU頻度が高いく改善の余地があることがわかります

 もちろんプログラムの改善はお客様にお願いしています。プログラムのどこに問題があるかは「仮説検証型性能解析」(図14)により、迅速化と作業品質の向上を実現することができます。

090318_2.png

図14 仮説検証型性能解析

以 上 

運用研究レポート
富士通メインフレームの本質を見る~性能改善の現場

SEが何ヶ月も調査しているはずなのに一向に解決しない性能問題。ギブアップ寸前の問題の相談を受け、解決に導いていくプロセスを現場の視点で紹介します。性能改善の現場ではメインフレームの本質が見えてきます。

記事一覧へ
筆者紹介

有賀 光浩(ありが みつひろ)



株式会社アイビスインターナショナル 代表取締役

1963年生まれ。1985年富士通株式会社入社。1992年~2003年まで社内共通技術部門で国内外のメインフレームの性能コンサルティングを実施、担当したシステム数は1,000を超える。2000年からは大規模SIプロジェクトへの品質コンサルティング部門も立ち上げた。

2004年に株式会社アイビスインターナショナルを設立。富士通メインフレームの性能コンサルティングとIT統制コンサルティングを行っている。

技術情報はhttp://www.ibisinc.co.jp/で公開中。富士通やSI’erからのアクセスが多い。

当サイトには、同名シリーズ「富士通メインフレームの本質を見る~IT全般統制の考え方」を3回、「富士通メインフレームの本質を見る~バッチ処理の性能評価と改善事例から」を6回、「富士通メインフレームの本質を見る~CPUリプレースの考え方」を3回、「富士通メインフレームの本質を見る~性能改善の現場」を7回、「富士通メインフレームの本質を見る~2009年度の最新トッピックス」を3回、「富士通メインフレームの本質を見る~2008年度の最新トピックス」を2回にわたり掲載。

  • 新着Q&A
  • 最新の回答
回答数:22019年11月12日

システム管理者認定講座<全コース共通>試験のみ受験希望の方はこちら

動画で見るセミナー
動画で見るセミナー

毎年恒例となった「システム管理者の会」の年に一度の大イベントとなる「システム管理者感謝の日イベント」の模様をお届けします。 今年のテーマは、「集まれ若いチカラ!システム管理者のための夏期講習!!」です。

個人情報保護方針
運営者につい て
利用規約
サイトマップ