Analytics and Automation Software : Cisco Data Virtualization

CIS パフォーマンス低下 トラブルシューティング

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

概要

システムが低下するようである記述されていますまたは Client 要求を処理する試みとハングしますときこの資料に Cisco インフォメーション・サーバー(CIS)パフォーマンスを解決する方法を。

アニル Prabhu によって貢献される、Cisco TAC エンジニア。

背景説明

CIS パフォーマンスが低下するようであるか、または Client 要求を処理する試みとハングするとき問題のもとを判別するために分析監視し、できる 3 つの領域があります:

  • メモリ
  • Disk
  • 全面的なサーバ負荷

この資料にこの 3 つのエリアを解決する方法を記述されています。

メモリ

このセクションは CIS サーバのメモリを監視し解決する方法を記述します。

メモリ使用量を判別して下さい

: この資料は CIS サーバがメモリの 14 GB で設定されると仮定します。

合成データ 仮想化(か CIS)サーバのメモリ使用量を判別するためにこれらのステップを完了して下さい:

  1. 上 10 の要求がピーク負荷の下で必要とするメモリ量を計算して下さい:

    1. このクエリを入力して下さい:

      SELECT {option  MAX_ROWS_LIMIT=10} REQUEST_ID,  CURRENT_MEMORY, MAX_MEMORY,
      TOTAL_DURATION, START_TIME, OWNER, TRANSACTION_ID, SESSION_ID, ROWS_AFFECTED,
      DESCRIPTION  FROM/services/databases/system/SYS_REQUESTS SYS_REQUESTS
      ORDER BY MAX_MEMORY  DESC
    2. CURRENT_MEMORY カラムに現われる値を追加して下さい。 これはロード状態の下で CIS サーバのメモリ要求の判別を助けます。 この資料の為に、上 10 の要求はヒープの 13 GB を奪取 します。

  2. CIS Java Virtual Machine (JVM; Java バーチャルマシン)ヒープの 85% を計算して下さい。 CIS JVM ヒープがメモリの 14 GB で設定されるという想定のもとで:

    14 の 85% GB = 12 GB

  3. 上 10 の要求が CIS JVM ヒープの 85% 以上奪取 するかどうか判別して下さい。 できれば、要求は CIS JVM ヒープの 85% 以上奪取 するべきではありません。 ヒープ な 使用方法が 90% から 100% の範囲にあれば、JVM は非常に緩慢になります。 その結果、CIS は要求に応答が遅いです。

    この場合、上 10 の要求は 13 GB を奪取 します、ヒープの 85% より大きい。 従って CIS メモリのロードを減らすために、strategize 下さい。

代替メモリ使用量判断メソッド

前の手順が推奨される間、またメモリ使用量を判別するためにこれらのメソッドを使用できます:

  • ロードは高いことを)疑うときメモリ グラフを日数回監視して下さい(特に、時々。 要求 使用方法はヒープ(12 GB)の 85% を超過することを判別すればグラフ データに基づいて、ハイメモリ 使用方法を防ぐために strategize 下さい。

  • cs_server_status.logサーバ統計セクションの総メモリによって使用される行を表示して下さい。

: このセクションはこの資料の説明されたさらに詳しく以降です。

メモリ問題修正

このセクションは CIS メモリ問題に対処するために使用できる 3 つの戦略を記述します。

ハードな制限を作成して下さい

各個別の要求は消費することができること要求 使用がメモリに、ハードな制限を置くことができるメモリを減らすため。 最もよい(推奨される)戦略はスタジオ設定の要求ごとの最大メモリの値を設定 することであり。 合成サーバ > メモリ > マネージ メモリへのナビゲート。 Cisco は 25% に値を設定 したことを推奨します。

これは各要求が CIS JVM ヒープから奪取 することができるメモリ量にキャップを置きます。 キャップはメモリに負荷をかける 要求により要求がスパイク ドロップ完了するまで CIS が応答が遅いですメモリ使用量で支えられたスパイクを引き起こすこと確率を大幅に下げ。

たとえば同時に動作する 2 つのメモリに負荷をかける 要求があることを、仮定して下さい、それぞれがヒープからの 6 GB を奪取 する。 2 間で、要求は 12 GB を消費します。 これは共有するヒープの 85% を超過する考えられる原因 メモリ消費他の受信 要求のための 2 GB だけ残します。 要求キャップごとの最大メモリが 25% に設定 される場合、各要求は利用可能 な 14 GB の 25%、か 3.5 GB を奪取 します。 これは要求間の 7 GB に以前に 12 GB であろう一方、メモリ使用量を制限します。

: 残る 2 つの戦略は最初の戦略がすべてのクエリにグローバルである一方基づく毎クエリです。 これらの戦略を使用するために、CIS サーバを長い期間監視し、ハイメモリ 使用方法クエリをおよびそれぞれが使用するメモリ量を判別して下さい。 またそれらのクエリが一般的に着くこと、おおよその時間を判別して下さい。

キャッシングを使用して下さい

CIS メモリ問題に対処するために使用する第 2 戦略はクエリをキャッシュすることです。 この戦略を実装するためにこれらのステップを完了して下さい:

  1. クエリをキャッシュして下さい。

  2. オフピーク の 時間の間に発生するためにキャッシュ更新をスケジュールして下さい。

ユーザがクエリを実行するときこの場合、クエリはキャッシュに対して動作します。 キャッシングは二重利点を生成 します: それはオフピーク の 時間にメモリ要求を移し、より速い応答時間を提供します。

クエリを再構成して下さい

CIS メモリ問題に対処するために使用する第 3 戦略はクエリを再構成することです。 この戦略を実装するためにこれらのステップを完了して下さい:

  1. 実行および Show statistics ボタンをクリックして下さい。 これは統計情報と共にリソース使用が余りに高いどこにのか理解を助けるクエリ プランを、示します。

  2. 判別するためにノードを確認して下さい:

    • ほとんどの時間をかけるノード。

    • 多くの行を処理するノードか。 多くの行は高負荷を示します。 たとえば、1,000 の行は少数の行ですが、1,000,000 の行はたくさんあります。 1,000,000 の行を処理するノードは可能性が高いですそれ以上のメモリを必要とする。

Disk

ディスクスペースは処理を可能にするために十分に大きさで分類する必要があります。 Cisco は CIS サーバによって使用する一時ディレクトリが少なくとも 10 GB であることを推奨します。 デフォルト一時ディレクトリは CIS サーバインストール ディレクトリと同じパーティションで作成され、規定 された制限まで必要に応じて拡張します。

全面的なサーバ負荷

CIS は余りに応答が遅いことが分ったら、cs_server_status.log のサーバ統計セクションを表示して下さい。 このセクションは一時間毎に記録 されます。 従って低下は発生すること時間の間に記録 される データを使用するように、して下さい。

たとえば、およそ 8:00 AM の 2014-04-30 の Users レポート CIS 減速。 従って、ここに示されているようにその時間枠のためのサーバ統計を、見つけて下さい:

INFO 2014-04-30 08:14:21.626 -0400 StatusReporter - 

===============================================================

----------------
| Server Stats |
----------------

Server Name:               myCISserver.cisco.com:9600

Total Memory Used:          62% (3284MB of 5292MB)

Total Sessions:             347342

Total Server Requests:      58137425

Total Data Source Requests: 28489774

Privilege Cache Access:     100% (227256506 hits of 227269153 accesses)

Privilege Cache Capacity:   16% (7976 of 50000 entries)?

User Cache Access:          100% (498356387 hits of 498331464 accesses)

User Cache Capacity:        3% (61 of 2000 entries)

Repository Cache Access:    100% (485995869 hits of 486418321 accesses)

Repository Cache Capacity: 4%(1850 resources using 26.37 MB of managed memory)

このデータは可能性のある低下がこれらの原因が原因で発生するかどうか示します:

  • 余りにも多くのセッションは開いています。

  • 余りにも多くの要求は動作します。

  • たくさんのメモリは使用されます。


Document ID: 117744