Voz y Comunicaciones unificadas : Cisco Unity

Diagnóstico del problema unificado dominó de los servicios de comunicación (DUCS)

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento discute cómo diagnosticar los problemas con los servicios de comunicación unificados dominó de Cisco (DUCS). Este documento también discute los asuntos relacionados de la notificación, las caídas/cuelgan (del DUC), y los problemas de rendimiento.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

  • Cisco Unity 4.x

  • Cisco Unity 5.x

  • Cisco Unity 7.x

  • Cisco Unity 8.x

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Diagnostique el problema

Para diagnosticar los problemas con el DUCS, usted necesita habilitar el DUC que localiza y habilitar el registro de la consola si no habilitado ya. Después, recoja los archivos de console.log /log.nsf de los cuales atraviese el tiempo cuando el servidor Domino comenzó a cuando sucede el problema problemático. Si usted diagnostica las caídas, cuelga, y los problemas de rendimiento, usted también necesita enviar el Diagnóstico de sistema de las notas (NSD). NSD presenta un archivo del registro que se genere automáticamente en caso de caída del servidor, y se salva en el directorio de los datos \ IBM_TECHNICAL_SUPPORT en su dominó instala el directorio.

Nota: Los mensajes de voz de los almacenes del Cisco Unity en un correo del usuario clasifían la base de datos en el servidor Domino. Si el dominó está instalado en uno o más servidores (nunca en el servidor del Cisco Unity), todos los suscriptores deben tener sus buzones del dominó en otros servidores. Cada servidor Domino que contiene a los suscriptores de Cisco Unity debe tener Comunicaciones unificadas del IBM Lotus Domino para Cisco instaló.

Gire la información detallada de Console.log /Log.nsf

Aseegurese para fijar UCLogLevel primero en el archivo 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.

El valor por defecto es 1, pero 4 se recomienda para diagnosticar los problemas.

Gire localizar del DUC

El localizar del DUC permite que usted considere vayan las rutas de acceso de código el DUC a través. El localizar del DUC es difícil de entender sin tener el código fuente. Sin embargo, usted puede ver el flujo básico de funciones, tales como notificaciones se creen que. Busque para los mensajes de error que pudieron estar presentes.

Fije estas variables notes.ini:

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

El servidor Domino se debe recomenzar para los cambios en las variables del ini para ocurrir. Tome la nota del nombre/del nombre de fichero del usuario de la prueba y pare el servidor Domino cuando usted quiere recoger los archivos.

Recoja los archivos .out

Si usted no está seguro de qué .out clasifía para recoger, envíelo todo. Sin embargo, verifique que el .out le clasifíe recoja sea del palmo correcto del tiempo.

Aquí está algún tipo de problema/nombres de fichero del ejemplo que pudieron ser generados:

  • El habilitar/que inhabilita de los errores a los usuarios (envíe los archivos salientes del ucadminp)

  • El MWI no se gira durante la entrega de mensajes (router, ucevent, csumhlr, el ucxmlextend)

  • El MWI no apaga en el mensaje abierto (servidor, ucevent, csumhlr, el ucxmlextend)

  • Caída/caída del servidor (envíe todos los archivos salientes)

NSD para las caídas/cuelga/problemas de rendimiento

NSDs toma una foto del contenido encontrado en la memoria del proceso de las notas/del dominó. NSDs puede mostrar lo que causaron los procesos una caída o a caída. Se requiere NSDs debe encender automáticamente en caso de caída, pero por problemas de rendimiento o cuelga, intervención manual.

Análisis NSD

A menudo, el primer paso tomado para resolver una caída del servidor es determinar el proceso que causó un crash el servidor. En el dominó 6 y posterior, el archivo NSD puede ser un lugar bueno a comenzar. NSD le da toda la información actual sobre el estado del servidor, tal como pilas de llamadas para todos los hilos, Información de la memoria, y así sucesivamente. En caso de caída, un archivo del registro NSD es generado automáticamente por el servidor Domino y salvado en el directorio de los datos \ IBM_TECHNICAL_SUPPORT. Un registro NSD tendrá un nombre del archivo con un sello de fecha/hora que muestre el tiempo en que el NSD fue generado. Por ejemplo, Nsd_W32I_KIRANTP_2006_01_17@17_17_18.log indica que este NSD fue creado en enero 17, 2006. Cuando NSD se ejecuta, asocia a cada proceso e hilo para vaciar las pilas de llamadas. Esto puede ayudarle a determinar la causa de una caída del servidor o del puesto de trabajo.

El corazón de un archivo NSD es la sección del seguimiento de pila. Esta sección proporciona una ruptura de la ruta de acceso de código de cada hilo en un proceso existente atravesado para ponerlo en su estado actual. Esto es útil examinar la caída o causar un crash las situaciones en un servidor. También, examinando el archivo NSD, usted puede encontrar cualquier archivo núcleo generado en un directorio de datos del dominó, y puede realizar un análisis del base-nivel para localizar el stack final de las llamadas que fueron hechas por el proceso que murió y se fue detrás de la base. En un producto complejo tal como dominó, un seguimiento de pila del mismo tipo de acción en dos diversos servidores puede producir diversos resultados.

En el archivo NSD, usted puede realizar una búsqueda de la palabra para “fatal”, el “pánico”, o la “segmentación” para identificar el ejecutable en el proceso que falla. Encontrando el proceso, usted puede ver qué lo precedió, y esperanzadamente determina cómo ocurrió la caída. Cuando ni se encuentra el “pánico” o “fatales”, un vaciado de memoria contendrá a veces una referencia a un “incidente de la segmentación” en una función. Esto indica que el proceso intentado para acceder un segmento de la memoria compartida que fue corrompido por alguna razón, y causará un crash sin la llamada del “error fatal” o del “pánico”.

Esto es un extracto de la muestra de un archivo NSD donde un proceso del servidor está implicado en una caída:

--------------------------------------------
### 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
  -------------------------------------------

Cuando se ha determinado el proceso que fallaba, usted puede centrarse en cómo resolver problemas ese proceso determinado.

Ejecute NSD para cuelga manualmente y los problemas de rendimiento

Para acceder la ayuda NSD, teclee el nsd – ayuda. Éste es el uso común:

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

Aseegure NSD contiene los callstacks, la Información de la memoria, y la información notes.ini antes de que usted envíe.

Diagnostique los problemas con el cliente DUCS

El seguimiento se puede configurar en el jugador con una configuración del registro. Complete estos pasos:

  1. Vaya a la clave HKEY_CURRENT_USER/Software/Lotus/DUCS.

  2. Seleccione el Edit (Editar) > New (Nuevo) > DWORD Value (Valor DWORD).

  3. Asigne un nombre de DebugFlags después fije el valor al fff.

El archivo saliente se llama LotusUC.csv y se encuentra en el directorio de datos de Lotus.

Si el jugador causa un crash, NSD debe ejecutarse. Si el jugador cuelga, NSD se puede todavía invocar manualmente.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 71316