富士通メインフレームの本質を見る~性能改善の現場

第5回 B社での事例(2)~オンラインの性能改善

概要

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

登山のたとえ話しの続きですが、性能改善の失敗にはいくつかのケースがあります。①麓の樹海から抜けられない、②山頂を目指したが途中で断念、③ヘリコプターをチャーターしたが着陸できず、④手前の低い山に登って満足した、等々。
 
 情報の入手が困難だからといって、手ぶらで登山しようというのは無謀です。
 
 登山をするのはお客様自身で、無事に頂上に到達するためのお手伝いをすることが私たちの役目です。しかし、私がメーカにいたときには④に誘導することが多かったかもしれません。
 
目次
5.1 状況の把握
5.2 麓の樹海に迷い込む
5.3 改善への歩み
5.4 学び

5.1 状況の把握

前回の図8に示した通り、オンライン業務は問題が山積みです。
 
 前回の性能データ(PDL)の誤差の件もあるので、性能評価プロセス(第2回-図3)の測る化から一つ一つ確認をしながら進めることにしました。規模が大きいため、性能データを取得する環境を作ることも、またそのデータを検証することも大変です。そして、想定外のことは色々起きるものです。例えば、
 

退避している性能データ(SMF)に抜けがあった
大規模な基幹システムなので、最初は信じられませんでした。実行されているはずのジョブの情報が見当たらず、おかしい、不思議だと悩み、データを調べ続けた結果、データの退避に不備があり歯抜けになっていたことが判明しました。20年も気づかなかったのでしょうか。

性能データ(AIM課金統計情報)の時間が9時間ずれている
データの相互確認で不備が見つかり、原因を調査していたら時間がずれていることが判明。初めてのケースでとても大変でした。

正常に動作しないツールがある
性能データは、今でも毎年少しずつ機能が追加されています。そのため、ごく稀に見える化ツールが正常動作しないことがあります。EXCELなどの制限にも注意が必要です。

性能データに何かおかしい数字がある
利用者が細部のパラメタまで調整したとしても完璧な性能データはありません。よくあることです。

必要なときにすぐにデータを取得でき、見える化のツールも一通り動くようになればひと安心です。この検証に一週間かかりました。
 
さて、前述のAIM課金統計情報を分析すると、1トランザクションごとの処理時間(レスポンス時間)とCPU時間がわかります(図10)。
図10 処理時間とCPU時間の関係
グラフ中央にある点線より上は実際に処理をしていて遅いプログラム、点線より下は待たされていて遅いプログラムと考えられます。即ち、前回の図8で最大処理時間が30秒を超えるプログラムは複数ありましたが、実際に遅いものはA◆とB▲であるとの仮説が立ちました。
 

5.2 麓の樹海に迷い込む

性能評価プロセスの問題抽出、原因分析を始めると、暫定的な改善案も出てきます。プログラムの動作環境の改善(バッファサイズの最適化など)はお客様主体でできるので並行して進めていくことになりました。逆に、データベースやプログラムの改善は手間がかかるので後回しとなりました。
 
 暫くすると、様々なバッファにおいて不足回数を0にすることに注力し、本来の目的が見えなくなる「手段の目的化」が始まりました。
 
 更に、バッファを拡張したことによりCPU使用量が増加するという逆効果の現象も発生しました(バッファを大きくしすぎてメモリサーチが増えたため)。まさに、山頂が見えない麓の樹海を地図もなくさまよい歩いている状況です。
 
 そこで、あらためて課題設定をするために問題の整理をしました(図11)。
図11 問題点の整理
左上の問題を改善することが目標のベースとなります。そのためには、処理時間が長いプログラムの改善とデッドロックの削減が課題としてあがりました。
 

5.3 改善への歩み

 図10で示されたプログラムA、Bについて可能な限りのデータを使い、徹底的に調べつくした結果、以下のことがわかりました。
 
    • 処理時間が長いのは、CPU時間が長いからである(処理時間の最大2/3)。これに加え、排他待ちが発生すると更に処理時間は長くなる。
    • CPU時間が長いのは、データベースの排他制御処理に費やしている可能性がある。
    • 特定のデータベース(AIM/VSAM)に対して多量のアクセスがある。そのため、処理が重なると排他待ちが発生する確率が高い。
    • ここでデッドロックも多発している。
そこで考えた手は以下の通りです。
 

データベースの排他単位をページからエクステント(ファイル)に変える。
参照系のアクセスについては排他をかけず運用で対応する。
少しでも排他占有の時間を短くするために、最高の優先順位で実行する。

   デメリットはもちろん処理が重なると必ず排他待ちが発生することで、常識的には考えられない方法です。お客様には内容を十分に理解して頂くことで、積極的に取り組んでもらうことができました。結果を図12に示します。
図12 処理時間とCPU時間の関係(改善後)
図10と見比べて下さい。CPU時間はおよそAが50%、Bが40%削減されました。処理時間が短縮することで、排他待ちもデッドロックも発生しにくくなりました。処理時間はお世辞にも速いとは言えませんが、メッセージの滞留やサーバ間のタイムアウトは無くなったようです。
 

5.4 学び

 「できることから始めよう」と号令をかけることがあります。性能改善のシーンでは目標を達成しないと意味がないことも多く、下手をするともぐら叩きの状態に陥ることがあります。目の前に山があるからといって、何の準備もせずにまずは登り始めるのは無謀です。
 
 目標(山頂)を確認し、問題点を整理して課題を設定することがまさに地図を作ること、解決策を立案することが登山のルートを決めることに相当します。性能評価プロセスを着実に実行することが重要だとあらためて感じます。
 
                                                                                                                                                                    以 上

連載一覧

コメント

筆者紹介

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

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

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回にわたり掲載。

バックナンバー