Solucionar problemas de desempenho em contas de armazenamento do Azure

Artigo
11/20/2024

Este artigo ajuda você a investigar mudanças inesperadas no comportamento (como tempos de resposta mais lentos do que o normal). 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, consulte os seguintes artigos:

Monitoramento de 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 do serviço de armazenamento ou do tipo da operação API que está usando para processar as 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, inclui a 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 Egress e lngress mostram um valor total de dados, em bytes, entrando e saindo do seu serviço de armazenamento ou por um tipo de operação API específica.
A métrica Transactions mostra o número total de solicitações que o serviço de armazenamento da operação 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 notificam quando qualquer uma das métricas de desempenho desse serviço fica abaixo ou excede um limite especificado.

Diagnosticar problemas de desempenho

O desempenho de um aplicativo pode ser subjetivo, especialmente da perspectiva de um usuário. Por isso, é 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 da perspectiva do aplicativo do cliente. Esses fatores podem operar no serviço de armazenamento, no cliente ou na infra-estrutura de rede. Portanto, é importante ter uma estratégia para identificar a origem do problema de desempenho.

Após ter identificado o possível local da causa do problema de desempenho a partir das métricas, você pode usar os arquivos de log para encontrar as informações detalhadas para diagnosticar e solucionar o problema mais profundamente.

As métricas mostram alta SuccessE2ELatency e baixa SuccessServerLatency

Em alguns casos, você pode achar que SuccessE2ELatency é maior que o SuccessServerLatency. O serviço de armazenamento calcula apenas a métrica SuccessE2ELatency para solicitações de êxito e, ao contrário de SuccessServerLatency, inclui o tempo que o cliente leva para enviar os dados e receber a confirmação do serviço de armazenamento. Portanto, uma diferença entre SuccessE2ELatency e SuccessServerLatency pode ser devido ao aplicativo cliente ser lento para responder ou devido a condições na rede.

Observação

Você também pode exibir E2ELatency e ServerLatency das operações de armazenamento individual nos dados de registro do log de Armazenamento.

Investigação dos problemas de desempenho do cliente

Os possíveis motivos para o cliente responder lentamente incluem ter conexões ou threads disponíveis limitados ou estar com poucos recursos, como CPU, memória ou largura de banda de rede. Você pode resolver 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 alto SuccessE2ELatency em comparação com SuccessServerLatency. Para obter mais informações, consulte o post O algoritmo de Nagle não é amigável para pequenas solicitações. Você pode desabilitar o algoritmo Nagle no código usando a ServicePointManager System.Net classe no namespace. Faça isso antes de fazer qualquer chamada para os serviços de tabela ou fila no seu aplicativo já que 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 verificar os logs do lado do cliente para ver quantas solicitações seu aplicativo cliente está enviando e verificar se há gargalos gerais de desempenho relacionados ao .NET em seu cliente, como CPU, coleta de lixo do .NET, utilização de rede ou memória. Como ponto de partida para solucionar problemas de aplicativos do cliente .NET, confira Depuração, rastreamento e criação de perfil.

Investigando os problemas de latência de rede

Normalmente a alta 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á recebendo uma latência alta

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

Uma das possíveis razões para o atraso do cliente em enviar solicitações é que há um número limitado de conexões ou threads disponíveis.

Além disso, verifique se o cliente está executando várias tentativas e investigue o motivo, se estiver. Para determinar se o cliente está realizando várias tentativas, é possível:

Revisar logs. Se várias tentativas estiverem ocorrendo, você verá várias operações com as mesmas IDs de solicitação do cliente.
Examine os logs do cliente. O log detalhado indica que ocorreu uma repetição.
Depure seu código e verifique 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 verificar as horas de início e término de cada solicitação.

Se não houver problemas no cliente, investigue os possíveis problemas de rede, tais como perda de pacote. Você pode usar ferramentas como o Wireshark para investigar problemas de rede.

As métricas mostram alta SuccessServerLatency

No caso de alta SuccessServerLatency para as 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 para grupos de blobs). Para solicitações de upload 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 estão carregando blocos para o mesmo blob em paralelo. Você também deve verificar 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 em cache usando o Cache do Azure ou a CDN (Rede de Distribuição de Conteúdo) do Azure. Para solicitações de carregamento, você pode aprimorar a produtividade usando um tamanho maior de bloco. Para consultas às tabelas, também é possível implementar o cache no lado do cliente nos clientes que realizam as mesmas operações de consulta e nos casos em que os dados não mudam com frequência.

Valores altos de 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 antipadrão de acrescentar/prefixar.

Observação

Você pode encontrar uma lista de verificação de desempenho abrangente em Lista de verificação de desempenho e escalabilidade do armazenamento do Microsoft Azure.

Você está sofrendo atrasos inesperados na entrega de mensagens na fila

Se você estiver enfrentando um atraso entre o momento em que um aplicativo adiciona uma mensagem a uma fila e o momento em que ela fica disponível para leitura da fila, execute as seguintes etapas para diagnosticar o problema:

Verifique se o aplicativo está adicionando com êxito as mensagens à fila. Verifique se o aplicativo não está repetindo o AddMessage método várias vezes antes de ter sucesso.
Verifique se não há distorção de relógio entre a função de trabalho que adiciona a mensagem à fila e a função de trabalho que lê a mensagem da fila. Uma inclinação do relógio faz parecer que há um atraso no processamento.
A função de trabalho lê as mensagens da fila que tem falhas. Se um cliente de fila chamar o GetMessage método, mas não responder com uma confirmação, a mensagem permanecerá invisível na fila até que o invisibilityTimeout período expire. Nesse momento, a mensagem se torna disponibilidade para ser processada novamente.
Verifique se o tamanho da fila está aumentando com o 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, verifique as métricas para ver se as solicitações de exclusão estão falhando e a contagem de remoção da fila nas mensagens, o que pode indicar tentativas repetidas com falha de excluir a mensagem.
Examine os logs de armazenamento para qualquer operação de fila que possa estar mais alta do que a E2ELatency esperada e valores ServerLatency durante um período mais longo de tempo do que de costume.

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.

Partilhar via