システム管理に関わるベーシック情報やトレンドをご案内します!
具体的な改善項目は、大小合わせて20を超えています。
前回2.3で紹介したプログラム(xxx0001)のロジック改善では、データベースの不要な排他待ちが削減され、デッドロックも起きにくくなり、システム全体の性能が大幅に改善される結果となりました。
重要なプログラムについては性能モデルを作成します。例えば、上記プログラムの性能改善の前後だと図6のようになります。データベースのメモリ常駐化も行っているためCPU/IO頻度は20→42に上昇しています。
図6 性能モデル
本題である「売上が1.5倍になったときシステムが業務に影響を与えない」ことを検証すためには様々な考慮が必要です。
① 売上の伸びとシステムの資源使用量の関係
CPUは第1回の図1に示したとおり十分に余裕があるので、売上との厳密な関係を導く必要はありませんでした。I/Oやメモリについても検証をします。
② システムで最初にボトルネックとなる資源は何か
CPUだけとは限りません。本件では、ほとんどのプログラムが参照しているデータベースがあり、できるだけ排他待ちが起きないようにする必要がありました。お客様にはデータベースの構造や排他制御の仕組みを十分に理解して頂き、自ら考え、チューニングを実施して頂きました。
③ 多重処理が可能か
入力端末やバッチジョブの実行多重度を増やすために、タスク数や優先度の調整を行います。
④ どこまで遅くなってよいのか
ハードの性能を上げない限り処理時間は遅延します(図6の待ち時間が延びる)。現実的なサービスレベルを合意することが重要です。
更に、想定されるリスクについてもお客様と意識を合わせることが重要です。例えば、処理時間が予想以上に遅延してしまったときの対処方法など具体的に提示します。
表2に示した状況から2週間後の改善結果を表3に示します。遅かった処理が短期間で改善している様子がわかると思います。
SEが何ヶ月も調査しているはずなのに一向に解決しない性能問題。ギブアップ寸前の問題の相談を受け、解決に導いていくプロセスを現場の視点で紹介します。性能改善の現場ではメインフレームの本質が見えてきます。
記事一覧へ有賀 光浩(ありが みつひろ)
第7回 バックアップ・リカバリ運用は適切ですか? | [2009年4月22日] |
第6回 B社での事例(3)~CPUのムダを無くす | [2009年3月18日] |
第5回 B社での事例(2)~オンラインの性能改善 | [2009年2月12日] |
第4回 B社での事例(1)~性能データの誤差 | [2009年1月14日] |
第3回 A社での事例(3)~性能改善 | [2008年11月26日] |
第2回 A社での事例(2)~自信を持たせる | [2008年10月29日] |
第1回 A社での事例(1)~初期動作 | [2008年9月24日] |