Solucionar problemas de desempenho em contas de armazenamento do Azure

Artigo
04/10/2024

Este artigo ajuda você a investigar alterações inesperadas no comportamento (como tempos de resposta mais lentos do que o habitual). Essas alterações de comportamento geralmente podem ser identificadas monitorando as métricas de armazenamento no Azure Monitor. Para obter informações gerais sobre como usar métricas e logs no Azure Monitor, confira os seguintes artigos:

Monitoramento do desempenho

Para monitorar o desempenho dos serviços de armazenamento, você pode usar as seguintes métricas:

As métricas SuccessE2ELatency e SuccessServerLatency mostram o tempo médio que o serviço de armazenamento ou o tipo de operação de API está levando para processar solicitações. SuccessE2ELatency é uma medida de latência de ponta a ponta que inclui o tempo necessário para ler a solicitação e enviar a resposta, além do tempo necessário para processar a solicitação (portanto, ela inclui latência de rede quando a solicitação chega ao serviço de armazenamento). SuccessServerLatency é uma medida apenas do tempo de processamento e, portanto, exclui qualquer latência de rede relacionada à comunicação com o cliente.
As métricas saídae entrada mostram a quantidade total de dados, em bytes, entrando e saindo do serviço de armazenamento ou por meio de um tipo de operação de API específico.
A métrica Transações mostra o número total de solicitações que o serviço de armazenamento da operação de API está recebendo. Transações é o número total de solicitações que o serviço de armazenamento recebe.

Você pode monitorar alterações inesperadas em qualquer um desses valores. Essas alterações podem indicar um problema que requer uma investigação mais aprofundada.

No portal do Azure, você pode adicionar regras de alerta que o notificam quando qualquer uma das métricas de desempenho desse serviço estiver abaixo ou exceder um limite especificado.

Diagnosticar problemas de desempenho

O desempenho de um aplicativo pode ser subjetivo, especialmente do ponto de vista do usuário. Portanto, é importante ter métricas de linha de base disponíveis para ajudá-lo a identificar onde pode haver um problema de desempenho. Muitos fatores podem afetar o desempenho de um serviço de armazenamento do Azure na perspectiva do aplicativo cliente. Esses fatores podem operar no serviço de armazenamento, no cliente ou na infraestrutura de rede. Portanto, é importante ter uma estratégia para identificar a origem do problema de desempenho.

Depois de identificar o local provável da causa do problema de desempenho das métricas, você poderá usar os arquivos de log para encontrar informações detalhadas para diagnosticar e solucionar o problema ainda mais.

Métricas mostram alta SuccessE2ELatency e baixo SuccessServerLatency

Em alguns casos, você pode descobrir que SuccessE2ELatency é maior que o SuccessServerLatency. O serviço de armazenamento calcula apenas a métrica SuccessE2ELatency para solicitações bem-sucedidas e, ao contrário de SuccessServerLatency, inclui o tempo que o cliente leva para enviar os dados e receber reconhecimento do serviço de armazenamento. Portanto, uma diferença entre SuccessE2ELatency e SuccessServerLatency pode ser devido à lentidão da resposta do aplicativo cliente ou devido às condições na rede.

Observação

Você também pode exibir E2ELatency e ServerLatency para operações de armazenamento individuais nos dados de log de armazenamento.

Investigando problemas de desempenho do cliente

Os possíveis motivos para o cliente responder lentamente incluem ter conexões ou threads disponíveis limitados ou ter poucos recursos, como CPU, memória ou largura de banda de rede. Você pode ser capaz de resolve o problema modificando o código do cliente para ser mais eficiente (por exemplo, usando chamadas assíncronas para o serviço de armazenamento) ou usando uma Máquina Virtual maior com mais núcleos e mais memória.

Para os serviços de tabela e fila, o algoritmo Nagle também pode causar alta SuccessE2ELatency em comparação com SuccessServerLatency. Para obter mais informações, confira a postagem Algoritmo do Nagle não é amigável para pequenas solicitações. Você pode desabilitar o algoritmo Nagle no código usando a ServicePointManager classe no System.Net namespace. Você deve fazer isso antes de fazer chamadas para a tabela ou serviços de fila em seu aplicativo, pois isso não afeta as conexões que já estão abertas. O exemplo a seguir vem do Application_Start método em uma função de trabalho:

var connectionString = Constants.connectionString;
QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

Você deve marcar os logs do lado do cliente para ver quantas solicitações seu aplicativo cliente está enviando e marcar para gargalos gerais de desempenho relacionados ao .NET em seu cliente, como CPU, coleta de lixo .NET, utilização de rede ou memória. Como ponto de partida para solucionar problemas de aplicativos cliente .NET, consulte Depuração, Rastreamento e Criação de Perfil.

Investigando problemas de latência de rede

Normalmente, a latência de ponta a ponta causada pela rede é devido a condições transitórias. Você pode investigar problemas de rede transitórios e persistentes, como pacotes descartados, usando ferramentas como o Wireshark.

As métricas mostram baixa SuccessE2ELatency e baixa SuccessServerLatency, mas o cliente está experimentando alta latência

Nesse cenário, a causa mais provável é um atraso na solicitação de armazenamento que chega ao serviço de armazenamento. Você deve investigar por que as solicitações do cliente não estão passando para o serviço de blob.

Um possível motivo para o cliente atrasar o envio de solicitações é que há um número limitado de conexões ou threads disponíveis.

Além disso, marcar se o cliente está executando várias tentativas e investigue o motivo se ele estiver. Para determinar se o cliente está executando várias tentativas, você pode:

Examine os logs. Se várias tentativas estiverem acontecendo, você verá várias operações com as mesmas IDs de solicitação de cliente.
Examine os logs do cliente. O registro em log verboso indicará que ocorreu uma nova tentativa.
Depure seu código e marcar as propriedades do OperationContext objeto associado à solicitação. Se a operação tiver sido repetida, a RequestResults propriedade incluirá várias solicitações exclusivas. Você também pode marcar os horários de início e término de cada solicitação.

Se não houver problemas no cliente, você deverá investigar possíveis problemas de rede, como perda de pacotes. Você pode usar ferramentas como o Wireshark para investigar problemas de rede.

Métricas mostram alta SuccessServerLatency

No caso de alta SuccessServerLatency para solicitações de download de blob, você deve usar os logs de armazenamento para ver se há solicitações repetidas para o mesmo blob (ou conjunto de blobs). Para solicitações de carregamento de blob, você deve investigar qual tamanho de bloco o cliente está usando (por exemplo, blocos com menos de 64 K de tamanho podem resultar em sobrecargas, a menos que as leituras também estejam em partes inferiores a 64 K) e se vários clientes estiverem carregando blocos no mesmo blob em paralelo. Você também deve marcar as métricas por minuto para picos no número de solicitações que resultam em exceder as metas de escalabilidade por segundo.

Se você vir alta SuccessServerLatency para solicitações de download de blob quando houver solicitações repetidas para o mesmo blob ou conjunto de blobs, considere armazenar esses blobs usando o Cache do Azure ou a CDN (Rede de Distribuição de Conteúdo do Azure). Para solicitações de upload, você pode melhorar a taxa de transferência usando um tamanho de bloco maior. Para consultas em tabelas, também é possível implementar o cache do lado do cliente em clientes que executam as mesmas operações de consulta e em que os dados não são alterados com frequência.

Os valores de High SuccessServerLatency também podem ser um sintoma de tabelas ou consultas mal projetadas que resultam em operações de verificação ou que seguem o anti-padrão de apêndice/prepend.

Observação

Você pode encontrar uma lista de verificação de desempenho abrangente na lista de verificação de desempenho e escalabilidade Armazenamento do Microsoft Azure.

Você está enfrentando atrasos inesperados na entrega de mensagens em uma fila

Se você estiver enfrentando um atraso entre o tempo em que um aplicativo adiciona uma mensagem a uma fila e a hora em que ele fica disponível para ler na fila, siga as seguintes etapas para diagnosticar o problema:

Verifique se o aplicativo está adicionando as mensagens com êxito à fila. Verifique se o aplicativo não está repetindo o AddMessage método várias vezes antes de ter êxito.
Verifique se não há distorção de relógio entre a função de trabalho que adiciona a mensagem à fila e à função de trabalho que lê a mensagem da fila. Uma distorção de relógio faz com que pareça que há um atraso no processamento.
Verifique se a função de trabalho que lê as mensagens da fila está falhando. Se um cliente de fila chamar o GetMessage método, mas não responder com um reconhecimento, a mensagem permanecerá invisível na fila até que o invisibilityTimeout período expire. Neste ponto, a mensagem fica disponível para processamento novamente.
Verifique se o comprimento da fila está crescendo ao longo do tempo. Isso pode ocorrer se você não tiver trabalhadores suficientes disponíveis para processar todas as mensagens que outros trabalhadores estão colocando na fila. Além disso, marcar as métricas para ver se as solicitações de exclusão estão falhando e a contagem de dequeue em mensagens, o que pode indicar tentativas repetidas de falha para excluir a mensagem.
Examine os logs de armazenamento para quaisquer operações de fila que tenham valores E2ELatency e ServerLatency acima do esperado em um período maior do que o normal.

Confira também

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.