Monitoramento e solução de problemas do Cisco Unified Communications Manager 6.0 High CPU, usando a Real Time Monitoring Tool (RTMT)

Introdução

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

Pré-requisitos

Requisitos

A Cisco recomenda ter conhecimento deste tópico:

• Cisco Unified Communications Manager

Componentes Utilizados

As informações neste documento são baseadas nestes itens da agenda:

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

• Alertas de Pegging de CPU

• Identificação do Processo que Usa a Maior Parte da CPU

• EsperaAlta

• HighIOWait devido à Partição Comum

• Identificação do Processo Responsável pela E/S de Disco

• Código amarelo

• Código Amarelo, mas Uso total da CPU é de apenas 25% - Por quê?

As informações neste documento são baseadas no Cisco Unified Communications Manager 6.0.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

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 de RTMT para isolar possíveis problemas com a CPU pode ser uma etapa muito útil de solução de problemas.

Estes termos representam o uso dos relatórios de CPU RTMT e de página de memória:

• %Sistema: o percentual de utilização da CPU que ocorreu na 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 esperava por uma solicitação de E/S de disco pendente

• %SoftIRQ: a porcentagem de tempo que o processador executa o processamento de IRQ adiado (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 de CPU

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

Observação: %CPU é calculado como %sistema + %usuário + %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 uma suspensão de disco ininterrupta

Os alertas de Pegging de CPU podem surgir no RTMT devido ao uso mais alto da CPU do que o definido como o nível da marca d'água. Como o CDR é um aplicativo que consome muita CPU quando é carregado, verifique se você recebeu 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 o %system e/ou %user for alto o suficiente para gerar o alerta de Pegging de CPU, verifique a mensagem de alerta para ver quais processos usam mais CPU.

Observação: vá até a página Processo RTMT e classifique por %CPU para identificar os processos de alta utilização da CPU.

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

EsperaAlta

Alta %IOWait indica atividades de E/S de disco altas. Considere estes:

• IOWait é devido à troca de memória pesada.

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

• IOWait é devido à atividade do BD.

  O BD é principalmente o único que acessa a Partição Ativa. Se o Tempo de %CPU para a Partição Ativa for alto, é provável que haja muita atividade no BD.

Espera alta devido à partição comum

Partição Comum (ou Log) é o local em que os arquivos de rastreamento e log são armazenados.

Observação: verifique estes:

• Central de Rastreamento e Log — Há alguma atividade de coleta de rastreamento? Se o processamento da chamada for afetado (isto é, CodeYellow), ajuste o agendamento de coleta de rastreamento. Além disso, se a opção zip for usada, desative-a.

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

Identificação do Processo Responsável pela E/S de Disco

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

Se %IOWait estiver alto o suficiente para causar um alerta de CpuPegging, verifique a mensagem de alerta para determinar os processos que estão aguardando a E/S do disco.

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

  

  Observação: o arquivo RIS Troubleshooting PerfMon Log pode ser baixado para examinar o status do processo por períodos mais longos.

1. Na Ferramenta de monitoramento em tempo real, vá para System > Tools > Trace > Trace & Log Central.

   

2. Clique duas vezes em Coletar arquivos e escolha Próximo.

   

3. Selecione 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 a partir do qual você pode iniciar o Monitor de desempenho do Windows para exibir o arquivo de registro), escolha Zip Files e escolha Finish.

   

5. Observe o andamento e o caminho de download de Coletar arquivos. Nenhum erro deve ser relatado aqui.

   

6. Exiba 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 do sistema. Escolha arquivos de log: como a origem de dados e clique no botão Adicionar.

   

9. Navegue até o diretório onde você fez o download do arquivo de log PerfMon e escolha o arquivo perfmon csv. O arquivo de registro inclui esta convenção de nomenclatura:

   PerfMon_<node>_<month>_<day>_<year>_<hour>_<minute>.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 de log PerfMon que você deseja exibir, arraste a barra para 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 de contadores, clique em Fechar.

    

13. Dicas para quando exibir o log:

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

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

    • Excluir processos que não estejam em suspensão de disco ininterrupta.

    • Use a opção de realce.

    

    Observação: Status do processo 2 = Suspensão de disco ininterrupta suspeita. Outras possibilidades de status são 0-execução, 1-repouso, 2-Suspensão de disco ininterrupta, 3-Zumbi, 4-Rastreado ou parado, 5-Paginação, 6-Desconhecido

Código amarelo

O alerta de código amarelo é gerado quando o serviço CallManager entra no estado de código amarelo. Para obter mais informações sobre o Estado de Código Amarelo, consulte Limitação de Chamada e o Estado de Código Amarelo. O alerta CodeYellow pode ser configurado para fazer download de arquivos de rastreamento para fins de solução de problemas.

O contador AverageExpectedDelay representa a média atual do atraso esperado para tratar qualquer mensagem de entrada. Se o valor estiver acima do valor especificado no parâmetro de serviço "Latência de Entrada de Código Amarelo", o alarme CodeYellow será gerado. Esse 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 fica em torno de 25-35 por cento em uma caixa de 4 processadores virtuais.

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

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

Alerta: "O status do serviço é INATIVO. Cisco Messaging Interface".

Se RTMT enviar, o status do serviço será DESATIVADO. Cisco Messaging Interface (Interface de mensagens Cisco). 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 de Interface de Mensagens da Cisco, ele interromperá 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