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

 

本稼動直後、異常なく動いているかを見たくてコンソールをたくさん立ち上げた
CPU負荷の高い繁忙期に、現場で今日の売上進捗を確認するためにENTERキーにシールを貼って画面を更新させていた
業務担当者にリアルタイムモニタを開放していた
サーバとファイル転送をするとき、ホストで文字コード変換を行っていた
使わないログを取得していた　　　等

ハードウェアの性能がよくなり問題が表面化しにくくなったため、運用担当者は意外と気付かないものです。CPUのムダを探し改善を進めた事例を紹介します。

 

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

 

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

 

非効率なテーブルサーチ
不必要なループ
無駄なデータベースマクロの発行
適切でないSQL命令の発行　　　等

実際には、COBOLソースから見えないところでもCPUとI/Oのバランスがくずれることがあります。代表的な原因を表４にまとめます。

 

 

 

(1)　CPU時間が最も長くCPU/IO頻度も非常に高いためチューニングの第一候補にあがりましたが、ロジックを追える人が退職してしまい保留となりました　（よくあることです）

(2)　ループしているプログラムロジックを改善。CPU/IO頻度も790→29に改善

(3)　SORT処理を改善

(4)　参考　前回紹介したオンラインジョブ。CPU/IO頻度は193→83になったがまだCPU頻度が高いく改善の余地があることがわかります

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

図１４　仮説検証型性能解析

以　上