Resolvendo Problemas dos Aplicativos SIP
É possível usar este tópico para solucionar problemas dos aplicativos SIP.
Sobre Esta Tarefa
Use as configurações básicas de resolução de problemas do contêiner SIP a seguir ao resolver problemas com os aplicativos SIP.
- A utilização de CPU Média do sistema não deve ultrapassar 60% - 70%.
- O contêiner não deve utilizar mais de 70% do tamanho de heap de VM alocado. Certifique-se de que o sistema tenha memória física suficiente para acomodar o tamanho de heap de VM. Os carregamentos de chamada e os tempos limites de sessão terão um grande efeito no uso do heap.
- O tempo máximo de coleta de lixo (GC) da VM no qual o contêiner fica em execução não deve exceder 500 ms e a média deve ser inferior a 400 ms. A GC detalhada pode ser utilizada para medir isso e o visualizador PMI pode ser utilizado para visualizar as quantidades de GC, o uso de heap, as sessões ativas, etc., no formulário gráfico.
Procedimento
- Verifique as portas de atendimento na configuração
- Utilize netstat –an para ver as portas de atendimento.
- Verifique se os hosts virtuais estão definidos
- Verifique se os aliases de host estão definidos.
- Um aplicativo está instalado? Está iniciado
- Para uma configuração proxy: Um cluster padrão está configurado? Se o proxy e o servidor estiverem na máquina, existe um conflito de porta?
Resultados
- Sintoma: Lotes de retransmissões, a CPU cai periodicamente para zero ou uma exceção ThreadPoolQueueIsFullException é vista nos logs
Solução: Tipicamente, este é um problema de DNS causado por consultas de DNS Reverso e pode ser confirmado usando uma ferramenta como Ethereal. Se você executar uma captura de rede e enviar várias consultas DNS que contenham um endereço IP e receber um nome de host na resposta, isso poderia ser o problema. Certifique-se de que nscd está executando se você estiver em HP ou alguma outra plataforma que necessite de armazenamento em cache de serviço de nomes. A plataforma Microsoft Windows não necessita de armazenamento em cache para serviço de nomes. Outra solução seria incluir nomes de host no arquivo /etc/hosts.
- Sintoma: Lotes de retransmissões, a CPU aumenta periodicamente para 100%.
Solução: Tipicamente, isto é devido à coleta de lixo e pode ser verificado ativando a GC detalhada (acessível no console administrativo) e consultando a duração dos ciclos da GC. A solução aqui é ativar a Coleta de Lixo de Geração, configurando args opcionais de JVM para -Xgcpolicy:gencon.
- Sintoma: Lotes de retransmissões, a CPU aumenta para 100% por longos períodos de tempo e a Coleta de Lixo de Geração é ativada.Solução: Tipicamente, isto é devido aos objetos de sessão SIP não estarem sendo invalidados ou não terem o tempo limite esgotado por um longo período de tempo. Uma solução é configurar o valor de tempo limite da sessão no sip.xml do aplicativo para um valor menor. A maneira mais eficiente de lidar com isso é fazer com que o aplicativo chame a invalidação na sessão quando o diálogo for concluído (por exemplo, após receber um BYE). A seguinte entrada no arquivo SystemOut.log indicará o valor de tempo limite de sessão para cada aplicativo instalado no contêiner:
SipXMLParser 3 SipXMLParser getAppSessionTTL Setting Expiration time: 7 Minutes, For App: TCK back-to-back user agent”
Nota: Esse tópico faz referência a um ou mais arquivos de log do servidor de aplicativos. Como uma recomendação alternativa, é possível configurar o servidor para usar a infraestrutura de log e rastreio do High Performance Extensible Logging (HPEL) em vez de usar os arquivos SystemOut.log , SystemErr.log, trace.log e activity.log em sistemas distribuídos e IBM® i. Também é possível usar HPEL em conjunção com os recursos de criação de log z/OS nativos. Se você estiver usando HPEL, será possível acessar todas as informações de log e rastreio usando a ferramenta de linha de comandos LogViewer a partir do diretório bin do perfil do servidor. Consulte as informações sobre a utilização do HPEL para resolução de problemas dos aplicativos para obter mais informações sobre o uso do HPEL. - Sintoma: Lotes de mensagens "480 Serviço Não Disponível" recebidas do contêiner ao enviar novas mensagens INVITE ao contêiner SIP.
Provavelmente, você também verá a mensagem a seguir aparecer no SystemOut.log quando o servidor estiver neste estado: "LoadManager E LoadManager warn.server.oveloaded".
Solução: Tipicamente, isto é devido a uma das métricas configuráveis do contêiner SIP estar sendo excedida. Isso inclui o valor "Máximo de Sessões de Aplicativo" e o valor "Máximo de Mensagens por Período Médio". A solução é ajustar esses valores mais alto.
- Sintoma: Lotes de reenvios e chamadas não estão sendo concluídos acompanhados pelas exceções OutOfMemory no SystemErr.log.
Solução: Isso geralmente significa que o tamanho de heap da VM associado ao seu contêiner não é grande o suficiente e deve ser ajustado para cima. Você pode ajustar esse valor a partir do console admin.
- Sintoma: Você receberá um "503 Serviço Indisponível" ao enviar uma solicitação SIP para um proxy SIP.
Solução: Isso geralmente significa que não há nenhum cluster padrão (ou regra de roteamento de cluster que corresponda à mensagem) configurado no proxy. Isso pode ocorrer também quando o proxy SIP estiver configurado corretamente, mas os contêineres SIP de backend estiverem parados ou travados.
- Sintoma: Você receberá um "404 Não Localizado" ao enviar uma solicitação SIP a um proxy SIP.
Solução: Isso geralmente significa que não há nenhum host virtual configurado para os contêineres que residem no cluster padrão. Isso também poderia significar que os servidores no cluster padrão do proxy não contêm um aplicativo SIP ou que a mensagem não corresponde a um dos aplicativos instalados no cluster padrão.
- Sintoma: Está ocorrendo um comportamento do tipo de "falta de memória".
Solução: Isso pode ser devido ao tamanho de heap máximo estar sendo configurado muito baixo. Os aplicativos SIP podem consumir uma significativa quantidade de memória porque existem sessões para um longo período de retenção de chamada. O tamanho máximo de heap de 512 MB não fornece memória suficiente para a carga de trabalho do tráfego SIP. Configure o tamanho de heap máximo para aplicativos SIP para o valor mínimo recomendado de 768 MB ou mais.
- Sintoma: Você receberá um "403 Proibido" ao enviar uma solicitação SIP para um contêiner SIP.
Solução: Isso geralmente significa que não há nenhum aplicativo SIP apropriado localizado para manipular a solicitação de SIP recebida (nenhuma regra de correspondência que correspondesse à mensagem).