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)

Options de téléchargement

  • PDF     (546.6 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (694.7 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (964.2 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:30 janvier 2009
ID du document:97086

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Introduction

Ce document fournit des étapes pour aider à la surveillance et au dépannage des problèmes liés à l'utilisation élevée du processeur sur Cisco Unified Communications Manager 6.0 avec RTMT.

Conditions préalables

Conditions requises

Cisco recommande que vous ayez une connaissance de ce sujet :

  • Solutions Cisco Unified Communications Manager

Components Used

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

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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

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

Heure système, heure utilisateur, IOWait, IRQ logiciel et IRQ

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

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

  • %Système : Le pourcentage d'utilisation du CPU qui s'est produit lors de l'exécution au niveau du système (noyau)

  • %Utilisateur : Le pourcentage d'utilisation du processeur qui s'est produit lors de l'exécution au niveau de l'utilisateur (application)

  • %IOWait : Pourcentage de temps pendant lequel le processeur était inactif en attendant une demande d'E/S de disque en attente

  • %SoftIRQ : Pourcentage de temps pendant lequel le processeur exécute un traitement IRQ différé (par exemple, le traitement des paquets réseau)

  • %IRQ le pourcentage de temps pendant lequel le processeur exécute la demande d'interruption, qui est affectée aux périphériques pour l'interruption, ou envoie un signal à l'ordinateur une fois le traitement terminé

Alertes de consignation du processeur

Les alertes CPUPegging/CallProcessNodeCPUPegging surveillent l'utilisation du CPU en fonction des seuils configurés :

Remarque : %CPU est calculé comme %system + %user + %nice + %iowait + %softirq + %irq

Les messages d'alerte incluent :

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

  • Processus qui utilise le plus de CPU

  • Les processus qui attendent la mise en veille du disque sans interruption

Les alertes de pagination du processeur peuvent apparaître dans RTMT en raison d'une utilisation plus élevée du processeur que ce qui est défini comme le niveau du filigrane. Comme le CDR est une application gourmande en CPU lorsqu'il se charge, vérifiez si vous recevez les alertes au cours de la même période que lorsque le CDR est configuré pour exécuter des rapports. Dans ce cas, vous pouvez avoir besoin d'augmenter les valeurs de seuil sur RTMT. Référez-vous à Alertes pour plus d'informations sur les alertes RTMT.

Identification du processus qui utilise le plus de CPU

Si %system et/ou %user sont suffisamment élevés pour générer une alerte CpuPegging, vérifiez le message d'alerte pour voir quels processus utilisent le plus de CPU.

Remarque : Accédez à la page Processus RTMT et triez par %CPU pour identifier les processus CPU élevés.

ccm6_cpu1.gif

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

IOWait élevé

La valeur élevée de %IOWait indique des activités d'E/S de disque élevé. Considérez les points suivants :

  • IOWait est dû à un échange de mémoire important.

    Vérifiez le %CPU Time for Swap Partition pour voir s'il y a un niveau élevé d'activité d'échange de mémoire. Comme Muster dispose d'au moins 2 Go de mémoire RAM, un échange de mémoire élevé est probablement dû à une fuite de mémoire.

  • IOWait est dû à l'activité de la base de données.

    DB est principalement le seul qui accède à la partition active. Si %CPU Time for Active Partition est élevé, il est probable qu'il y ait beaucoup d'activité de base de données.

Attente IOWa élevée en raison d'une partition commune

La partition commune (ou log) est l'emplacement dans lequel les fichiers de trace et de journal sont stockés.

Remarque : cochez les cases suivantes :

  • Trace & Log Central : existe-t-il une activité de collecte de trace ? Si le traitement des appels est affecté (c'est-à-dire CodeYellow), ajustez le calendrier de collecte de trace. En outre, si l'option zip est utilisée, désactivez-la.

  • Paramètre de suivi : au niveau Détaillé, CallManager génère pas mal de suivi. Si la valeur élevée de %IOWait et/ou CCM est à l'état CodeYellow et que le paramètre de suivi du service CallManager est à l'état Détaillé, essayez de la remplacer par « Erreur ».

Identification du processus responsable des E/S disque

Il n'existe aucun moyen direct de connaître l'utilisation de %IOWait par processus. Actuellement, le meilleur moyen est de vérifier les processus en attente sur le disque.

Si %IOWait est suffisamment élevé pour provoquer une alerte CpuPegging, vérifiez le message d'alerte pour déterminer les processus en attente d'E/S disque.

  • Accédez à la page Processus RTMT et triez par état. Recherchez les processus en veille sur disque sans interruption. Le processus SFTP utilisé par TLC pour la collecte planifiée est en état de veille sur disque sans interruption.

    ccm6_cpu2.gif

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

  1. Dans l'outil de surveillance en temps réel, accédez à System > Tools > Trace > Trace & Log Central.

    ccm6_cpu3.gif

  2. Double-cliquez sur Collecter les fichiers et sélectionnez Suivant.

    ccm6_cpu4.gif

  3. Choisissez Cisco RIS Data Collector PerfMonLog et choisissez Suivant.

    ccm6_cpu5.gif

  4. Dans le champ Temps de collecte, configurez le temps nécessaire pour afficher les fichiers journaux pour la période en question. Dans le champ Options du fichier de téléchargement, accédez à votre chemin de téléchargement (emplacement à partir duquel vous pouvez lancer l'Analyseur de performances Windows pour afficher le fichier journal), choisissez Fichiers zip, puis choisissez Terminer.

    ccm6_cpu6.gif

  5. Notez le chemin d'avancement et de téléchargement de Collect Files. Aucune erreur ne doit être signalée ici.

    ccm6_cpu7.gif

  6. Affichez les fichiers journaux de performances à l'aide de l'outil Microsoft Performance Monitor. Choisissez Démarrer > Paramètres > Panneau de configuration > Outils d'administration > Performances.

    ccm6_cpu8.gif

  7. Dans la fenêtre de l'application, cliquez avec le bouton droit de la souris et sélectionnez Propriétés.

    ccm6_cpu9.gif

  8. Sélectionnez l'onglet Source dans la boîte de dialogue Propriétés du Moniteur système. Choisissez Fichiers journaux : comme source de données, puis cliquez sur le bouton Ajouter.

    ccm6_cpu10.gif

  9. Accédez au répertoire dans lequel vous avez téléchargé le fichier journal PerfMon et sélectionnez le fichier perfmon csv. Le fichier journal inclut cette convention d'attribution de noms :

    PerfMon_<noeud>_<mois>_<jour>_<année>_<heure>_<minute>.csv ; par exemple, PerfMon_10.89.35.218_6_20_2005_11_27.csv.

  10. Cliquez sur Apply.

  11. Cliquez sur le bouton Plage de temps. Afin de spécifier l'intervalle de temps dans le fichier journal PerfMon que vous voulez afficher, faites glisser la barre vers les heures de début et de fin appropriées.

  12. Afin d'ouvrir la boîte de dialogue Ajouter des compteurs, cliquez sur l'onglet Données et cliquez sur Ajouter. Dans la liste déroulante Objet de performance, ajoutez Process. Choisissez État du processus et cliquez sur Toutes les instances. Lorsque vous avez terminé les choix de compteurs, cliquez sur Fermer.

    ccm6_cpu11.gif

  13. Conseils relatifs à l'affichage du journal :

    • Définissez l'échelle verticale du graphique sur Maximum 6.

    • Concentrez-vous sur chaque processus et observez la valeur maximale de 2 ou plus.

    • Supprimer les processus qui ne sont pas en veille sur disque sans interruption.

    • Utilisez l'option de surbrillance.

    ccm6_cpu12.gif

    Remarque : État du processus 2 = Mise en veille sur disque sans interruption suspecte. D'autres possibilités d'état sont les suivantes : 0 exécution, 1 mise en veille, 2 mises en veille sur disque sans interruption, 3-Zombie, 4-Tracé ou arrêté, 5-Paging, 6-Inconnu

Code jaune

L'alerte Code Yellow est générée lorsque le service CallManager passe à l'état Code Yellow. Pour plus d'informations sur l'état Jaune du code, référez-vous à Contrôle d'appel et État Jaune du code. L'alerte CodeYellow peut être configurée pour télécharger les fichiers Trace à des fins de dépannage.

Le compteur MoyenneDélaiAttendu représente le délai moyen prévu actuel pour traiter tout message entrant. Si la valeur est supérieure à la valeur spécifiée dans le paramètre de service Code Yellow Entry Latency, l'alarme CodeYellow est générée. Ce compteur peut être un indicateur clé des performances de traitement des appels.

CodeJaune, mais l'utilisation totale du CPU est seulement de 25 % - Pourquoi ?

Il est possible que CallManager passe à l'état CodeYellow en raison d'un manque de ressources processeur alors que l'utilisation totale du CPU est d'environ 25 à 35 % dans un boîtier à 4 processeurs virtuels.

Remarque : avec Hyper-Threading activé, un serveur doté de deux processeurs physiques dispose de quatre processeurs virtuels.

Remarque : De même, sur un serveur à deux processeurs, CodeYellow est possible avec une utilisation totale de l'UC d'environ 50 %.

Alerte : « L'état du service est désactivé. Interface de messagerie Cisco. »

Si RTMT envoie le statut du service est DÉSACTIVÉ. Interface de messagerie Cisco. , vous devez désactiver le service Cisco Messaging Interface si CUCM n'est pas intégré à un système de messagerie vocale tiers. Si vous désactivez le service Cisco Messaging Interface, il arrête d'autres alertes de RTMT.

Informations connexes

Historique de révision

Révision Date de publication Commentaires
1.0
30-Jan-2009
Première publication

Ce document vous est-il utile?

FeedbackCommentaires

Contacter Cisco

Ce document s’applique à ces produits