CSA: メモリおよびパフォーマンス トラッキング(オンプレミスのみ)

ccppmop159
システムのパフォーマンスの監視、クラスタ内の各サーバへの物理メモリ割り当ての管理、最適なデータベース パフォーマンスを維持するためのデータベース サーバの分析を行います。
2
システム パフォーマンスの監視
CSA を使用して、システム パフォーマンスを追跡することができます。データが分析されて
クラシック PPM
に移動されるまで、
クラシック PPM
サーバ上でデータを収集して格納できます。
パフォーマンス トラッキング セッションの仕組み
  • セッションが開始されると、ユーザ ワークステーションからの
    クラシック PPM
    サーバへのコールが追跡されて記録されます。セッションが完了した後で、分析がデータに対して実行されます。個別のセッションをリスト表示する[パフォーマンス トラッキング]
    ページから分析結果にアクセスできます。
  • コールごとに、分析によって、ミリ秒単位の応答時間とバイト単位のデータ ボリュームが提供されます。
  • すぐに新しいセッションを開始するか、必要に応じて後で開始するか、または指定された時刻に開始するようにスケジュールすることもできます。
  • セッションの期間を定義できます。
  • 一度に 1 つのセッションのみを開始して、
    [データを収集]
    ステータスにすることができます。
  • クラスタ内のサービスはすべてパフォーマンス トラッキング セッション内に含まれます。セッション中に、個々のサービスでトラッキングを中止できます。
  • セッションが開始された後は、セッションが停止されているか、分析を完了している場合でも再起動することはできません。セッションのプロパティ ページで[名前を付けて保存]ボタンを使用すると、その設定を新しいセッション名に保存して、新しいセッションを開始できます。
  • 個々のユーザに応じてデータを記録し追跡できます。多くのユーザを追跡すると、システム自体のパフォーマンスに影響する場合があります。
  • レベル 1 ~ 10 でデータを追跡できます。連続するそれぞれのレベルに応じて、システム内のより深度レベルの高い情報が提供されます。最も詳細なレベル(10)でパフォーマンスを追跡することを選択すると、システム自体のパフォーマンスに影響する場合があります。
パフォーマンス トラッキング セッションの作成
以下の手順に従います。
  1. CSA にログインします。
  2. [パフォーマンス]を開いて、[パフォーマンス トラッキング]をクリックします。
  3. [新規]をクリックします。
  4. 以下のフィールドに入力します。
    • セッション名
      セッションの名前を定義します。
    • 説明
      セッションの説明を定義します。この情報は、[パフォーマンス トラッキング]
      ページのセッションのリストに表示されます。
    • 開始オプション
      セッションをいつ開始するかを指定します。[スケジュール済み]を選択する場合は、日付の選択を使用して開始日を選択します。開始時刻を時間と分で選択します。
      値:
      今すぐ、オンデマンド、またはスケジュール。
    • 期間
      セッションが存続する時間の長さを指定します。これらのフィールドを組み合わせて、正確な時間を指定できます。
      フィールド:
      日、時間、および分
    • トラッキング レベル
      1~10 の数字を選択して、追跡する詳細レベルを指定します。最低レベル(1)を選択した場合は、コールの名前のみがセッションの分析データでリスト表示されます。コール リスト用に提供されているデータ(応答時間およびデータ ボリューム)は、選択されたレベルに影響されません。より詳細なレベルでコール リストのデータを表示する場合は、さらに詳細な情報を収集して表示するために高いトラッキング レベルを選択します。選択された追加のトラッキング レベルごとに、別のレベルが各コールに利用可能なツリー ビューに追加されます。トラッキング レベル 10 は、すべての利用可能なレベルに相当します。いずれかの特定コール用のツリー ビューに表示される情報は、コールの複雑さによって異なる場合があります。より高いトラッキング レベルでは、パフォーマンスがさらに詳細に収集されますが、より多くのリソースを消費します。
    • 個別ユーザをトラッキング
      個別ユーザ、およびそれらのユーザが
      クラシック PPM
      で行うアクションについての情報を記録するかどうかを示します。
    • 完了後にただちにデータを分析
      セッション終了直後にデータの分析を開始することを示します。
    • 応答時間パーセンタイル
      最も遅い応答時間が表示されるパーセンタイルを定義します。たとえば、90 パーセントをした場合は、90 パーセンタイル以下の応答時間のみが表示されます。90 パーセンタイルより速い応答時間の 10 パーセントは処理されません。
  5. 変更を保存します。
パフォーマンス トラッキング セッションの停止
適切な権限を持つ管理者は、手動でいつでもセッションを停止できます。停止するには、セッションを作成または開始したユーザである必要はありません。
以下の手順に従います。
  1. CSA にログインします。
  2. [パフォーマンス]を開いて、[パフォーマンス トラッキング]をクリックします。
  3. セッションが含まれている行で、[停止]をクリックします。
サービスのパフォーマンス トラッキング セッションの停止
適切な権限を持つ管理者は、セッションを停止することなく、サービスに対するパフォーマンス トラッキング セッションを手動でいつでも停止できます。
以下の手順に従います。
  1. CSA にログインします。
  2. [パフォーマンス]を開いて、[パフォーマンス トラッキング]をクリックします。
  3. セッションの名前をクリックします。
  4. [サービス]セクションで、セッションを終了するサービスを探して、行内にある[中止]
    リンクをクリックします。
セッションの結果の表示
セッションの分析後にパフォーマンス トラッキング セッションの結果を表示できます。サーバへの各コールのデータ応答時間およびデータ ボリュームがリスト表示されます。リストに表示される情報量は、選択するトラッキング レベルによって異なります。リスト内のコールを展開して、追加情報を表示できます。
以下の手順に従います。
  1. CSA にログインします。
  2. [パフォーマンス]を開いて、[パフォーマンス トラッキング]をクリックします。
  3. セッションが含まれている行で、[結果を表示]をクリックします。
    [結果]ページが表示されます。[概要]タブは、初期にセッション用に設定されているプロパティ、および選択したサービスの統計を表示します。
  4. 複数のサービスを実行している場合は、[サービス]
    フィールドでその結果を表示するサービスを選択します。
  5. [分析]タブをクリックします。
セッションの比較
リスト内の任意の 2 つのセッションの結果を比較できます。比較は、同じサービスまたは異なるサービス上の異なるセッションに対して行うことができます。最初のセッションの分析は、標準形式で[分析]タブに表示されます。2 番目のセッションの比較は、最初のセッション用に表示された各データ統計のすぐ後の増加または減少の割合として表示されます。
以下の手順に従います。
  1. CSA にログインします。
  2. [パフォーマンス]を開いて、[パフォーマンス トラッキング]をクリックします。
  3. セッションのリストで、比較する 2 つのセッションを選択し、[比較]をクリックします。
    [比較]ページが表示されます。
    ページの[セッション]セクションは、どのセッションが基準で、どれが比較かを示します。セッションの既定以外のサービスを選択するには、[サービス]
    列のドロップダウン リストをクリックします。
  4. 基準と比較セッションの順序を変更するには、[比較を逆転]をクリックします。
  5. リストで表示されるデータを制限するには、[パフォーマンス分析フィルタ]セクションのリスト フィルタを使用します。
メモリの管理
クラシック PPM
クラスタ内の各サーバに十分な物理メモリを割り当てることが重要です。必要な物理メモリの量は、クラスタがどのように設定されるか、どのようなサービスが実行されるか、および何人のユーザがクラスタによってサポートされるかによって異なります。
クラシック PPM
によって実際に使用される量よりも多くの物理メモリをサーバに搭載する必要があります。仮想メモリに依存することはできません。これは、オペレーティング システムでメモリとディスク間のスワップが必要になり、システムの速度が著しく遅くなってパフォーマンスが低下するためです。
メモリ消費量とパフォーマンスの監視
top または prstat などのコマンドを使用して、各プロセスまたはサーバ全体の UNIX 上のメモリ消費量を監視できます。
Microsoft Windows 環境では、Windows Task Manager を使用します。[プロセス]
タブに移動して、各プロセスのメモリ消費量を確認するか、[パフォーマンス]
タブを使用して、サーバ全体のメモリ設定および消費量を確認します。
タスク マネージャの使用方法に関する詳細については、Microsoft Windows のタスク マネージャのヘルプを参照してください。
十分なメモリの保持
他のアプリケーションと同様に、
クラシック PPM
クラスタの各サーバに十分な物理メモリを割り当てます。必要な物理メモリの量は、クラスタがどのように設定されるかによって異なります。たとえば、どのサーバでどのようなサービスが実行されるか、およびサポートする実装の規模などを考慮します。次のルールに従ってください:
クラシック PPM
によって実際に使用される量よりも多くの物理メモリをサーバに設置する必要があります。仮想メモリに依存することはできません。これは、オペレーティング システムでメモリとディスク間のスワップが必要になり、アプリケーションの速度が著しく遅くなってパフォーマンスが低下するためです。
  • top または prstat などのコマンドを使用して、各プロセスまたはサーバ全体の UNIX 上のメモリ消費を確認できます。
  • Microsoft Windows 環境では、Windows Task Manager を使用します。各プロセスのメモリ消費量を確認するために、[プロセス]タブに移動するか、[パフォーマンス]タブを使用して、サーバ全体のメモリ設定および消費量を確認します。
Oracle および Microsoft SQL Server などの他のサービス用のメモリ割り当てを変更するには、各製品の管理マニュアルを参照してください。
メモリ設定を変更する前にサービスをシャットダウンして、メモリ設定を変更した後にサービスを再起動します。
以下の手順に従います。
  1. CSA にログインします。
  2. [クラスタ] - [サーバ]を使用して、それぞれのサーバを選択します。
  3. 以下のいずれかを実行します。
    • アプリケーション サーバ上のメモリを調節するには、[アプリケーション]タブを選択します。
    • バックグラウンド サーバ上のメモリを調節するには、[バックグラウンド]タブを選択します。
  4. [Java VM パラメータ]フィールドに新しいメモリの割り当てを入力して保存します。
  5. [サービス]タブを選択します。
  6. app と bg サービスを再起動します。
Microsoft SQL Server のメモリ消費の制限
時間の経過とともに、Microsoft SQL Server は利用可能な物理システム メモリ全体、またはそれ以上を消費します。その結果、オペレーティング システム レベルのページングによってデータベースの動作が著しく低下します。ベスト プラクティスとして、Microsoft SQL Server 用のメモリ割り当て容量を制限してください。
バージョンによっては、オペレーティング システム用に約 200MB のメモリを予約できる場合があります。Microsoft SQL Server が実行されている唯一のアプリケーションであると想定します。残りのシステム メモリの 90 パーセントを Microsoft SQL Server に割り当てます。たとえば、システムに 2GB のメモリがあるとします。OS メモリが割り当てられた後、約 1.8GB が利用可能となります。約 1.6GB(1.8GB の 90 パーセント)を Microsoft SQL Server に割り当てます。
以下の手順に従います。
  1. Microsoft SQL Server Enterprise Manager アプリケーションを開き、サーバを右クリックして、[プロパティ]を選択します。
  2. [メモリ]タブを選択します。[SQL Server メモリの動的設定]セクションのスライダ バーを計算された最大設定に調整します。
  3. [OK]をクリックして、変更を確認します。
Microsoft SQL Server のシステム設定の詳細については、Microsoft TechNet の Web サイトを参照してください。
メモリ割り当ての調整
クラシック PPM
またはバックグラウンド サービスに割り当てられるメモリを調整する前に、最初にサービスを停止します。メモリの調整を行ったら、サービスを再起動します。Oracle および Microsoft SQL Server などの他のサービス用のメモリ割り当てを変更するには、それぞれの管理マニュアルを参照してください。
以下の手順に従います。
  1. CSA にログインします。
  2. [ホーム]を開き、[サーバ]をクリックします。
  3. メモリを調整するサーバの名前をクリックします。
  4. [サービス]タブをクリックします。
  5. 変更するサービスの隣のチェック ボックスをオンにして、[停止]をクリックします。
  6. クラシック PPM
    のメモリ設定を変更するには、以下の手順に従います。
    1. [プロパティ]タブをクリックします。
    2. [アプリケーション]サブタブをクリックします。
    3. [Java VM パラメータ]フィールドで、メモリの割り当てを変更して保存します。
  7. バックグラウンド サービスのメモリ設定を変更するには、以下の手順に従います。
    1. [プロパティ]タブをクリックします。
    2. [バックグラウンド]サブタブをクリックします。
    3. [Java VM パラメータ]フィールドで、メモリの割り当てを変更して保存します。
  8. [サービス]タブをクリックします。
  9. 変更したサービスの隣のチェック ボックスをオンにして、[開始]をクリックします。
十分なディスク I/O スループットの確保
クラシック PPM
は、以下のようなさまざまなアクティビティを活用する混合環境です。
  • オンライン トランザクション処理 (OLTP)
    タイム シートの入力、会計トランザクションの入力、ドキュメント上のコラボレーション、およびキャパシティ計画。
  • バッチ処理
    [トランザクションを会計にポスト]、[データマートの抽出]および[会計実績のインポート]。
  • データ分析
    レポート、クエリ、グラフ、およびグリッド
これらのほとんどのアクティビティは、データベース サーバにかなりの量の読み取り/書き込み負荷を与えます。ベスト プラクティスとして、これらの操作で最大限のスループットを実現します。RAID 0 + 1 ディスク設定によってデータベース サーバを設定します。この設定は、ディスクのストライピングおよびディスク障害に対する適切なフェールオーバ機構を提供します。
データベース パフォーマンスの最適化
これらの手法を活用してデータベース サーバを分析し、最適なデータベース パフォーマンスを確保します。
Oracle データベース スキーマの分析
以下の方法のいずれかを使用して、データベース スキーマを分析できます。
  • Oracle テーブル解析ジョブを使用する。このジョブをスケジュールするには、以下の権限が必要です。
    • このジョブを実行するためのアクセス権を所有しているか、または、[レポートとジョブ管理者]グループに属している必要があります。
    • [レポートとジョブ]ページにアクセスするには、[ジョブ ユーザ]グループに属している必要があります。
      ベスト プラクティスとして、少なくとも週に一度、週末の夜などのユーザ アクティビティが少ないときに、このジョブを実行します。
  • admin db analyze コマンド ライン ユーティリティを使用する。通常は、ジョブの間にこの方法を使用する必要はありません。このメソッドはスケジュール済みジョブで実行される同じ分析コマンドを実行します。ただし、
    クラシック PPM
    ホット フィックスまたはパッチ リリース アプリケーションの実行中に、
    クラシック PPM
    を起動して実行せずにデータベースを分析することが必要になる場合があります。
  • 直接および非同期 I/O
    UNIX および Linux システムでの I/O 操作は通常、ファイル システム キャッシュを経由します。処理自体には問題はありませんが、この追加の処理によってリソースが必要になります。ファイル システム キャッシュをバイパスすると、CPU の使用率を削減して、データベース以外のその他のファイル操作用にファイル システム キャッシュを解放できます。Raw デバイスに対する操作では、ファイル システム キャッシュが自動的にバイパスされます。
    オペレーティング システムに同期 I/O 要求がサブミットされると、書き込みが完了するまで書き込み処理をブロックして、その後に処理を続行します。非同期 I/O では、I/O 要求がサブミットされて処理されている間も処理を続行します。これにより、非同期 I/O では、I/O 操作に関連するパフォーマンス上のボトルネックの一部をバイパスできます。
    Oracle では、FILESYSTEMIO_OPTIONS パラメータを使用して、サポートされているプラットフォーム上で直接 I/O および非同期 I/O を利用できます。使用可能な値を以下に示します。
    • ASYNCH - 可能な場合は非同期 I/O が有効になります。
    • DIRECTIO - 可能な場合は直接 I/O が有効になります。
    • SETALL - 可能な場合は直接 I/O および非同期 I/O の両方が有効になります。
    • NONE - 直接 I/O および非同期 I/O の両方が無効になります。
    ベスト プラクティス
    : SETALL
  • AWR レポートの分析
    Oracle から AWR または Statspack レポートを生成して、レポートを分析します。PGA および SGA のサイズ設定を確認し、必要に応じてそれらのサイズを調整します。
    REDO ログ切り替えの数を確認します。ベスト プラクティスは、1 時間あたり 2 ~ 3 回の REDO ログ切り替えです。
Oracle 11g のパフォーマンスを改善するための CPU 速度の設定
Oracle 11g のオプティマイザは、CPU と読み取り値の両方を使用して、クエリのコストを判定します。また、全体的な負荷の軽減を試行するためにシステム ロード特性を使用します。CPU 速度設定が指定されていないと、オプティマイザの性能は低下します。CPU 速度を設定するには、以下のように gather system stats を実行します。
execute dbms_stats.gather_system_stats('Start'); -- <some time delay while the database is under a typical workload> execute dbms_stats.gather_system_stats('Stop');
パフォーマンスを改善するための追加の Oracle 11g パラメータの設定
以下のパラメータは、Oracle 11g 上で
クラシック PPM
を実行するときにパフォーマンスの向上を示すことが判明しています。これらのパラメータはオプションの「
チューニング
」パラメータとして用意されており、十分なデータベース パフォーマンスを実現するために使用する必要があります。
CURSOR_SHARING=FORCE Oracle init parameter
このパラメータを FORCE に設定すると、Oracle では基本的に実行されたクエリが書き直されて、リテラルがバインド値に置換されます。実行されたクエリが同じ(ただし値は異なる)である場合は、1 つの共有クエリのみが作成され、すべてのセッションで共有可能になって使用されます。これにより、ハード解析がソフト解析になります。ソフト解析では、ハード解析より少ない共有プールのロック(またはラッチ)が行われるため、パフォーマンスが向上します。これが使用すべき設定かどうかを判定するには、Oracle AWR を監視して、過剰なクエリ解析を確認します。
Microsoft SQL Server データベース スキーマの分析
Oracle と同様、Microsoft SQL Server でも、効率よく SQL ステートメントを実行するために、テーブルおよび索引の統計が必要です。SQL Server DBA として統計の更新および再索引付けのための SQL Server ジョブを作成し、定期的にそれを実行する必要があります。
データマート パラレル オプションの有効化
データマートの抽出は I/O 集約的です。これは、トランザクション型テーブルで増分変更を検出して、データマート レポート テーブルに書き込む必要があるためです。一般的な顧客環境では、ディスクにパラレルにアクセスするための複数のパラレル プロセスを起動できる十分な CPU パワーがあり、全体的なデータマートの実行時間は最小化されます。
最適なデータベース サーバ ファイル レイアウトの実現
Oracle と Microsoft SQL Server は、いずれもそのテーブル ファイルが索引ファイルから分離されているときにパフォーマンスが著しく向上します。他の 2 つからのログ ファイルを分離します。データベース サーバ ファイルのレイアウトを最適化するには、以下の手順を使用します。
  1. 索引テーブルスペース データ ファイルとは別のディスクに Oracle テーブル テーブルスペース データ ファイルを配置します。
  2. テーブルと索引用の個別のファイル グループを作成し、異なるディスクに配置します。
  3. 索引を新しい索引ファイル グループに移行します。
Oracle テーブルスペース データ ファイル
セグメント内での領域管理を改善して自動化するために、autoextend をオンにして自動セグメント領域管理(ASSM)を使用することをお勧めします。ASSM は、空きリスト ベースの領域管理による管理容易性とパフォーマンス上の利点を提供します。ASSM に関する詳細については、Oracle のマニュアルを参照してください。
SQL Server テーブルスペース データ ファイル
テーブルと索引用の個別のファイル グループを作成し、異なるディスクに配置します。トランザクション ログをディスクの別のセットに配置します。
クラシック PPM
索引の新しい索引ファイル グループへの移行
以下の手順に従います。
  1. Microsoft SQL Server Enterprise Manager を開きます。
  2. クラシック PPM
    データベースをバックアップします。
  3. クラシック PPM
    データベースを右クリックし、[プロパティ]をクリックします。
  4. [データ ファイル]タブをクリックします。
  5. クラシック PPM
    _Data ファイル名の下の新規行をクリックし、以下の情報を入力します。
    • ファイル名として「Classic PPM_Idx」。
    • Classic PPM_Idx_Data.NDF という名前のファイルの適切な 2 番目のディスクの場所。
    • 割り当てられたスペースの値(値は主要データ ファイルの割り当ての 50 パーセント以上であることが必須)。
    • ファイルグループ名の隣の IDX。
    使用する名前に、INDEX などの Microsoft SQL Server キーワードを使用することはできません。
    他の既定の設定はどれも変更しないでください。
  6. 値がすべて入力されたときに、新しいデータ ファイルおよび新しいファイル グループを作成するには、[OK]をクリックします。
  7. データ ファイルとファイル グループが作成されていることを確認するには、
    クラシック PPM
    データベースを右クリックします。
  8. [データ ファイル]タブをクリックし、新しいデータ ファイルが作成されていることを確認します。入力した値がすべて存在し正しいことを確認します。
  9. [ファイル グループ]タブをクリックし、新しいファイル グループが作成されていることを確認します。既定のファイル グループは PRIMARY になっている必要があります。
  10. niku db ユーザとして SQL クエリ アナライザを使用し、
    クラシック PPM
    データベースに接続します。
  11. パラメータとして新しいファイル グループを指定して、ストアド プロシージャ CMN_MIGRATE_MSSQL_INDEXES_SP を実行します。
    EXECUTE CMN_MIGRATE_MSSQL_INDEXES_SP 'IDX'
    このストアド プロシージャが実行されると、PRIMARY ファイル グループのすべての索引が、2 番目のディスク上の IDX ファイル グループに移動されます。
    このストアド プロシージャを実行するには、データベースのサイズによっては著しく時間がかかる場合があります。