Monitoração e solução de problemas da CPU alta do Cisco Unified Communications Manager 6.0 usando a ferramenta de monitoramento em tempo real (RTMT)

Introduction

Este documento fornece etapas para ajudar na monitoração e na solução de problemas relacionados à alta utilização do processador no Cisco Unified Communications Manager 6.0 com RTMT.

Prerequisites

Requirements

A Cisco recomenda ter conhecimento deste tópico:

• Cisco Unified Communications Manager

Componentes Utilizados

As informações neste documento se baseiam nos seguintes itens da agenda:

• Hora do sistema, Hora do usuário, IOWait, IRQ suave e IRQ

• Alertas de Pegging da CPU

• Identificação do processo que usa a maior parte da CPU

• Alta IOWait

• Alta IOW devido à partição comum

• Identificação do processo responsável pela E/S do disco

• Código amarelo

• Code Yellow, mas o uso total da CPU é de apenas 25% - Por quê?

As informações neste documento são baseadas no 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

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

Hora do sistema, Hora do usuário, IOWait, IRQ suave e IRQ

A utilização da RTMT para isolar possíveis problemas com a CPU pode ser uma etapa muito útil na solução de problemas.

Estes termos representam o uso de relatórios de páginas RTMT CPU e Memória:

• %Sistema: o percentual de utilização da CPU que ocorreu durante a execução no nível do sistema (kernel)

• %Usuário: o percentual de utilização da CPU que ocorreu na execução no nível do usuário (aplicativo)

• %IOWait: o percentual de tempo em que a CPU ficou ociosa enquanto aguardava por uma solicitação de E/S de disco pendente

• %SoftIRQ: o percentual de tempo em que o processador executa o processamento de IRQ diferido (por exemplo, processamento de pacotes de rede)

• %IRQ a porcentagem de tempo que o processador executa a solicitação de interrupção, que é atribuída a dispositivos para interrupção, ou envia um sinal ao computador quando o processamento é concluído

Alertas de Pegging da CPU

Os alertas CPUPegging/CallProcessNodeCPUPegging monitoram o uso da CPU com base nos limiares configurados:

Nota: %CPU é calculado como %system + %user + %nice + %iowait + %softirq + %irq

As mensagens de alerta incluem:

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

• O processo que usa a maior parte da CPU

• Os processos que aguardam no modo de espera do disco ininterrupto

Os alertas de Pegging da CPU podem aparecer na RTMT devido ao uso mais alto da CPU do que o definido como nível de marca d'água. Como o CDR é um aplicativo com uso intenso da CPU quando ele é carregado, verifique se você recebe os alertas no mesmo período em que o CDR está configurado para executar relatórios. Nesse caso, você pode precisar aumentar os valores de limite em RTMT. Consulte Alertas para obter mais informações sobre alertas RTMT.

Identificação do processo que usa a maior parte da CPU

Se %system e/ou %user estiverem altos o suficiente para gerar o alerta CpuPegging, verifique a mensagem de alerta para ver quais processos usam a CPU mais.

Observação: vá para a página RTMT Process e classifique por %CPU para identificar os processos de CPU mais altos.

Observação: para análise post mortem, o log de PerfMon de Troubleshooting RIS rastreia o processo %CPU e rastreia no nível do sistema.

Alta IOWait

Alta %IOAit indica atividades de E/S de disco elevadas. Considere estes:

• IOWait é devido a uma troca de memória intensa.

  Verifique o %CPU Time for Swap Partition (Tempo da CPU %para a Partição de Troca) para ver se há um alto nível de atividade de troca de memória. Como o Muster tem pelo menos 2 G de RAM, é provável que haja uma alta troca de memória devido a um vazamento de memória.

• IOWait é devido à atividade de BD.

  O DB é principalmente o único que acessa a Partição Ativa. Se %CPU Time for Ative Partition for high (Tempo de CPU para a partição ativa), provavelmente há muita atividade de DB.

Alta IOW devido à partição comum

Partição comum (ou log) é o local no qual os arquivos de rastreamento e log são armazenados.

Nota: Verifique estes:

• Central de rastreamento e log—Há alguma atividade de coleta de rastreamento? Se o processamento da chamada for afetado (ou seja, CodeYellow), ajuste a programação da coleta de rastreamento. Além disso, se a opção zip for usada, desligue-a.

• Configuração de rastreamento—No nível Detalhado, o CallManager gera bastante rastreamento. Se %IOWait e/ou CCM estiverem no estado CodeYellow e a configuração de rastreamento de serviço CallManager estiver em Detailed, tente alterá-lo para "Error".

Identificação do processo responsável pela E/S do disco

Não há maneira direta de descobrir o uso de %IOWait por processo. Atualmente, a melhor maneira é verificar os processos aguardando no disco.

Se %IOWait for alto o suficiente para causar um alerta CpuPegging, verifique a mensagem de alerta para determinar os processos aguardando I/O do disco.

• Vá para a página Processo RTMT e classifique por Status. Verifique os processos no estado de suspensão do disco ininterrupto. O processo SFTP usado pelo TLC para coleta agendada está no estado de suspensão de disco ininterrupto.

  

  Observação: o arquivo de log do PerfMon de solução de problemas RIS pode ser baixado para examinar o status do processo por períodos maiores.

1. Na Real Time Monitoring Tool, vá para System > Tools > Trace > Trace & Log Central.

   

2. Clique duas vezes em Coletar arquivos e escolha Avançar.

   

3. Escolha Cisco RIS Data Collector PerfMonLog e escolha Next.

   

4. No campo Tempo de coleta, configure o tempo necessário para exibir arquivos de log para o período em questão. No campo Download File Options, navegue até o caminho de download (um local no qual você pode iniciar o Windows Performance Monitor para visualizar o arquivo de log), escolha Zip Files e escolha Finish.

   

5. Observe o progresso do processo de coleta de arquivos e o caminho de download. Nenhum erro deve ser relatado aqui.

   

6. Veja os arquivos de log de desempenho com a ferramenta Microsoft Performance Monitor. Escolha Iniciar > Configurações > Painel de Controle > Ferramentas Administrativas > Desempenho.

   

7. Na janela do aplicativo, clique com o botão direito do mouse e escolha Propriedades.

   

8. Escolha a guia Origem na caixa de diálogo Propriedades do Monitor de Sistema. Escolha Arquivos de log: como a fonte de dados e clique no botão Adicionar.

   

9. Navegue até o diretório em que você baixou o arquivo de log PerfMon e escolha o arquivo permon csv. O arquivo de log inclui esta convenção de nomenclatura:

   PerfMon_<nó>_<mês>_<dia>_<ano>_<hora>_<minuto>.csv; por exemplo, PerfMon_10.89.35.218_6_20_2005_11_27.csv.

10. Clique em Apply.

11. Clique no botão Intervalo de tempo. Para especificar o intervalo de tempo no arquivo Log do PerfMon que você deseja exibir, arraste a barra até as horas de início e término apropriadas.

12. Para abrir a caixa de diálogo Adicionar contadores, clique na guia Dados e clique em Adicionar. Na caixa suspensa Objeto de desempenho, adicione Processo. Escolha Status do processo e clique em Todas as instâncias. Quando terminar as opções dos contadores, clique em Fechar.

    

13. Dicas para quando visualizar o registro:

    • Defina a escala vertical do gráfico como Máximo 6.

    • Concentre-se em cada processo e veja o valor máximo de 2 ou mais.

    • Exclua os processos que não estão em modo de espera de disco ininterrupto.

    • Use a opção de realce.

    

    Nota: Status do processo 2 = Suspensão de disco ininterrupta são suspeitos. Outras possibilidades de status são: 0-running, 1-sleep, 2-Uninterruptible Dissleep, 3-Zombie, 4-Traced ou stop, 5-Paging, 6-Unknown

Código amarelo

O alerta Code Yellow é gerado quando o serviço CallManager entra no estado Code Yellow. Para obter mais informações sobre o estado amarelo do código, consulte Limitação de chamadas e o estado amarelo do código. O alerta CodeYellow pode ser configurado para baixar arquivos de rastreamento para fins de solução de problemas.

O contador MédiaEsperadaAtraso representa a média atual esperada para tratar qualquer mensagem de entrada. Se o valor estiver acima do valor especificado no parâmetro de serviço "Code Yellow Entry Latency", o alarme CodeYellow será gerado. Este contador pode ser um indicador chave do desempenho do processamento de chamadas.

CodeYellow, mas o uso total da CPU é de apenas 25% - Por quê?

É possível que o CallManager entre no estado CodeYellow devido à falta de recursos do processador quando o uso total da CPU é de apenas 25 a 35 por cento em uma caixa de processador virtual de 4.

Nota: com a tecnologia Hyper-Threading ativada, um servidor com dois processadores físicos tem quatro processadores virtuais.

Nota: Da mesma forma, em um servidor de dois processadores, CodeYellow é possível com cerca de 50% de uso total da CPU.

Alerta: "O status do serviço está desativado. Cisco Messaging Interface."

Se RTMT enviar o status de serviço for DOWN (desativado). Cisco Messaging Interface. alerta, você deve desativar o serviço Cisco Messaging Interface se o CUCM não estiver integrado a um sistema de mensagens de voz de terceiros. Se você desabilitar o serviço Cisco Messaging Interface, ele interrompe outros alertas da RTMT.

Informações Relacionadas

• Suporte à Tecnologia de Voz
• Suporte aos produtos de Voz e Comunicações Unificadas
• Troubleshooting da Telefonia IP Cisco
• Suporte Técnico e Documentação - Cisco Systems