Problemas de rede – ASYNC_NETWORK_IO

Há um tempo atrás, fiz uma analise em conjunto com um amigo, Rafael Carneiro Machado, de problemas com lentidão em um site. O Rafael trabalha comigo, porém no time de Web e ajudou a identificar o problema que estávamos tendo, assim como a escrever o texto abaixo.

Objetivo

Diagnosticar e identificar as possíveis causas de lentidão em um site que estavam ocorrendo. O diagnóstico iniciou-se de forma geral nos ambientes de Web e Banco de Dados e os contadores de performance foram sendo refinados de acordo com as evidências encontradas.

Depois da análise realizada, foram identificadas evidências de um problema na rede que interliga os ambientes de Web e Banco de Dados. Dessa maneira nossos esforços foram direcionados para tanto.

Incidente Reportado: Lentidão e timeout em alguns momentos do acesso ao site

Análise Inicial – Banco de Dados:

Foi realizada uma analise em cima da instância de banco de dados, que hospedava o site e foi identificado um alto tempo de espera do tipo ASYNC_NETWORK_IO, quase 15%.
Porque esse valor é alto? Em particular, nunca tinha visto esse tipo de espera com um valor alto e isto me chamou a atenção, pois sempre vi um valor próximo a 0% ou no máximo a 2%. Aqui foi o ponto que levou a nossa investigação a se concentrar que poderia existir um problema relacionado à rede, mas o que era exatamente nesse momento ainda não sabíamos.

01-async_network_io

Figura 1

Esse tipo de espera indica que o SQL Server está respondendo para a aplicação, porém a mesma não está conseguindo processar no tempo correto.

02-technet-waittypes

Figura 2

Algumas ações que podemos tomar para tentar identificar a causa raiz do problema:

  • Identificar results sets grandes e verificar com a equipe de sistema se isso realmente está de acordo com o negócio.
  • Se nem todas as linhas do result set serão necessárias, devemos alterar o código para restringir essa quantidade de linhas.
  • Devemos verificar as configurações de placa de rede e verificar se não existe nenhum problema.
  • Validar os componentes de rede entre a aplicação/cliente e a instancia do SQL Server

Análise Inicial – WEB:

Não foi identificado nenhum time-out no ambiente Web, o que tinhamos era a demora do Banco de Dados em responder as requisições dos servidores de aplicação. Isso pode ser identificado pela quantidade de conexões com o estado “SYN_SENT”, porém esta informação apenas indica que a primeira ação do Three-Way-Handshake foi iniciada, onde a origem informou ao destino que deseja iniciar uma comunicação. Normalmente não vemos este estado de conexão, pois as comunicações de SYN, SYN-ACK e ACK ocorrem quase de forma instantânea exceto em casos como este, onde o servidor de destino demora a enviar a resposta do SYN à origem, porém não existia registro de time-out. Monitoramos os pacotes entre os servidores de aplicação e banco de dados e pudemos ver que o servidor de banco de dados estava demorando para enviar a resposta, mas respondia a requisição dos servidores de aplicação:

03-web01

Figura 3

Nesse momento, suspeitávamos que o problema pudesse estar ocorrendo por falta de portas TCP para realizar a comunicação devido a um alto trafego de dados. Foi realizado um monitoramento e a média de conexões TCP em portas distintas em cada servidor era de 800, independente do destino. Se levarmos em conta que por padrão a quantidade de portas dinâmicas no Windows 2008 é de 16384 portas (49152 a 65535), ainda sobram mais de 15 mil portas livres:

04-netstat01

Figura 4

05-netstat02

Figura 5

O que poderia estar acontecendo era uma limitação nas portas dinâmicas dos servidores de banco. Essa nossa suspeita não se confirmou, pois dificilmente o problema estava na falta de “portas altas” nos servidores de aplicação.

Outro detalhe importante que não poderíamos deixar de lado, era que o tráfego entre Web e Banco de Dados passava por um appliance de balanceamento, um intrusion prevention system (IPS), Firewall e outros equipamentos de rede física.

Análise detalhada

Após análise inicial, foi constatada a possibilidade de um problema de rede, a partir desse ponto uma nova investigação foi realizada com foco neste quesito utilizando as ferramentas de análise de performance do próprio sistema operacional, o Perfmon.

Os contadores utilizados foram:

Network Interface
  • % Network Utilization
  • Output Queue Length
  • % Network Utilization Sent
  • % Network Utilization Received
  • Packets Outbound Errors
  • Bytes Total/sec
  • Current Bandwidth
  • Packets/secPackets Sent/sec
  • Packets Received/sec
  • Packets Received Unknown
  • Packets Received Discarded
  • Packets Outbound Discarded
  • Packets Sent Unicast/sec
Processor
  • % DPC Time
  • DPCs Queued/sec
TCPv4
  • Connection Failures
  • Segments/sec
  • Connections Established
  • Connections Reset
  • Segments Received/sec
  • Connections Passive
  • Connections Active
  • Segments Retransmitted/sec
  • Segments Sent/sec

AMBIENTE DE BANCO DE DADOS

06-PerfmonDB 

Figura 6

Os itens que mais se destacaram foram a quantidade de pacotes recebidos descartados e com erro, além disso, o número de segmentos TCP retransmitidos e de conexões com falha também estão altos.

 07-PerfmonDB Simplificado

Figura 7

08-GraficoErrosTCP

Figura 8

A figura 8 mostra os segmentos TCP que precisaram ser retransmitidos por algum erro de rede.

Outro ponto de destaque é a quantidade de conexões TCP com falha. O fabricante recomenda que este contador não ultrapasse o número de 10 conexões TCP com falha por hora. No ambiente de banco de dados este valor está com uma média de 20. Os figuras 9 e 10 mostram esse comportamento.

  09-errosTCP

Figura 9

10-errosTCP-PAL

Figura 10

AMBIENTE WEB

11-PerfmonDB WEB

Figura 11

No ambiente Web não tínhamos qualquer indício na camada física de erros, porém o mesmo problema identificado no ambiente de Banco de Dados ocorre no ambiente Web. Esse problema trata-se da camada de transporte, várias conexões com falha e retransmitidas.

 12-PerfmonDB Simplificado -WEB

Figura 12

O padrão de segmentos retransmitidos se repete no ambiente Web, consequência das conexões TCP com falhas.

13-GraficoErrosTCP-WEB

Figura 13

Esse comportamento no ambiente web foi detectado em todos os servidores da farm.

Resolução

Esse comportamento foi enviado para equipe de rede, que realizou as ações necessárias na camada física dos equipamentos fazendo assim com que o trafego de pacotes ocorresse com sucesso. O site em questão apresentou uma melhora significante, onde seu carregamento inicial passou de 14 segundos para apenas 2,8 segundos.

Conclusão

Por algum motivo relacionado a rede, o Banco de Dados estava com muitos pacotes com erros e descartados e  isso gerava a necessidade de retransmissão dos mesmos, ocasionando demora na entrega das informações que a aplicação demandava. O resultado final era a lentidão no acesso e carregamento do site.
Foi constatado que até mesmo para iniciar a comunicação entre Web e Banco de Dados o problema ocorria.

O servidor Web enviava o pacote de SYN, o qual o servidor de banoo de dados recebia o pacote e enviava o ACK. Este pacote de ACK estava sendo corrompido em algum ponto e a aplicação informava ao banco de dados que ainda não havia recebido sua confirmação (ACK), fazendo com que o Banco de Dados tentasse enviá-lo novamente.

Este período entre tentativas e falhas até que o ACK seja enviado corretamente e a comunicação estabelecida, é um exemplo de como a retransmissão de pacotes TCP pode impactar na performance do site. Essa retransmissão não ocorre apenas durante o processo de “Three Way Handshake”, mas também quando a comunicação já está estabelecida e efetivamente os dados estão sendo enviados do banco de dados para os servidores de aplicação.

Em uma empresa onde as áreas de infraestrutura são segmentadas, nem sempre temos acesso total a todas as áreas. Nesse caso, eu gostaria de mostrar que é importante uma analise iniciada e detalhada partindo dos times de banco de dados e web, para demonstrar que o problema pode estar em outra camada (outra equipe responsável). Devemos ter o embasamento necessário para comprovar esse fato e o importante não é achar o “culpado”, mas sim resolver o problema de forma conjunta.

Referências:

http://msdn.microsoft.com/pt-br/library/ms179984.aspx

http://en.wikipedia.org/wiki/Handshaking

http://support.microsoft.com/kb/929851/en-us

http://msdn.microsoft.com/pt-br/library/ms179984.aspx

Maníaco, entusiasta, fascinado, fanático por SQL Server e nas horas vagas um DBA que adora o que faz! Também possui certificações como: MCT, MCSE - Data Management and Analystics, MCSA - SQL Server 2014/2012

4 Responses to “Problemas de rede – ASYNC_NETWORK_IO”

  1. MAURO MOÑIZ, Responder

    TIAGO, PARABÉNS PELO POST.
    ESTOU ENFRENTANDO UM PROBLEMA SEMELHANTE E SUAS DICAS ESTÃO ME AJUDANDO MUITO.
    aBRAÇOS

  2. Wolney Marconi Maia, Responder

    Ola Tiago,
    Muito bom o post.

    Vc pode informar qual foi a instrução que vc executou para obter o resultado da figura 1.

    Grato,

Responda