Voix et communications unifiées : Cisco Unified Communications Manager (CallManager)

Surveillance et dépannage de l'utilisation élevée du CPU dans Cisco Unified Communications Manager 6.0 à l'aide de l'outil RTMT (Real Time Monitoring Tool)

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document fournit des étapes pour aider au problème lié de surveillance et de dépannage au taux d'utilisation du processeur élevé sur Cisco Unified Communications Manager 6.0 avec RTMT.

Conditions préalables

Conditions requises

Cisco recommande que vous ayez la connaissance de ce thème :

  • Cisco Unified Communications Manager

Composants utilisés

Les informations dans ce document sont basées sur ces points de l'ordre du jour :

Les informations dans ce document sont basées sur Cisco Unified Communications Manager 6.0.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Heure système, temps d'utilisateur, IOWait, IRQ doux, et IRQ

L'utilisation de RTMT pour isoler des problèmes potentiels avec la CPU peut être une étape de dépannage très utile.

Ces termes représentent l'utilisation des états de page de CPU et mémoire RTMT :

  • %System : le pourcentage de l'utilisation du processeur qui s'est produit dans l'exécution à l'au niveau système (le noyau)

  • %User : le pourcentage de l'utilisation du processeur qui s'est produit dans l'exécution au niveau utilisateur (l'application)

  • %IOWait : le pourcentage du temps qui la CPU était de veille car elle a attendu une demande exceptionnelle E/S de disque

  • %SoftIRQ : le pourcentage du temps que le processeur exécute a reporté le traitement IRQ (par exemple, le traitement des paquets du réseau)

  • %IRQ le pourcentage du temps que le processeur exécute la demande d'interruption, qui est assignée aux périphériques pour l'interruption, ou envoie un signal à l'ordinateur quand il est traitement de finition

Alertes de chevillage CPU

CPUPegging/CallProcessNodeCPUPegging alerte l'utilisation du CPU de moniteur basée sur les seuils configurés :

Remarque: %CPU est calculé en tant que %system + %user + %nice + %iowait + %softirq + %irq

Les messages d'alerte incluent ces derniers :

  • %system, %user, %nice, %iowait, %softirq, et %irq

  • Le processus qui utilise la plupart de CPU

  • Les processus qui attendent sur le sommeil non interruptible de disque

Des alertes de chevillage CPU peuvent être soulevées dans RTMT dû à une utilisation du CPU plus élevée que ce qui est défini comme niveau de filigrane. Puisque le CDR est une application intensive CPU quand il charge, vérifiez si vous recevez les alertes pendant la même période que quand le CDR est configuré pour exécuter des états. Dans ce cas, vous pouvez devoir augmenter les valeurs seuil sur RTMT. Référez-vous aux alertes pour plus d'informations sur des alertes RTMT.

Identification du processus qui utilise la plupart de CPU

Si %system et/ou %user est assez élevé pour générer l'alerte de CpuPegging, vérifiez le message d'alerte pour voir quels processus utilisent la plupart de CPU.

Remarque: Allez à la page de processus RTMT et le triez par %CPU pour identifier les processus CPU de haute.

/image/gif/paws/97086/ccm6_cpu1.gif

Remarque: Pour l'analyse post mortem, le RIS dépannant le log de PerfMon suit l'utilisation du processus %CPU, et il dépiste au niveau du système.

IOWait élevé

La haute %IOWait indique des activités élevées E/S de disque. Considérez ces derniers :

  • IOWait est dû à l'échange lourd de mémoire.

    Vérifiez les % de temps- CPU pour la partition d'échange pour voir s'il y a haut niveau d'activité d'échange de mémoire. Puisque le rassemblement a au moins la RAM 2G, l'échange de mémoire élevée est vraisemblablement dû à une fuite de mémoire.

  • IOWait est dû à l'activité de DB.

    Le DB est principalement le seul qui accède à la partition active. Si % de temps- CPU pour la partition active est haute, vraisemblablement il y a beaucoup d'activité de DB.

IOWait élevé dû à la partition commune

La partition commune (ou log) est l'emplacement dans lequel le suivi et les fichiers journal sont enregistrés.

Remarque: Vérifiez les points suivants :

  • Central de suivi et de log — Y a-t-il une activité de collecte de suivi ? Si le Traitement des appels est affecté (c'est-à-dire, CodeYellow), ajustez le programme de collecte de suivi. En outre, si l'option de zip est utilisée, tour outre dont.

  • Configuration de suivi — Au niveau d'analyse détaillé, le CallManager génère tout à fait un bit de suivi. Si la haute %IOWait et/ou CCM est dans l'état de CodeYellow et la configuration de suivi de service de CallManager est à détaillé, l'essai pour le changer à la « erreur. »

Identification du processus responsable de l'E/S de disque

Il n'y a aucun moyen direct de découvrir l'utilisation %IOWait par processus. Actuellement, la meilleure manière est de vérifier les processus attendant sur le disque.

Si %IOWait est assez élevé pour entraîner une alerte de CpuPegging, vérifiez le message d'alerte pour déterminer les processus attendant l'E/S de disque.

  • Allez à la page de processus RTMT et le triez par état. Vérifiez les processus dans l'état non interruptible de sommeil de disque. Le processus de SFTP utilisé par la chromatographie sur couche mince pour la collection programmée est dans l'état non interruptible de sommeil de disque.

    /image/gif/paws/97086/ccm6_cpu2.gif

    Remarque: Le RIS dépannant le fichier journal de PerfMon peut être téléchargé pour examiner l'état du processus pendant de plus longues périodes.

  1. Dans l'outil de suivi en temps réel, allez au système > aux outils > au suivi > au suivi et connectez-vous le central.

    /image/gif/paws/97086/ccm6_cpu3.gif

  2. Double-cliquer collectent des fichiers et choisissent ensuite.

    /image/gif/paws/97086/ccm6_cpu4.gif

  3. Choisissez le RIS Data Collector PerfMonLog de Cisco et choisissez ensuite.

    /image/gif/paws/97086/ccm6_cpu5.gif

  4. Dans le domaine de temps de collecte, configurez la durée requise pour visualiser des fichiers journal pour la période en question. Dans le domaine d'options de fichier téléchargé, parcourez à votre chemin de téléchargement (un emplacement duquel vous pouvez lancer le moniteur de performances de Windows pour visualiser le fichier journal), choisissez les fichier zip, et choisissez la finition.

    /image/gif/paws/97086/ccm6_cpu6.gif

  5. Notez les fichiers de collecter progressent et téléchargent le chemin. Aucune erreur ne devrait être signalée ici.

    /image/gif/paws/97086/ccm6_cpu7.gif

  6. Visualisez les fichiers journal de représentation avec l'outil de moniteur de Microsoft Performance. Choisissez le début > les configurations > le panneau de configuration > les outils d'administration > la représentation.

    /image/gif/paws/97086/ccm6_cpu8.gif

  7. Dans la fenêtre d'application, cliquez avec le bouton droit et choisissez Properties.

    /image/gif/paws/97086/ccm6_cpu9.gif

  8. Choisissez l'onglet de source dans la boîte de dialogue Properties de moniteur système. Choisissez les fichiers journal : comme point d'émission de données, et cliquez sur le bouton d'ajouter.

    /image/gif/paws/97086/ccm6_cpu10.gif

  9. Parcourez au répertoire où vous avez téléchargé le fichier journal de PerfMon et choisissez le fichier de csv de perfmon. Le fichier journal inclut cette convention nommante :

    PerfMon_<node>_<month>_<day>_<year>_<hour>_<minute>.csv ; par exemple, PerfMon_10.89.35.218_6_20_2005_11_27.csv.

  10. Cliquez sur Apply.

  11. Cliquez sur le bouton de plage de temps. Afin de spécifier la plage de temps dans le fichier journal de PerfMon que vous voulez visualiser, faites glisser la barre au début et aux heures de fin appropriés.

  12. Afin d'ouvrir la boîte de dialogue de compteurs d'ajouter, cliquez sur l'onglet de données et cliquez sur Add. De la liste déroulante d'objet de représentation, ajoutez le processus. Choisissez l'état du processus et cliquez sur tous les exemples. Quand vous terminez les choix de compteurs, cliquez sur étroitement.

    /image/gif/paws/97086/ccm6_cpu11.gif

  13. Conseils pour quand vous visualisez le log :

    • Placez l'échelle verticale de graphique au maximum 6.

    • Concentrez sur chaque processus et regardez la valeur maximale de 2 ou plus grand.

    • Supprimez les processus qui ne sont pas dans le sommeil non interruptible de disque.

    • Utilisez l'option de point culminant.

    /image/gif/paws/97086/ccm6_cpu12.gif

    Remarque: L'état du processus 2 = sommeil non interruptible de disque sont suspect. D'autres possibilités d'état sont 0 ? s'exécutant, 1 ? dormant, 2 ? sommeil non interruptible de disque, 3 ? zombies, 4 ? tracé ou arrêté, 5 ? paginations, 6 ? inconnu

Codez le jaune

L'alerte jaune de code est générée quand le service de CallManager entre dans l'état de jaune de code. Pour plus d'informations sur Code Yellow State, référez-vous à l'étranglement d'appel et à Code Yellow State. L'alerte de CodeYellow peut être configurée pour télécharger des fichiers de suivi pour dépannage des buts.

Le compteur d'AverageExpectedDelay représente le délai prévu moyen d'attente en cours pour manipuler n'importe quel message d'arrivée. Si la valeur est au-dessus de la valeur spécifique dans le paramètre de service « de latence jaune d'entrée de code », l'alarme de CodeYellow est générée. Ce compteur peut être un indicateur principal de représentation de Traitement des appels.

CodeYellow mais utilisation du CPU totale est seulement 25% - pourquoi ?

Il est possible que le CallManager entre dans l'état de CodeYellow dû à un manque de ressources en processeur quand toute l'utilisation du CPU est seulement environ 25-35 pour cent dans une case 4-virtual-processor.

Remarque: Le HyperThreading étant activé, un serveur avec deux processeurs physiques a quatre processeurs virtuels.

Remarque: De même, sur un serveur de deux-processeur, CodeYellow est possible à environ 50 pour cent d'utilisation du CPU de total.

Alerte : Le « état du service est EN BAISSE. Interface de Messagerie de Cisco. »

Si RTMT envoie l'état du service est EN BAISSE. Interface de Messagerie de Cisco. alerte, vous devez mettre le service hors fonction d'interface de Messagerie de Cisco si CUCM n'est pas intégré avec un système de messagerie de Voix de tiers. Si vous désactivez le service d'interface de Messagerie de Cisco, il arrête d'autres alertes de RTMT.


Informations connexes


Document ID: 97086