Solucionar problemas de desempenho Arquivos do Azure

  • Artigo

Observação

O CentOS referenciado neste artigo é uma distribuição do Linux e chegará ao EOL (End Of Life). Considere seu uso e planeje de acordo. Para obter mais informações, confira Diretrizes de Fim de Vida do CentOS.

Este artigo lista problemas comuns relacionados ao desempenho do compartilhamento de arquivos do Azure e fornece possíveis causas e soluções alternativas. Para obter o maior valor deste guia de solução de problemas, recomendamos primeiro ler Entender Arquivos do Azure desempenho.

Aplicável a

Tipo de compartilhamento de arquivo SMB NFS
Compartilhamentos de arquivo padrão (GPv2), LRS/ZRS
Compartilhamentos de arquivo padrão (GPv2), GRS/GZRS
Compartilhamentos de arquivo Premium (FileStorage), LRS/ZRS

Solução de problemas de desempenho geral

Primeiro, desmente alguns motivos comuns pelos quais você pode estar tendo problemas de desempenho.

Você está executando um sistema operacional antigo

Se a VM (máquina virtual do cliente) estiver executando Windows 8.1 ou Windows Server 2012 R2 ou uma distro ou kernel do Linux mais antigo, você poderá ter problemas de desempenho ao acessar compartilhamentos de arquivos do Azure. Atualize o sistema operacional cliente ou aplique as correções abaixo.

Considerações sobre Windows 8.1 e Windows Server 2012 R2

Os clientes que estão executando Windows 8.1 ou Windows Server 2012 R2 podem ver latência maior do que o esperado ao acessar compartilhamentos de arquivos do Azure para cargas de trabalho intensivas em E/S. Verifique se o hotfix KB3114025 está instalado. Esse hotfix melhora o desempenho de identificadores de criação e fechamento.

Você pode executar o seguinte script para marcar se o hotfix foi instalado:

reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies

Se o hotfix estiver instalado, a seguinte saída será exibida:

HKEY_Local_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies {96c345ef-3cac-477b-8fcd-bea1a564241c} REG_DWORD 0x1

Observação

Windows Server 2012 imagens R2 no Azure Marketplace têm o hotfix KB3114025 instalado por padrão, a partir de dezembro de 2015.

Sua carga de trabalho está sendo limitada

As solicitações são limitadas quando as operações de E/S por segundo (IOPS), entrada ou limites de saída para um compartilhamento de arquivos são atingidas. Por exemplo, se o cliente exceder o IOPS de linha de base, ele será limitado pelo serviço Arquivos do Azure. A limitação pode fazer com que o cliente esteja com um desempenho ruim.

Para entender os limites para compartilhamentos de arquivos padrão e premium, consulte Compartilhamento de arquivos e destinos de escala de arquivos. Dependendo da carga de trabalho, a limitação geralmente pode ser evitada passando de compartilhamentos de arquivos padrão para premium do Azure.

Para saber mais sobre como a limitação no nível de compartilhamento ou no nível da conta de armazenamento pode causar alta latência, baixa taxa de transferência e problemas gerais de desempenho, consulte Compartilhar ou conta de armazenamento está sendo limitada.

Alta latência, baixa taxa de transferência ou baixo IOPS

Causa 1: a conta de armazenamento ou de compartilhamento está sendo limitada

Para confirmar se sua conta de compartilhamento ou armazenamento está sendo limitada, você pode acessar e usar as métricas do Azure no portal. Você também pode criar alertas que o notificarão se um compartilhamento estiver sendo limitado ou estiver prestes a ser limitado. Consulte Solucionar problemas Arquivos do Azure criando alertas.

Importante

Para contas de armazenamento padrão com grandes compartilhamentos de arquivos (LFS) habilitados, a limitação ocorre no nível da conta. Para compartilhamentos de arquivos premium e compartilhamentos de arquivos padrão sem LFS habilitado, a limitação ocorre no nível de compartilhamento.

  1. No portal do Azure, vá para sua conta de armazenamento.

  2. No painel esquerdo, em Monitoramento, selecione Métricas.

  3. Selecione Arquivo como o namespace de métrica para o escopo da conta de armazenamento.

  4. Selecione Transações como a métrica.

  5. Adicione um filtro para tipo de resposta e, em seguida, marcar para ver se alguma solicitação foi limitada.

    Para compartilhamentos de arquivos padrão que não têm grandes compartilhamentos de arquivos habilitados, os seguintes tipos de resposta serão registrados se uma solicitação for limitada no nível de compartilhamento:

    • SuccessWithThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareIopsThrottlingError

    Para compartilhamentos de arquivos padrão que têm grandes compartilhamentos de arquivos habilitados, os seguintes tipos de resposta serão registrados se uma solicitação for limitada no nível da conta do cliente:

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    Para compartilhamentos de arquivos premium, os seguintes tipos de resposta serão registrados se uma solicitação for limitada no nível de compartilhamento:

    • SuccessWithShareEgressThrottling
    • SuccessWithShareIngressThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareEgressThrottlingError
    • ClientShareIngressThrottlingError
    • ClientShareIopsThrottlingError

    Se uma solicitação limitada foi autenticada com Kerberos, você poderá ver um prefixo indicando o protocolo de autenticação, como:

    • KerberosSuccessWithShareEgressThrottling
    • KerberosSuccessWithShareIngressThrottling

    Para saber mais sobre cada tipo de resposta, consulte Dimensões de métrica.

    Captura de tela que mostra o filtro de propriedade 'Tipo de resposta'.

Solução

Causa 2: Metadados ou carga de trabalho pesada do namespace

Se a maioria das suas solicitações for centrada em metadados (como createfile, openfile, closefile, queryinfoou querydirectory), a latência será pior do que a das operações de leitura/gravação.

Para determinar se a maioria das solicitações são centradas em metadados, comece seguindo as etapas 1-4, conforme descrito anteriormente na Causa 1. Para a etapa 5, em vez de adicionar um filtro para o tipo Response, adicione um filtro de propriedade para o nome da API.

Captura de tela que mostra o filtro de propriedade 'Nome da API'.

Soluções alternativas

  • Verifique se o aplicativo pode ser modificado para reduzir o número de operações de metadados.

  • Separe o compartilhamento de arquivos em vários compartilhamentos de arquivos na mesma conta de armazenamento.

  • Adicione um VHD (disco rígido virtual) no compartilhamento de arquivos e monte o VHD do cliente para executar operações de arquivo em relação aos dados. Essa abordagem funciona para cenários ou cenários de escritor/leitor único com vários leitores e sem escritores. Como o sistema de arquivos pertence ao cliente em vez de Arquivos do Azure, isso permite que as operações de metadados sejam locais. A configuração oferece desempenho semelhante ao do armazenamento conectado diretamente local. No entanto, como os dados estão em um VHD, eles não podem ser acessados por meio de outros meios que não sejam a montagem do SMB, como a API REST ou por meio do portal do Azure.

    1. No computador que precisa acessar o compartilhamento de arquivos do Azure, monte o compartilhamento de arquivos usando a chave da conta de armazenamento e mapeie-o para uma unidade de rede disponível (por exemplo, Z:).
    2. Acesse Gerenciamento de Disco e selecione Criar VHD de Ação>.
    3. Defina Local como a unidade de rede à qual o compartilhamento de arquivos do Azure é mapeado, defina o tamanho do disco rígido virtual conforme necessário e selecione Tamanho fixo.
    4. Selecione OK. Depois que a criação do VHD for concluída, ela será montada automaticamente e um novo disco não alocado será exibido.
    5. Clique com o botão direito do mouse no novo disco desconhecido e selecione Inicializar Disco.
    6. Clique com o botão direito do mouse na área não alocada e crie um novo volume simples.
    7. Você deve ver uma nova letra de unidade aparecer no Gerenciamento de Disco representando esse VHD com acesso de leitura/gravação (por exemplo, E:). Em Explorador de Arquivos, você deve ver o novo VHD na unidade de rede do compartilhamento de arquivos do Azure mapeada (Z: neste exemplo). Para ficar claro, deve haver duas letras de unidade presentes: o mapeamento padrão de rede de compartilhamento de arquivos do Azure em Z:e o mapeamento VHD na unidade E: .
    8. Deve haver um desempenho muito melhor em operações de metadados pesados em relação aos arquivos na unidade mapeada VHD (E:) versus a unidade mapeada de compartilhamento de arquivos do Azure (Z:). Se desejado, deve ser possível desconectar a unidade de rede mapeada (Z:) e ainda acessar a unidade VHD montada (E:).
    • Para montar um VHD em um cliente Windows, você também pode usar o cmdlet do Mount-DiskImage PowerShell.
    • Para montar um VHD no Linux, consulte a documentação da distribuição do Linux. Aqui está um exemplo.

Causa 3: aplicativo com thread único

Se o aplicativo que você está usando for de thread único, essa configuração poderá resultar em uma taxa de transferência IOPS significativamente menor do que a taxa de transferência máxima possível, dependendo do tamanho do compartilhamento provisionado.

Solução

  • Aumente o paralelismo do aplicativo aumentando o número de threads.
  • Alterne para aplicativos em que o paralelismo é possível. Por exemplo, para operações de cópia, você pode usar o AzCopy ou o RoboCopy de clientes Windows ou o comando paralelo de clientes Linux.

Causa 4: Número de canais SMB excede quatro

Se você estiver usando o SMB MultiChannel e o número de canais que você excedeu quatro, isso resultará em um desempenho ruim. Para determinar se a contagem de conexões excede quatro, use o cmdlet get-SmbClientConfiguration do PowerShell para exibir as configurações atuais de contagem de conexões.

Solução

Defina a configuração windows por NIC para SMB para que o total de canais não exceda quatro. Por exemplo, se você tiver dois NICs, poderá definir o máximo por NIC como dois usando o seguinte cmdlet do PowerShell: Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

Causa 5: O tamanho de leitura antecipada é muito pequeno (somente NFS)

Começando com o kernel do Linux versão 5.4, o cliente NFS do Linux usa um valor padrão read_ahead_kb de 128 kibibytes (KiB). Esse pequeno valor pode reduzir a quantidade de taxa de transferência de leitura para arquivos grandes.

Solução

Recomendamos que você aumente o valor do read_ahead_kb parâmetro kernel para 15 mebibytes (MiB). Para alterar esse valor, defina o tamanho de leitura à frente persistentemente adicionando uma regra no udev, um gerenciador de dispositivos kernel do Linux. Siga estas etapas:

  1. Em um editor de texto, crie o arquivo /etc/udev/rules.d/99-nfs.rules inserindo e salvando o seguinte texto:

    SUBSYSTEM=="bdi" \
, ACTION=="add" \
, PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
, ATTR{read_ahead_kb}="15360"

  2. Em um console, aplique a regra udev executando o comando udevadm como um superusuário e recarregando os arquivos de regras e outros bancos de dados. Para conscientizar o udev sobre o novo arquivo, você só precisa executar esse comando uma vez.

    sudo udevadm control --reload

Latência muito alta para solicitações

Motivo

A VM do cliente pode estar localizada em uma região diferente do compartilhamento de arquivos. Outro motivo para alta latência pode ser devido à latência causada pelo cliente ou pela rede.

Solução

  • Execute o aplicativo de uma VM localizada na mesma região que o compartilhamento de arquivos.
  • Para sua conta de armazenamento, examine as métricas de transação SuccessE2ELatency e SuccessServerLatency por meio do Azure Monitor em portal do Azure. Uma grande diferença entre os valores de métricas SuccessE2ELatency e SuccessServerLatency é uma indicação de latência que provavelmente é causada pela rede ou pelo cliente. Consulte Métricas de transação na referência de dados de monitoramento de Arquivos do Azure.

Cliente não pode obter a taxa de transferência máxima com suporte pela rede

Motivo

Uma causa potencial é a falta de suporte multicanal SMB para compartilhamentos de arquivos padrão. Atualmente, Arquivos do Azure dá suporte apenas a um único canal para compartilhamentos de arquivos padrão, portanto, há apenas uma conexão da VM do cliente com o servidor. Essa conexão única é atrelada a um único núcleo na VM do cliente, portanto, a taxa de transferência máxima alcançável de uma VM é vinculada por um único núcleo.

Solução alternativa

Desempenho lento em um compartilhamento de arquivos do Azure montado em uma VM do Linux

Causa 1: Cache

Uma possível causa de desempenho lento é o cache desabilitado. O cache pode ser útil se você estiver acessando um arquivo repetidamente. Caso contrário, pode ser uma sobrecarga. Verifique se você está usando o cache antes de desativá-lo.

Solução para a causa 1

Para marcar se o cache está desabilitado, procure a cache= entrada.

Cache=none indica que o cache está desabilitado. Remonte o compartilhamento usando o comando de montagem padrão ou adicionando explicitamente a opção cache=strict ao comando de montagem para garantir que o cache padrão ou o modo de cache "rigoroso" esteja habilitado.

Em alguns cenários, a opção serverino de montagem pode fazer com que o ls comando seja executado stat em cada entrada de diretório. Esse comportamento resulta em degradação de desempenho quando você está listando um diretório grande. Você pode marcar as opções de montagem em sua entrada /etc/fstab:

//azureuser.file.core.windows.net/cifs /cifs cifs vers=2.1,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777

Você também pode marcar se as opções corretas estão sendo usadas executando o sudo mount | grep cifs comando e verificando sua saída. A seguir está uma saída de exemplo:

//azureuser.file.core.windows.net/cifs on /cifs type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=xxx,domain=X,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.10.1,file_mode=0777, dir_mode=0777,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,actimeo=1)

Se a opção cache=strict ou serverino não estiver presente, desmonte e monte Arquivos do Azure novamente executando o comando de montagem da documentação. Em seguida, verifique novamente se a entrada /etc/fstab tem as opções corretas.

Causa 2: Limitação

É possível que você esteja enfrentando limitação e suas solicitações estejam sendo enviadas para uma fila. Você pode verificar isso aproveitando as métricas de Armazenamento do Azure no Azure Monitor. Você também pode criar alertas que notifiquem você se um compartilhamento estiver sendo limitado ou estiver prestes a ser limitado. Consulte Solucionar problemas Arquivos do Azure criando alertas.

Solução para a causa 2

Verifique se seu aplicativo está dentro dos destinos de escala Arquivos do Azure. Se você estiver usando compartilhamentos de arquivos padrão do Azure, considere mudar para premium.

A taxa de transferência em clientes Linux é menor que a dos clientes Windows

Motivo

Esse é um problema conhecido com a implementação do cliente SMB no Linux.

Solução alternativa

  • Espalhe a carga em várias VMs.
  • Na mesma VM, use vários pontos de montagem com uma nosharesock opção e espalhe a carga por esses pontos de montagem.
  • No Linux, tente montar com uma nostrictsync opção para evitar forçar uma liberação de SMB em cada fsync chamada. Para Arquivos do Azure, essa opção não interfere na consistência de dados, mas pode resultar em metadados de arquivo obsoletos em listagens de diretório (ls -lcomando). Consultar diretamente os metadados de arquivo usando o stat comando retornará os metadados de arquivo mais atualizados.

Altas latências para cargas de trabalho pesadas de metadados envolvendo operações extensas de abertura/fechamento

Motivo

Falta de suporte para concessões de diretório.

Solução alternativa

  • Se possível, evite usar um identificador de abertura/fechamento excessivo no mesmo diretório em um curto período de tempo.
  • Para VMs linux, aumente o tempo limite de cache de entrada do diretório especificando actimeo=<sec> como uma opção de montagem. Por padrão, o tempo limite é de 1 segundo, portanto, um valor maior, como 30 segundos, pode ajudar.
  • Para VMs Linux do CentOS ou Red Hat Enterprise Linux (RHEL), atualize o sistema para o CentOS Linux 8.2 ou RHEL 8.2. Para outras distribuições do Linux, atualize o kernel para 5.0 ou posterior.

Enumeração lenta de arquivos e pastas

Motivo

Esse problema pode ocorrer se não houver cache suficiente no computador cliente para diretórios grandes.

Solução

Para resolve esse problema, ajuste o valor do DirectoryCacheEntrySizeMax registro para permitir o cache de listagens de diretórios maiores no computador cliente:

  • Localização: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
  • Nome do valor: DirectoryCacheEntrySizeMax
  • Tipo de valor: DWORD

Por exemplo, você pode defini-lo como 0x100000 e ver se o desempenho melhora.

Copiar arquivos lentos de e para compartilhamentos de arquivos do Azure

Você pode ver um desempenho lento ao tentar transferir arquivos para o serviço Arquivos do Azure. Se você não tiver um requisito de tamanho mínimo de E/S específico, recomendamos que você use 1 MiB como o tamanho de E/S para um desempenho ideal.

Copiar arquivos lentos de e para Arquivos do Azure no Windows

  • Se você sabe o tamanho final de um arquivo que está estendendo com gravações e seu software não tem problemas de compatibilidade quando a cauda não escrita no arquivo contém zeros, defina o tamanho do arquivo com antecedência em vez de fazer de cada gravação uma gravação estendida.

  • Use o método de cópia correto:

    • Use o AzCopy para qualquer transferência entre dois compartilhamentos de arquivo.
    • Use o Robocopy entre compartilhamentos de arquivos em um computador local.

Chamadas excessivas do DirectoryOpen/DirectoryClose

Motivo

Se o número de chamadas do DirectoryOpen/DirectoryClose estiver entre as principais chamadas de API e você não esperar que o cliente faça tantas chamadas, o problema poderá ser causado pelo software antivírus instalado na VM do cliente do Azure.

Solução alternativa

Uma correção para esse problema está disponível na Atualização da Plataforma de Abril para Windows.

O SMB Multichannel não está sendo disparado

Motivo

Alterações recentes nas configurações de configuração multicanal do SMB sem uma remontagem.

Solução

  • Depois de qualquer alteração nas configurações de configuração multicanal do cliente SMB ou da conta do Windows, você precisa desmontar o compartilhamento, aguardar 60 segundos e remontar o compartilhamento para disparar o multicanal.
  • Para o sistema operacional cliente Windows, gere carga de E/S com alta profundidade de fila, por exemplo, copiando um arquivo para disparar o SMB Multichannel. Para o sistema operacional do servidor, o SMB Multichannel é disparado com QD=1, o que significa que assim que você inicia qualquer E/S no compartilhamento.

Desempenho lento ao descompactar arquivos

Dependendo do método de compactação exato e da operação de descompactação usada, as operações de descompressão podem ser executadas mais lentamente em um compartilhamento de arquivos do Azure do que em seu disco local. Isso ocorre geralmente porque as ferramentas de descompactação executam várias operações de metadados no processo de execução da descompressão de um arquivo compactado. Para obter o melhor desempenho, recomendamos copiar o arquivo compactado do compartilhamento de arquivos do Azure para o disco local, descompactar lá e, em seguida, usar uma ferramenta de cópia, como Robocopy (ou AzCopy) para copiar de volta para o compartilhamento de arquivos do Azure. O uso de uma ferramenta de cópia como o Robocopy pode compensar o desempenho reduzido das operações de metadados em Arquivos do Azure em relação ao disco local usando vários threads para copiar dados em paralelo.

Alta latência em sites hospedados em compartilhamentos de arquivos

Motivo

A notificação de alteração de arquivo em número alto em compartilhamentos de arquivos pode resultar em altas latências. Normalmente, isso ocorre com sites hospedados em compartilhamentos de arquivos com estrutura de diretório aninhada profunda. Um cenário típico é o aplicativo Web hospedado pelo IIS, em que a notificação de alteração de arquivo é configurada para cada diretório na configuração padrão. Cada alteração (ReadDirectoryChangesW) no compartilhamento em que o cliente está registrado envia por push uma notificação de alteração do serviço de arquivo para o cliente, que leva recursos do sistema e o problema piora com o número de alterações. Isso pode causar limitação de compartilhamento e, portanto, resultar em maior latência do lado do cliente.

Para confirmar, você pode usar o Azure Metrics no portal.

  1. No portal do Azure, vá para sua conta de armazenamento.
  2. No menu à esquerda, em Monitoramento, selecione Métricas.
  3. Selecione Arquivo como o namespace de métrica para o escopo da conta de armazenamento.
  4. Selecione Transações como a métrica.
  5. Adicione um filtro para ResponseType e marcar para ver se alguma solicitação tem um código de resposta de SuccessWithThrottling (para SMB ou NFS) ou ClientThrottlingError (para REST).

Solução

  • Se a notificação de alteração de arquivo não for usada, desabilite a notificação de alteração de arquivo (preferencial).

  • Aumente a frequência do intervalo de votação de notificação de alteração de arquivo para reduzir o volume.

    Atualize o intervalo de sondagem do processo de trabalho W3WP para um valor mais alto (por exemplo, 10 ou 30 minutos) com base em seus requisitos. Defina HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSecondsno registro e reinicie o processo W3WP.

  • Se o diretório físico mapeado do site tiver uma estrutura de diretório aninhada, você poderá tentar limitar o escopo das notificações de alteração de arquivo para reduzir o volume de notificação. Por padrão, o IIS usa a configuração de Web.config arquivos no diretório físico ao qual o diretório virtual é mapeado, bem como em qualquer diretório filho nesse diretório físico. Se você não quiser usar Web.config arquivos em diretórios filho, especifique false o allowSubDirConfig atributo no diretório virtual. Mais detalhes podem ser encontrados aqui.

    Defina a configuração do diretório allowSubDirConfig virtual do IIS em Web.Config para false excluir diretórios filho físico mapeados do escopo.

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.