Analytics and Automation Software : Cisco Data Virtualization

Dépannage CIS de dégradation de représentation

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit comment dépanner la représentation (CIS) de serveur d'informations de Cisco quand le système semble dégrader ou s'arrête avec des tentatives de traiter des demandes de client.

Contribué par Anil Prabhu, ingénieur TAC Cisco.

Informations générales

Quand la représentation CIS semble dégrader ou s'arrête avec des tentatives de traiter des demandes de client, il y a trois zones que vous pouvez surveiller et analyser afin de déterminer la source de question :

  • Mémoire
  • Disque
  • Chargement du serveur global

Ce document décrit comment dépanner ces trois zones.

Mémoire

Cette section décrit comment surveiller et dépanner la mémoire sur le serveur CIS.

Déterminez l'utilisation de mémoire

Remarque: Ce document suppose que votre serveur CIS est configuré avec 14 Go de mémoire.

Terminez-vous ces étapes afin de déterminer l'utilisation de mémoire sur le serveur composé de virtualisation de données (ou CIS) :

  1. Calculez la quantité de mémoire que vos dix demandes principales exigent sous le chargement maximal :

    1. Écrivez cette requête :

      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. Ajoutez les valeurs qui apparaissent dans la colonne CURRENT_MEMORY. Ceci aide à déterminer la demande de mémoire sur votre serveur CIS dans des conditions de charge. Afin de ce document, les dix demandes principales prennent 13 Go de segment de mémoire.

  2. Calculez 85% de votre segment de mémoire CIS de Java Virtual Machine (JVM). Avec la supposition que votre segment de mémoire CIS JVM est configuré avec 14 Go de mémoire :

    85% de 14 Go = 12 Go.

  3. Déterminez si vos dix demandes principales prennent plus de 85% du segment de mémoire CIS JVM. De préférence, vos demandes ne devraient pas prendre plus de 85% de votre segment de mémoire CIS JVM. Une fois que l'utilisation de segment de mémoire est de l'ordre de 90% à 100%, le JVM devient très lent. En conséquence, CIS répond aux demandes lentement.

    Dans ce cas, les dix demandes principales prennent 13 Go, qui est plus grand que 85% du segment de mémoire. Par conséquent, vous devez strategize afin de réduire le chargement sur la mémoire CIS.

Méthodes alternatives de détermination d'utilisation de mémoire

Tandis que les étapes précédentes sont recommandées, vous pouvez également employer ces méthodes afin de déterminer l'utilisation de mémoire :

  • Surveillez votre graphique de mémoire plusieurs fois par jour (en particulier, parfois quand vous suspectez que le chargement soit élevé). Basé sur les données de graphique, si vous déterminez que l'utilisation de demande dépasse 85% de votre segment de mémoire (12 Go), vous devez strategize afin d'empêcher l'utilisation de mémoire élevée.

  • Visualisez la ligne utilisée par mémoire totale dans la section de stats de serveur de votre cs_server_status.log.

Remarque: Cette section est expliquée plus en détail plus tard dans ce document.

Difficultés de question de mémoire

Cette section décrit trois stratégies que vous pouvez employer afin d'aborder les questions CIS de mémoire.

Créez les limites dures

Afin de réduire la mémoire qui demande l'utilisation, vous pouvez placer des limites dures sur la mémoire qu'on permet chaque demande individuelle de consommer. La meilleure (et recommandé) stratégie est de placer une valeur pour la mémoire maximum par demande dans la configuration de studio. Naviguez vers le serveur composé > la mémoire > mémoire gérée. Cisco recommande que vous placiez la valeur à 25%.

Ceci place un CAP sur la quantité de mémoire qu'on permet chaque demande de prendre du segment de mémoire CIS JVM. Le CAP réduit de manière significative la probabilité qu'une demande mémoire-intensive entraînera un pic soutenu dans l'utilisation de mémoire, qui entraîne CIS pour répondre lentement jusqu'à ce que la demande se termine et les baisses de pic.

Par exemple, supposez que vous avez deux demandes mémoire-intensives qui fonctionnent en même temps, qui prend 6 Go du segment de mémoire. Entre les deux, les demandes consomment 12 Go. Ceci laisse seulement 2 Go pour que d'autres demandes d'arrivée partagent, qui des causes probables la consommation de mémoire de dépasser 85% de votre segment de mémoire. Si la mémoire maximum par CAP de demande est placée à 25%, alors chaque demande prend 25% des 14 Go disponible, ou 3.5 Go. Ceci limite l'utilisation de mémoire à 7 Go entre les demandes, tandis que précédemment c'aurait été 12 Go.

Remarque: Les deux stratégies qui demeurent sont par-requête basée, tandis que la première stratégie est globale à toutes les requêtes. Afin d'utiliser ces stratégies, vous devez surveiller votre serveur CIS sur une période de temps et déterminer les requêtes d'utilisation de haute-mémoire et la quantité de mémoire que chacun utilise. En outre, vous devez déterminer le temps approximatif que ces requêtes arrivent typiquement.

Mise en antémémoire d'utilisation

La deuxième stratégie qui est utilisée afin d'aborder les questions CIS de mémoire est de cacher les requêtes. Terminez-vous ces étapes afin d'implémenter cette stratégie :

  1. Cachez la requête.

  2. Caches refreshs de programme à se produire pendant des heures creuses.

Maintenant, quand les utilisateurs exécutent une requête, la requête fonctionne contre le cache. La mise en cache produit un double avantage : il décale des exigences de mémoire aux heures creuses, et il fournit un temps de réponse plus rapide.

Restructurez la requête

La troisième stratégie qui est utilisée afin d'aborder les questions CIS de mémoire est de restructurer les requêtes. Terminez-vous ces étapes afin d'implémenter cette stratégie :

  1. Cliquez sur l'exécuter et affichez le bouton de statistiques. Ceci affiche que le plan de requête, avec des statistiques aidait à comprendre où l'utilisation de ressource est trop élevée.

  2. Vérifiez les Noeuds afin de déterminer :

    • Les Noeuds qui prennent la plupart de temps.

    • Les Noeuds qui manipulent beaucoup de lignes ? Beaucoup de lignes indique une charge élevée. Par exemple, 1,000 lignes est un nombre restreint de lignes, mais 1,000,000 lignes est beaucoup. Le noeud qui traite les 1,000,000 lignes est susceptible d'exiger plus de mémoire.

Disque

L'espace disque doit être convenablement classé afin de tenir compte du traitement. Cisco recommande que le répertoire de Temp qui est utilisé par le serveur CIS soit au moins 10 Go dans la taille. Le répertoire de Temp par défaut est créé sur la même partition que le répertoire d'installation CIS de serveur et développe comme nécessaire, jusqu'à la limite spécifiée.

Chargement du serveur global

Si vous trouvez que CIS répond trop lentement, visualisez la section de stats de serveur de votre cs_server_status.log. Cette section est enregistré d'heure en heure. , Assurez-vous par conséquent que vous utilisez les données qui sont enregistré pendant l'heure que le défilement ralenti se produit.

Par exemple, les utilisateurs signalent un défilement ralenti CIS sur 2014-04-30 approximativement à 8:00 AM. Par conséquent, vous devez trouver les stats de serveur pour cette période, comme affiché ici :

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)

Ces données indiquent si un défilement ralenti possible se produit en raison de ces raisons :

  • Trop de sessions sont ouvertes.

  • Trop de demandes sont exécutées.

  • Trop de mémoire est utilisée.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 117744