「SAP　Basis概要の教科書」No.21 SAP 性能分析について2

はじめに

今回は、前回の性能分析の続きになります。前回はプログラム単体の性能を確認しましたが、今回はSAPシステム全体の性能を見てパフォーマンス問題を解決する方法をご紹介いたします。

1. 問題が今まさに発生している場合

プログラム単体の性能分析と同様、まずは問題発生の日時を特定します。もし今まさに性能低下が継続しているという場合は、トランザクション：SM50からワークプロセスの状態を確認して下さい。ワークプロセスが専有されていないかチェックします。

ワークプロセスが専有されている場合、いずれかのプロセスがデータベースに高負荷を与えている可能性が高いです。もし、同じプログラムが複数実行中の状態になっている場合、そのプログラムが直近移送等で改修されていないかも含めて、該当プログラム保守担当者に調査支援を依頼して下さい。

また、トランザクション：SM12にて、大量の更新ロックエントリが蓄積しているかも見てみて下さい。生産系のMRP処理などで、対象期間が長いことで大量の更新処理が実行され処理遅延が発生することがあります。大量のワークプロセスが実行されているが、様々な処理が動いており、どれが性能遅延を引き起こしているか不明な場合、データベース側のクエリー実行状況を確認して下さい。

各種RDBMS製品のツールにて実行状況をモニタ出来るツールが用意されています。SAPのプログラムは最終的にデータベースにクエリーを発行するのはどれも同じですので、そちらから大量のクエリーの実行状況を見て特定のテーブルに処理が集中していないか確認して下さい。テーブルが特定できれば、そのテーブルの統計情報を更新することで性能が改善できることがあります。

2. 過去に発生した事象の場合

過去に発生した問題の分析を行うには、まず発生日時を特定し、その時間帯の各種リソース（CPU、ディスクI/O、メモリ）の使用状況を確認します。明らかにその時間帯に使用状況が継続して高い場合はリソースの増強を検討して下さい。下記に各種リソースの確認ポイントを記しますのでご参考下さい。

3. CPUの使用率が高い場合

CPUについては、長時間使用率が高いのか否かをまず確認して下さい。短時間、例えば1分以内などは、メモリから取得したデータを円滑に処理できているだけでボトルネックと断定するのは早計です。この場合はCPUだけではなく他のリソースに問題がないかも併せて確認して下さい。長時間負荷が高い場合は、該当時間帯に他のアプリケーションが並行して動いていなかったか確認して下さい。

例えばウィルス対策ソフトの実行でCPU負荷が上がることは複数事例が報告されています。SAPシステムのプログラムをウィルスチェックしている最中に処理が保留されてしまうという動きです。この場合は、SAPシステム関連のプログラムをリアルタイムスキャン対象から除外することで回避可能です。その代わりにシステムメンテナンス日などにSAPシステムファイルをスキャンさせるようにします。

並行して動いているアプリケーションがない場合は、CPU負荷を高めるのはABAPプログラム側の問題になってきます（データベース側の問題はほとんど考えられません）。トランザクション：STADやST03N等で該当時間帯のCPU応答時間が長いプログラムを特定し、プログラム保守担当者に改修の余地がないか確認します。不要なループ処理によりCPU負荷を高めていたというケースもあります。

これらいずれのケースにも合致しない場合、定期的にCPU使用率が高まってしまっている場合、これは慢性的にCPUのパワーが足りなくなっているとおもわれます。CPUコア数増加などCPUリソースの増強をご検討下さい。

4. ディスクI/Oが高い場合

I/O待ちが長い場合は、ディスク自体に障害があって性能が低下していないか確認しますが、この場合、ほぼデータベース側のメモリが足りていないことが想定されます。メモリバッファのキャッシュヒット率を見て95%を下回る状況が長時間続いている場合は、メモリの増強協をご検討下さい。

ただ、まずはプログラム側でメモリの節約が検討できないか、そこから始めるべきだと筆者は考えます。メモリを無限に増やすわけにはいきませんので、前回のプログラム単体の性能分析を参考に、プログラム側でできることは実施し、それでも不足する場合はメモリリソースを増強して下さい。

5. メモリ使用率が高い場合

ディスクI/Oの調査と同様、データベースメモリのキャッシュヒット率をまず確認して下さい。その際、併せてI/Oラッチ・WRITELOGといった性能分析指標も併せて確認すると効果的です。

I/Oラッチが高い場合、読み込み系の処理で負荷が高まっていることが多いです。

該当時間帯のクエリーの実況状況を確認し、長時間読み込まれているテーブルを特定し索引の追加や統計情報の更新で性能が改善される場合があります。WRITELOGの値が高い場合は、更新処理でボトルネックになっている可能性があります。

I/Oラッチ同様、実行クエリーを特定し複数のプログラムで同一テーブルに書き込み処理が集中していないか確認して下さい。バッチ処理などで集中している場合は、処理時間をずらすなど運用面の対応で性能低下を防ぐことが可能な場合があります。

上記いずれにケースでも対応できない場合に、メモリリソースの増強をご検討下さい。

まとめ

いかがでしたでしょうか。今回はシステム全体の性能分析のアプローチ方法について説明いたしました。個別プログラムの性能分析と重複する部分もありましたが、まずはリソース増強にはコストもかかりますし、無限ではないので、まずは現状を分析して改善できることから検討し、最終手段としてリソース全体の増強をご検討頂ければ幸いです。