「システムが遅い」という訴えは、Basisに寄せられる相談の中で最も多いものの1つです。しかし「遅い」の中身はさまざまで、まず何が遅いのかを特定することから始まります。
レスポンスタイムの内訳
SAPは、1回のリクエストの処理時間を複数の要素に分解して記録します。どこに時間がかかっているかを見れば、原因の見当がつきます。
| 要素 | 内容 | 長い場合に疑うこと |
|---|---|---|
| 待機時間（Wait） | ワークプロセスの空き待ち | プロセス数の不足、長時間処理の占有 |
| ロール時間 | ユーザーコンテキストの入替 | メモリ不足 |
| ロード時間 | プログラムのロード | プログラムバッファの不足 |
| 処理時間（CPU） | ABAPの実行 | 非効率なループ、大量データ処理 |
| DB時間 | データベースアクセス | インデックス不足、非効率なSQL |
| エンキュー時間 | ロック取得の待ち | ロック競合 |
| GUI時間 | 画面転送 | ネットワーク、GUI設定 |
分析のトランザクション
| Tコード | 用途 |
|---|---|
| ST03 / ST03N | ワークロード分析。全体の傾向を把握 |
| ST05 | SQLトレース。個別のSQLを詳細に分析 |
| ST02 | バッファの使用状況。ヒット率とスワップ |
| ST06 | OSレベルの監視。CPU、メモリ、ディスク |
| SM50 / SM66 | ワークプロセスの状態。長時間処理の特定 |
| SAT | ABAPランタイム分析。処理時間の内訳 |
| DB02 | データベースの領域とオブジェクト |
| DBACOCKPIT | データベース統合管理 |
ST03によるワークロード分析
ST03は、システム全体の負荷傾向を把握するための出発点です。時間帯別、トランザクション別、ユーザー別の集計が可能です。
見るべきポイントは、「実行回数が多く、かつ1回あたりの時間が長いトランザクション」です。1回10秒かかるが日に3回しか実行されないものより、1回2秒だが日に5,000回実行されるもののほうが、全体への影響は大きくなります。
バッファの監視
ST02では、各種バッファのヒット率とスワップ回数を確認します。バッファが不足すると、本来メモリから読めるはずのデータをディスクから読むことになり、性能が低下します。
| バッファ | 内容 | 目標ヒット率 |
|---|---|---|
| プログラムバッファ | ABAPプログラムの実行形式 | 98%以上 |
| 汎用領域バッファ | クライアント別などのテーブルデータ | 95%以上 |
| 単一レコードバッファ | 個別レコード | 95%以上 |
| CUA バッファ | メニューと画面定義 | 98%以上 |
| 画面バッファ | Dynpro定義 | 98%以上 |
メモリの構成
SAPのメモリ管理は独特で、ワークプロセスが使うメモリには段階があります。
| 順序 | 領域 | 内容 |
|---|---|---|
| 1 | ロールエリア | 最初に使われる。プロセスごと |
| 2 | 拡張メモリ（EM） | 複数プロセスで共有。主要な作業領域 |
| 3 | ヒープメモリ | EMを使い切った後。プロセス専有（PRIVモード） |
ヒープメモリを使い始めるとワークプロセスがPRIVモードになり、そのプロセスが他のユーザーに使われなくなります。大量データを扱うプログラムがこの状態を引き起こすと、システム全体に影響します。
性能改善の優先順位
性能問題への対処は、効果の大きいものから順に検討します。
- SQLの改善：インデックスの追加、ループ内SELECTの排除。最も効果が大きい
- プログラムロジックの改善：ネステッドループの解消、不要な処理の削除
- アーカイブ：古いデータを削除・退避してテーブルを小さくする
- バッファ・メモリの調整：パラメータチューニング
- ハードウェアの増強：最後の手段。根本原因の解決にはならない