Voz e comunicações unificadas : Cisco Unity

Diagnósticos do problema unificados dominó dos serviços de comunicação (DUCS)

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento discute como diagnosticar problemas com os serviços de comunicação unificados dominó de Cisco (DUCS). Este documento igualmente discute problemas relacionados da notificação, os impactos (DUC)/penduram, e problemas de desempenho.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

  • Cisco Unity 4.x

  • Cisco Unity 5.x

  • Cisco Unity 7.x

  • Cisco Unity 8.x

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Diagnostique o problema

A fim diagnosticar problemas com DUCS, você precisa de permitir o traçado DUC e de permitir o logging de console se não já permitido. Em seguida, recolha os arquivos de console.log /log.nsf de que meça o tempo quando o servidor domino começou a quando a edição problemática acontece. Se você diagnostica impactos, pendura, e problemas de desempenho, você igualmente precisa de enviar o Diagnóstico do Sistema das notas (NSD). NSD produz um arquivo de registro que seja gerado automaticamente no caso de um impacto do server, e é armazenado no diretório dos dados \ IBM_TECHNICAL_SUPPORT em seu dominó instala o diretório.

Nota: Os mensagens de voz das lojas do Cisco Unity em um correio do usuário arquivam o banco de dados no servidor domino. Se o dominó está instalado em uns ou vários server (nunca no server do Cisco Unity), todos os assinantes devem ter suas caixas postais do dominó em outros server. Cada servidor domino que abriga assinantes de Cisco Unity deve ter comunicações unificadas do IBM Lotus Domino para Cisco instalou.

Gire sobre a informação detalhada de Console.log /Log.nsf

Certifique-se ajustar UCLogLevel primeiramente no arquivo 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.

O padrão é 1, mas 4 são recomendados diagnosticando problemas.

Gire sobre o traçado DUC

O traçado DUC permite que você considere os trajetos do código o DUC vão completamente. O traçado DUC é difícil de compreender sem ter o código de origem. Contudo, você pode ver o fluxo básico das funções, tais como as notificações que são criadas. A busca para os Mensagens de Erro que puderam esta presente.

Ajuste estas variáveis notes.ini:

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

O servidor domino deve ser reiniciado para mudanças nas variáveis do ini para ocorrer. Tome a nota do nome/nome de arquivo do usuário dos testes e pare o servidor domino quando você quer recolher os arquivos.

Recolha os arquivos .out

Se você não é certo de que .out arquiva para recolher, envie-o todo. Contudo, verifique que o .out o arquiva recolhe é do período correto do tempo.

Está aqui alguns tipo de problema/nomes de arquivo do exemplo que puderam ser gerados:

  • Erros permitindo/usuários da desabilitação (envie arquivos de saída do ucadminp)

  • O MWI não gira sobre durante a entrega de mensagem (roteador, ucevent, csumhlr, o ucxmlextend)

  • O MWI não desliga na mensagem aberto (server, ucevent, csumhlr, o ucxmlextend)

  • Impacto/cair do server (envie todos os arquivos de saída)

NSD para impactos/pendura/problema de desempenho

NSDs toma um instantâneo dos índices encontrados na memória do processo das notas/dominó. NSDs pode mostrar o que os processos causaram a um impacto ou a um cair. NSDs deve atear fogo automaticamente no caso de um impacto, mas para problemas de desempenho ou pendura, intervenção manual é exigido.

Análise NSD

Frequentemente, a primeira etapa tomada para resolver um impacto do server é determinar o processo que causou um crash o server. No dominó 6 e mais tarde, o arquivo NSD pode ser um bom lugar a começar. NSD dá-lhe toda a informação atual sobre o estado do server, tal como pilhas de atendimento para todas as linhas, informação de memória, e assim por diante. No caso de um impacto, um arquivo de registro NSD é gerado automaticamente pelo servidor domino e armazenado no diretório dos dados \ IBM_TECHNICAL_SUPPORT. Um log NSD terá um nome de arquivo com um selo de tempo que mostre o tempo em que o NSD foi gerado. Por exemplo, Nsd_W32I_KIRANTP_2006_01_17@17_17_18.log indica que este NSD esteve criado em janeiro 17, 2006. Quando NSD é executado, anexa a cada processo e linha a fim despejar as pilhas de atendimentos. Isto pode ajudá-lo a determinar a causa de um impacto do server ou da estação de trabalho.

O coração de um arquivo NSD é a seção do rastreamento de pilha. Esta seção fornece uma divisão do trajeto do código de cada linha em um processo existente atravessado para pô-lo em seu estado atual. Isto é útil examinar o cair ou causar um crash situações em um server. Também, examinando o arquivo NSD, você pode encontrar todos os arquivos principais gerados em um diretório de dados do dominó, e pode executar uma análise do base-nível a fim seguir a pilha final de atendimentos que foram feitos pelo processo que morreu e saiu atrás do núcleo. Em um produto complexo tal como o dominó, um rastreamento de pilha do mesmo tipo de ação em dois server diferentes pode produzir resultados diferentes.

No arquivo NSD, você pode executar uma busca da palavra para “fatal”, o “pânico”, ou a “segmentação” a fim identificar o executável no processo de falha. Encontrando o processo, você pode ver o que o precedeu, e determina esperançosamente como o impacto ocorreu. Quando nem o “pânico” ou “fatais” são encontrados, às vezes um dump principal conterá uma referência da “a uma falha segmentação” em uma função. Isto indica que o processo tentou alcançar um segmento da memória compartilhada que seja corrompido por qualquer motivo, e causará um crash sem chamar o “erro fatal” ou o “pânico”.

Este é um trecho da amostra de um arquivo NSD onde um processo de servidor seja envolvido em um impacto:

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

Quando o processo de falha foi determinado, você pode focalizar em como pesquisar defeitos que particular processe.

Execute NSD manualmente para pendura e problemas de desempenho

A fim alcançar a ajuda NSD, datilografe o nsd – ajuda. Este é o uso comum:

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

Certifique-se que NSD contém callstacks, informação de memória, e informação notes.ini antes que você envie.

Diagnostique problemas com o cliente DUCS

O traçado pode estabelecer-se no jogador com uma configuração de registro. Conclua estes passos:

  1. Vá à chave HKEY_CURRENT_USER/Software/Lotus/DUCS.

  2. Seleto edite > novo > valor DWORD.

  3. Atribua um nome de DebugFlags a seguir ajuste o valor ao fff.

O arquivo de saída é chamado LotusUC.csv e encontra-se no diretório de dados de Lotus.

Se o jogador causa um crash, NSD deve ser executado. Se o jogador pendura, NSD pode ainda ser invocado manualmente.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 71316