Voix et communications unifiées : Cisco Unity

Diagnostic des problèmes liés à Domino Unified Communication Services (DUCS)

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


Contenu


Introduction

Ce document discute comment diagnostiquer des problèmes avec le Domino Unified Communication Services de Cisco (DUCS). Ce document discute également des questions connexes de notification, les crash (DUC)/s'arrête, et des problèmes de performance.

Conditions préalables

Conditions requises

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

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Cisco Unity 4.x

  • Cisco Unity 5.x

  • Cisco Unity 7.x

  • Cisco Unity 8.x

Conventions

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

diagnostic du problème

Afin de diagnostiquer des problèmes avec DUCS, vous devez activer le suivi DUC et activer la journalisation console sinon déjà activée. Ensuite, collectez les fichiers de console.log /log.nsf dont répartissez le temps quand le serveur Domino a démarré à quand la question problématique se produit. Si vous diagnostiquez des crash, s'arrête, et des problèmes de performance, vous devez également envoyer le diagnostic de système de notes (NSD). NSD produit un fichier journal qui est automatiquement généré en cas d'un crash de serveur, et est enregistré dans le répertoire des données \ IBM_TECHNICAL_SUPPORT dans votre domino installe le répertoire.

Remarque: Les messages vocaux de mémoires de Cisco Unity dans une messagerie d'utilisateur classent la base de données sur le serveur Domino. Si le domino est installé sur un ou plusieurs serveurs (jamais sur le serveur de Cisco Unity), tous les abonnés doivent avoir leurs boîtes aux lettres de domino sur d'autres serveurs. Chaque serveur Domino qui loge des abonnés de Cisco Unity doit avoir l'IBM Lotus que les transmissions unifiées par domino pour Cisco ont installé.

Activez les informations détaillées de Console.log /Log.nsf

Veillez à placer UCLogLevel d'abord dans le fichier notes.ini.

0 - No logging (This is the same as having no UCLogLevel entry)
1 - Minimal logging - only Fatal and Error events are logged
2 - Normal logging - Fatal, Error and Warning events are logged
3 - Informational logging - Fatal, Error, Warning and Informational events are logged.
4 - Verbose logging - Fatal, Error, Warning, Informational and Verbose events are logged.

Le par défaut est 1, mais 4 est recommandés pour diagnostiquer des problèmes.

Activez le suivi DUC

Le suivi DUC te permet pour voir que les chemins de code que le DUC intervient. Il est difficile comprendre suivi DUC sans avoir le code source. Cependant, vous pouvez voir l'écoulement de base des fonctions, telles que les notifications qui sont créées. Recherchez les messages d'erreur qui pourraient être présents.

Placez ces variables notes.ini :

trace_uc_all=1
trace_uc_dir=<output files dir> (W32 only)

Le serveur Domino doit être redémarré pour des changements des variables d'ini pour avoir lieu. Notez le nom/nom du fichier de l'utilisateur de test et arrêtez le serveur Domino quand vous voulez collecter les fichiers.

Collectez les fichiers .out

Si vous n'êtes pas sûr de quel .out classe pour collecter, envoyez-les tous. Cependant, vérifiez que le .out vous classe collecte est de l'envergure correcte du temps.

Voici quelques type/noms du fichier de problème d'exemple qui pourraient être générés :

  • Erreurs activer/des utilisateurs (envoyez les fichiers de sortie d'ucadminp)

  • Le MWI ne s'active pas pendant la livraison de message (routeur, ucevent, csumhlr, ucxmlextend)

  • Le MWI n'arrête pas sur le message ouvert (serveur, ucevent, csumhlr, ucxmlextend)

  • Crash/coup de serveur (envoyez tous les fichiers de sortie)

NSD pour des crash/s'arrête/problème de performance

NSDs prennent un instantané du contenu trouvé dans la mémoire du processus de notes/domino. NSDs peut afficher ce que les processus ont entraîné à un crash ou à un coup. NSDs devrait se déclencher automatiquement en cas d'un crash, mais pour des problèmes de performance ou s'arrête, intervention manuelle est exigé.

Analyse NSD

Souvent, la première étape prise pour résoudre un crash de serveur est de déterminer le processus qui est tombé en panne le serveur. Dans le domino 6 et plus tard, le fichier NSD peut être un emplacement adapté à démarrer. NSD te fournit toutes les informations en cours sur l'état du serveur, tel que des piles des appels pour tous les thread, les informations de mémoire, et ainsi de suite. En cas d'un crash, un fichier journal NSD est automatiquement généré par le serveur Domino et enregistré dans le répertoire des données \ IBM_TECHNICAL_SUPPORT. Un log NSD aura un nom du fichier avec un groupe date/heure qui affiche le moment où le NSD a été généré. Par exemple, Nsd_W32I_KIRANTP_2006_01_17@17_17_18.log indique que ce NSD a été créé en janvier 17, 2006. Quand NSD fonctionne, il se relie à chaque processus et thread afin de vider les piles des appels. Ceci peut vous aider à déterminer la cause d'un crash de serveur ou de poste de travail.

Le coeur d'un fichier NSD est la section de suivi de pile. Cette section fournit une répartition du chemin de code de chaque thread dans un processus existant traversé pour le mettre dans son état actuel. C'est utile d'examiner le coup ou de tomber en panne des situations sur un serveur. En outre, en examinant le fichier NSD, vous pouvez trouver tous les fichiers image mémoire générés dans un répertoire des données de domino, et pouvez exécuter une analyse niveau de la base afin de tracer la pile finale d'appels qui ont été faits par le processus qui est mort et est parti derrière le noyau. Dans un produit complexe tel que le domino, un suivi de pile du même type d'action sur deux serveurs différents peut produire différents résultats.

Dans le fichier NSD, vous pouvez exécuter un mot recherchez « mortel », « panique », ou « segmentation » afin d'identifier l'exécutable dans le processus manquant. En trouvant le processus, vous pouvez voir ce qui l'a précédé, et déterminez si tout va bien comment le crash s'est produit. Quand ni la « panique » ou « mortels » sont trouvés, parfois un vidage de mémoire contiendra une référence à un « défaut de segmentation » dans une fonction. Ceci indique que le processus essayé pour accéder à un segment partagé de mémoire qui a été corrompu pour quelque raison, et tombera en panne sans appeler la « erreur fatale » ou la « panique ».

C'est un extrait témoin à partir d'un fichier NSD où un processus de serveur est impliqué dans un crash :

--------------------------------------------
### FATAL THREAD 39/83 [ nSERVER:07c0: 2764] ### FP=0743f548,
	 PC=60197cf3, SP=0743ebd0, stksize=2424 Exception code: c0000005
	 (ACCESS_VIOLATION) ############################################################
	 @[ 1] 0x60197cf3 nnotes._Panic@4+483 (7430016,496dae76,0,496dace8) @[ 2]
	 0x600018a4 nnotes._OSBBlockAddr@8+148 (1153f38,2000000,743f608,1) @[ 3]
	 0x6000bd92 nnotes._CollectionNavigate@24+610 (0,743fc74,f,0) @[ 4] 0x600626cc
	 nnotes._ReadEntries@68+2860 (4c5440e8,4cfb8dba,800f,1) @[ 5] 0x600b9f6f
	 nnotes._NIFReadEntriesExt@72+351 (0,4cfb8dba,800f,1) @[ 6] 0x10032d40
	 nserverl._ServerReadEntries@8+1424 (0,8d0c0035,4b64b5bc,4ae46dd6) @[ 7]
	 0x100191fc nserverl._DbServer@8+2284 (41b0383,cb740064,0,23696f8) @[ 8]
	 0x1002b8c8 nserverl._WorkThreadTask@8+1576 (4711d68,0,3,563fb10) @[ 9]
	 0x100016cb nserverl._Scheduler@4+763 (0,563fb10,0,10ec334) @[10] 0x6011e5e4
	 nnotes._ThreadWrapper@4+212 (0,10ec334,563fb10,0) [11] 0x77e887dd
	 KERNEL32.GetModuleFileNameA+465
  -------------------------------------------

Quand le processus manquant a été déterminé, vous pouvez se concentrer sur la façon dépanner ce processus particulier.

Exécutez NSD manuellement pour s'arrête et des problèmes de performance

Afin d'accéder à l'aide NSD, nsd de type ? aide. C'est l'utilisation commune :

nsd -ini <notes_ini_file> -log <nsd_output_name> -dumpandkill

Assurez-vous que NSD contient des callstacks, des informations de mémoire, et des informations notes.ini avant que vous envoyiez.

Diagnostiquez les problèmes avec le client DUCS

Le suivi peut être installé sur le lecteur avec des paramètres de registre. Procédez comme suit :

  1. Allez à la clé HKEY_CURRENT_USER/Software/Lotus/DUCS.

  2. Choisi éditez > nouveau > valeur DWORD.

  3. Assignez un nom de DebugFlags puis placez la valeur au fff.

Le fichier de sortie s'appelle le LotusUC.csv et il est trouvé dans le répertoire des données de Lotus.

Si le lecteur tombe en panne, NSD devrait fonctionner. Si le lecteur s'arrête, NSD peut encore être appelé manuellement.

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.


Informations connexes


Document ID: 71316