|
『富士通メインフレームにおけるパフォーマンス改善への取り組み』
１．会社概要
2010年10月にあいおい損保とニッセイ同和損保が合併し、あいおいニッセイ同和損保が設立されました。弊社は、あいおいニッセイ同和損保の100％出資のIT子会社として、グループ企業のシステム開発・保守および管理運営を行っております。
以下からは、性能改善事例を4つご紹介します。
２．事例紹介
【事例1：代理店オンラインシステムのレスポンス改善】
損害保険の取引は全て代理店が行っており、代理店オンラインシステムの使い勝手は収保に直接影響するため、非常に重要なシステムとなっています。
2003年になりますが、ヘルプデスクの障害履歴より代理店オンラインシステムにてタイムアウトと思われる事象が発生していることが判明しました。まずは、現状を把握するため調査を実施しました。
調査の結果、合併によるデータ増加に伴い、半年後にはCPU使用率がほぼ100%、その翌月には120％になる恐れがあることが分かりました。このままでは年度末に影響がでる可能性があるため、対応策を検討しました。しかし、増強には膨大なコストがかかるため、コストを掛けない方法で緊急対策を実施することになりました。実施した対策は下記4点です。
①PDLサンプリング間隔の見直し
効果としては微々たるものですが、自分たちでできることは全て実施するという観点で、性能測定を実施する際に支障が出ないぎりぎりの間隔に変更しました。
②代理店接続ミドルウェアの改修
ホストへ接続するたび、接続IDの認証を実施しています。その接続IDが肥大化して、CPU使用率が高くなっていました。1処理あたりのCPU時間はわずかでも、1日あたりの処理件数が膨大なことから効果ありと判断しました。
接続IDが管理されているテーブルの検索手法を変更しました。先頭から順に検索していたものを1万件単位でグルーピング化し、始めに属しているグループを検索したのち、順次検索をするようにしました。
③業務アプリケーションの改修
印刷業務のCPU使用率が高く、全体の約30％を使用していました。初期処理にのみ使用するルールとなっていた「INITIALIZE」命令が、初期処理以外で使用されていたので、これを廃止いたしました。またプログラムにおける走行ステップ数を測定し、1トランザクションごとに内部ソートを行っているプログラムが2本あったので改善しました。
④汎用ルーチンの改善
さらに調査をしたところ、漢字の水準をチェックする汎用プログラムがあることが分かりました。このプログラムは漢字を一文字ずつチェックしており、空白においても一文字と認識しチェックしていました。そのため、空白の場合は処理を迂回するよう変更しました。
以上の対策により、年度末には1.45倍になると想定していたCPU使用率を大幅に削減することができました。その結果、年度末におけるCPU使用率は改善前よりも下がっており、無事に年度末を迎えることができました。
【事例2：ジョブの増加とは関係のない総実行時間の増加】
2008年3月以降、ジョブ数はほとんど変わっていないにもかかわらず、総実行時間のみが増加する現象が発生しました。
前月と比較して、総エラップス時間が極端に増加していることが分かりました。調査したところ、実行月によって実行時間が極端に異なるジョブがあり、このジョブに着目して分析をしました。
分析の結果、SDMパラメータの設定が20年前のままになっており、最適値から乖離した状態になっていました。具体的には、CPUが一定時間（100ms）割当てられる時間内に7回以上のI/Oが発行されると、I/Oバウンドジョブと見なされる設定となっていました。
そのため、同じパフォーマンスグループの多くのジョブがI/Oバウンドと見なされ、一部のCPUバウンドジョブにCPUがディスパッチされない状態になっていました。
対策として、SDMパラメータをメーカ推奨値（2000回以上I/Oが発行されるとI/Oバウンドジョブと見なす）に変更しました。これにより、同じパフォーマンスグループのジョブはすべてCPUバウンドジョブとなりました。その結果、CPUが均等にディスパッチされて、特定のジョブが大幅に遅れることがなくなりました。
【事例３：メモリのサイジング】
2008年の代理店オンラインシステムの刷新により、オンラインジョブが増加し、それに伴いページイン回数が増加しました。処理効率の悪化が懸念されるため、未割当のメモリを追加し、ページイン回数の低減を図ることにしました。
調査の結果、オンラインアプリがメモリを使用すると、優先度の低いバッチジョブのメモリ使用が制限されて、バッチジョブのページングが増加していることが分かりました。
対策として、オンラインアプリのメモリ使用率とページインの相関関係から、メモリ割り当ての不足分を算出しました。未割当のメモリを追加することで、ページイン回数を削減することができました。
【事例4：ページング激増の原因調査】
2010年10月のニッセイ同和損害保険との合併に向けて、CPUのCP数を2から4に増強しました。合併前には増強分を使わず、全体のCPU能力は増強前と同等の２CP相当にしたところ、ページイン回数が激増しました。
調査したところ、CPU能力は増強前と変わっていませんが、定例バッチの終了時刻が早まっていました。CP数が増加したことで多重度が高まり、CPU待ちが解消され、その結果アクティブなアドレス空間が増えてメモリの競合が高まり、ページインが増加したと考えられました。
近年はディスクの性能が向上しているため、 ページイン発生回数が増加しても業務への影響は見られませんでした。そのため、閾値の設定が適切ではないのではと考え、検討を実施しました。その結果、ページイン回数の閾値は環境によって変更する必要があるという結論に達し、メーカの見解をもとに適切な閾値に変更しました。
３．ニッセイ同和損害保険との合併
ニッセイ同和損害保険との合併に向けて、CPUとメモリの増強、ストレージの入れ替えを行いました。また、IIM社のサポートを利用し、リソース使用状況の比較を実施しました。
この結果、適切なリソースの増強を行うことにより、システム統合後も安定した稼動状況を維持することができました。また、IIM社の性能評価のサービスを十分に活用することにより、性能評価に関する工数を大幅に削減することができました。
今後さらなる業務増加が見込まれるため、IIM社のサポートを利用しながら、引き続きピーク日稼動状況の比較確認を実施していきたいと考えています。
以上
|
