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

Panne de service Cisco CallManager

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


Contenu


Introduction

Ce document fournit des informations au sujet d'un crash de Cisco CallManager, comment déterminer si vous avez éprouvé un crash, les informations pour recueillir et fournir au support technique de Cisco, et comment rechercher les bogues de crash de Cisco CallManager qui existent.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

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

Description de crash de service de Cisco CallManager

Quand les crash du service de Cisco CallManager (ccm.exe), vous voient ce message dans le journal d'événements de système :

The Cisco CallManager service terminated unexpectedly. 
It has done this 1 time. The following corrective action 
will be taken in 60000 ms. Restart the service.

D'autres messages que vous pouvez voir en cas d'un crash sont :

Timeout 3000 milliseconds waiting for Cisco 
CallManager service to connect. 

The Cisco CallManager failed to start due to the following error. 
The service did not respond to the start or control request in a timely fashion.

À ce moment, quand les périphériques comme des Téléphones IP de Cisco et unregister de passerelles du Cisco CallManager, expérience d'utilisateurs ont retardé la tonalité, et/ou les gels de serveur Cisco CallManager dus à la CPU de haute. Référez-vous aux journaux d'événements de Cisco CallManager pour des messages de journal d'événements non inclus ici.

Le service de Cisco CallManager peut tomber en panne en raison d'une de ces raisons :

  1. Un événement inattendu se produit dans le service de Cisco CallManager. Ce crash ajoute une entrée au log Dr.Watson qui existe et un User.dmp est généré dans les utilisateurs de C:\Documents and Settings\All de répertoire \ documents \ DrWatson.

  2. Le service de Cisco CallManager n'a pas assez de ressources comme la CPU ou la mémoire afin de fonctionner. Généralement, l'utilisation du processeur dans le serveur est à 100 pour cent à ce moment-là.

Personne à charge sur le type de crash que vous éprouvez, vous devez recueillir les données différentes qui vous aident et le support technique de Cisco pour déterminer la cause principale du crash.

Déterminez le type de crash

Si vous exécutez une recherche sur votre Cisco CallManager après que le crash pour un fichier appelé Drwtsn32.log et l'ouvrez, regardez tout au plus l'entrée récente afin de voir si une entrée pour le ccm.exe a été ajoutée. Ouvrez la procédure de connexion Notepad de Dr. Watson, allez au bas du fichier et recherchez Applicationexception s'est produit, qui vous porte au dernier crash.

C'est un exemple d'en-tête pour une entrée de crash dans drwtsn32.log.

Application exception occurred:
        App:  (pid=680)
        When: 3/8/2003 @ 14:01:06.978
        Exception number: e06d7363

À côté de la date du crash il y a un PID, si ce PID correspond au PID pour ccm.exe dans la liste des tâches alors que vous savez que le Cisco CallManager est tombé en panne.

La liste des tâches dans drwtsn32.log semble semblable à ceci :

PID  PROCESS
   8 System.exe
 212 SMSS.exe
 240 CSRSS.exe
 264 WINLOGON.exe
 292 SERVICES.exe
 304 LSASS.exe
 424 termsrv.exe
 520 svchost.exe
 560 msdtc.exe
 696 DLLHOST.exe
 736 Ipvmsapp.exe
 752 DLLHOST.exe
 824 AudioTranslator.exe
 848 RisDC.exe
 860 LogoutService.E.exe
 884 DCX500.exe
 936 svchost.exe
 980 LLSSRV.exe
1028 sqlservr.exe
1112 ntpd.exe
1140 rcmdsvc.exe
1172 regsvc.exe
1176 mstask.exe
1204 SNMP.exe
1244 WinMgmt.exe
1260 cpqnimgt.exe
1284 cqmgserv.exe
1296 cqmgstor.exe
1308 sysdown.exe
1372 cqmghost.exe
1524 aupair.exe
1552 sqlagent.exe
 276 svchost.exe
2400 inetinfo.exe
2412 explorer.exe
2752 sqlmangr.exe
2700 taskmgr.exe
2704 mmc.exe
 680 ccm.exe
 868 DRWTSN32.exe

Remarque:  Dans cet exemple, PID = 680, qui de la liste, correspond à ccm.exe.

S'il n'y a aucune liste des PID, regardez l'horodateur de la dernière entrée de drwtsn32.log et l'horodateur du log d'erreur en cas. Voyez la section de description de crash de service de Cisco CallManager. S'ils sont les précis la même heure, il est probable que vous ayez éprouvé un crash inattendu de Cisco CallManager d'événement.

Le suivi de pile rend un crash seul, qui est pourquoi le fichier entier de drwtsn32.log dans les informations recueillir et fournir au support technique de Cisco est demandé.

Si le PID pour le jour du crash n'est pas ccm.exe ou l'horodateur ne correspond pas, alors vous très probablement vous êtes exécuté dans un manque de crash de ressource, ou un crash d'un autre processus.

Les informations à recueillir et fournir au support technique de Cisco

Crash inattendu d'événement

Si vous éprouvez un crash inattendu d'événement, terminez-vous ces étapes afin de recueillir des informations pour fournir au support technique de Cisco.

  1. Collectez les suivis de Cisco CallManager 15 minutes avant et après le crash.

    Les suivis se trouvent chez C:\Program Files\cisco\trace\ccm.

  2. Collectez les suivis SDL 15 minutes avant et après le crash.

    Les suivis se trouvent chez C:\Program Files\cisco\trace\sdl\ccm.

  3. Choisissez le Start > Programs > Administrative tools > le visualisateur d'événements afin de recueillir des fichiers de consignation de journal d'événements de système et d'application du visualisateur d'événements.

  4. Cliquez sur en fonction le log système et choisissez le log d'action > de sauvegarde comme et sauvegardez le log.

    Faites la même chose du journal d'application.

  5. Assurez-vous que le paramètre de SdlMaxUnhandledExceptions est placé à 0 (zéro) pour chaque Cisco CallManager.

  6. Collectez le log de Dr. Watson situé aux utilisateurs de C:\Documents and Settings\All \ aux documents \ DrWatson. Le nom du fichier est Drwtsn32.log.

  7. Collectez le fichier situé User.dmp aux utilisateurs de C:\Documents and Settings\All \ aux documents \ DrWatson.

    Remarque: Ces fichiers peuvent être très grands. Soyez sûr de les zipper avant que vous les envoyiez au support technique de Cisco. Il est également important de noter que ces fichiers tiennent les informations l'ingénieur de support technique de Cisco et les développeurs doivent afin de déterminer la cause du crash.

  8. Ouvrez la procédure de connexion Notepad de Dr. Watson et poursuivez à la détermination le type de section de crash afin de découvrir si votre crash est un problème connu.

Manque de crash de ressource

Si vous éprouvez un manque de crash de ressource, terminez-vous ces étapes afin de recueillir des informations pour fournir au support technique de Cisco.

  1. Collectez les suivis de Cisco CallManager 15 minutes avant et après le crash. Les suivis se trouvent chez C:\Program Files\cisco\trace\ccm.

  2. Collectez les suivis SDL 15 minutes avant et après le crash. Les suivis se trouvent chez C:\Program Files\cisco\trace\sdl\ccm.

  3. Collectez les suivis de perfmon si disponible. S'ils ne sont pas disponibles, commencez à collecter des ces et utilisation de mémoire et utilisation du CPU de piste pour chaque processus qui fonctionne sur le serveur. Voyez pour installer des logs de compteur de moniteur de performances pour sectionner afin d'installer des suivis de perfmon. Ceux-ci aident en cas d'un autre manque de ressources à tomber en panne.

Configurations de contrôle sur l'utilitaire de sauvegarde pour éviter la CPU de haute

Assurez-vous que vous exécutez la plus défunte sauvegarde d'applications de Téléphonie sur IP de Cisco afin d'éviter un blocage système dû à la sauvegarde d'applications de Téléphonie sur IP de Cisco qui peut fonctionner pendant une longue période à l'utilisation du CPU élevé. Si vous exécutez le Cisco CallManager 3.1(3a)spC et plus tard ou le Cisco CallManager 3.2(1)spA et plus tard, par ID de bogue Cisco CSCdt91655 (clients enregistrés seulement), le nouveau passage d'utilitaire de sauvegarde à la faible priorité par défaut.

Vous pouvez télécharger la dernière version des applications de Téléphonie sur IP de Cisco de sauvegarde de la page de téléchargement du logiciel de Voix (clients enregistrés seulement) sous le Cisco CallManager.

Remarque: Si vous exécutez un balayage de virus sur les BARRES présentant le répertoire C:\STI quand vous exécutez la sauvegarde, vous pouvez entraîner des pics CPU. Balayage de virus de débronchement sur C:\STI afin d'éviter des utilisations du CPU élevé.

Avant cette modification, les versions préalables ont utilisé un onglet appelé Performance afin de changer la priorité de base du processus qui exécute l'application de sauvegarde d'applications de Téléphonie sur IP de Cisco. Changez la représentation à normal ou bas ci-dessous afin de s'assurer que ce processus ne concurrence pas d'autres processus, qui fonctionnent à la priorité de base normale, pour la CPU, telle que CCM.exe.

ccmcrash-2.gif

Les boucles de routage d'Intercluster peuvent entraîner les pics élevés CPU

Le joncteur réseau d'Intercluster faisant une boucle peut sont provoqué par par un modèle misconfigured d'artère. Ceci peut faire exécuter la CPU élevée pendant une longue période de temps ou tomber en panne le Cisco CallManager le serveur. Le Cisco CallManager a ajouté la logique dans le périphérique H.225 (pour le périphérique de joncteur réseau seulement) afin de surveiller le nombre d'appels de transit exceptionnels afin de résoudre ce problème. L'appel de transit est l'appel que le Cisco CallManager reçoit la demande de configuration pour (ou envoie la demande de configuration pour) et encore ne reçoit pas ou envoie le premier message arrière. Par exemple, la démarche d'appel, progression de l'appel, alerte, connectent, ou libèrent complet. Le Cisco Call manager exécute un cinq-deuxième temporisateur afin de surveiller la file d'attente d'appel de transit pour le périphérique du joncteur réseau H.225. Si le nombre d'entrées de file d'attente d'appel de transit est plus grand qu'un seuil prédéfini, alors, pendant une période (par défaut 30 secondes), toute la nouvelle demande d'appel entrant ou sortant à celle périphérique du joncteur réseau H225 sont rejetées en envoyant les messages terminés par release avec l'encombrement de système de commutateur de code de cause.

En raison de ce comportement de Cisco CallManager, ces erreurs peuvent être vues dans le journal d'application du Cisco CallManager.

  • L'erreur Le message d'erreur d'ICTCallThrottlingStart indique que le Cisco CallManager ne peut pas traiter des appels pour H.323 H.323 indiqué le périphérique en raison d'une boucle d'artère au-dessus du joncteur réseau.

  • L'erreur Le message d'erreur d'ICTCallThrottlingEnd indique que le Cisco CallManager a repris la gestion des appels pour H.323 indiqué le périphérique (en raison arrêté de la boucle d'artère créée au-dessus H.323 du joncteur réseau).

Cessez la boucle de routage entre les batteries afin d'éviter ces erreurs. Référez-vous au guide de manière d'éviter de boucle de Cisco CallManager des pratiques recommandées pour plus d'informations sur la manière d'éviter de boucle de Cisco CallManager.

Logs de compteur de moniteur de performances d'installation

Terminez-vous ces étapes afin de recueillir des compteurs pour le crash afin de vérifier les processus qui fonctionnent et la quantité de CPU et mémoire qui sont consommées.

  1. Choisissez le Start > Programs > Administrative tools > la représentation.

  2. Du moniteur de performances, choisissez les logs de représentation > les alertes > les logs de compteur.

  3. Choisissez l'action > de nouvelles configurations de log et écrivez un nom pour le contre- log.

  4. Sous des compteurs, choisissez ajoutent.

    Utilisez les compteurs d'ordinateur local et assurez-vous que vous configurez ceci directement sur le Cisco CallManager qui éprouve le crash.

  5. Sous l'objet de représentation, choisissez le processus.

  6. Sous les compteurs choisis, mettez en valeur la liste > des exemples choisis, et choisissez ces compteurs et exemples associés :

    • % de temps processeur/tous les exemples

    • Processus d'ID/tout l'exemple

    • Octets virtuels/tous exemples

    • Octets privés/tous exemples

  7. Sous des données d'échantillon chaque, placez l'intervalle à 2 et les unités comme secondes.

  8. À partir des fichiers journal tabulez, assurez-vous que le type de fichier journal est fichier texte - CSV. Également note où ceux-ci se trouvent. Le par défaut est C:\PerfLogs.

  9. Choisissez une limite de fichier journal de 20,000 Ko.

  10. Exécutez ces actions de programme :

    1. Choisissez le log de début manuellement afin de commencer le log.

    2. Choisissez quand le fichier journal du Ko 20,000 est plein afin d'arrêter le log.

    3. Quand le log se ferme, choisissez le début un nouveau fichier journal et puis cliquez sur OK.

  11. Choisissez la contre- commande créée de procédure de connexion pour commencer à se connecter. Choisissez alors l'action > le début.

    Remarque: Au fil du temps, si vous activez ces logs de moniteur de performances, il génère un grand nombre de fichiers et utilise un grand nombre d'espace disque. Par conséquent, il est nécessaire de garder un oeil sur ceci et, s'il est, zippe les logs plus anciens et/ou les déplace du lecteur local.


Informations connexes


Document ID: 19122