Solução de problemas de desempenho dos Arquivos do Azure

Este artigo lista problemas comuns relacionados ao desempenho de compartilhamentos de arquivos do Azure e apresenta possíveis causas e soluções alternativas. Para aproveitar ao máximo este guia de solução de problemas, recomendamos primeiro ler Noções básicas sobre o desempenho dos Arquivos do Azure.

Aplica-se a

Tipo de compartilhamento de arquivos	SMB	NFS
Compartilhamentos de arquivos padrão (GPv2), LRS/ZRS
Compartilhamentos de arquivos padrão (GPv2), GRS/GZRS
Compartilhamento de arquivos premium (FileStorage), LRS/ZRS

Solução de problemas de desempenho geral

Primeiro, elimine alguns motivos comuns pelos quais você pode ter problemas de desempenho.

Você está executando um sistema operacional antigo

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

Sua carga de trabalho está sendo limitada

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

Para entender os limites Standard e Premium do compartilhamento de arquivos, confira Compartilhamento de arquivos e alvos de escala de arquivos. Dependendo da carga de trabalho, a limitação geralmente pode ser evitada migrando dos compartilhamentos de arquivos Standard para Premium do Azure.

Para saber mais sobre como a limitação no compartilhamento ou na conta de armazenamento pode causar alta latência, baixa taxa de transferência e problemas gerais de desempenho, confira A conta de armazenamento ou o compartilhamento está sendo limitado.

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

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

Para confirmar se o compartilhamento ou a conta de armazenamento está sendo limitado, você pode acessar e usar as métricas do Azure no portal. Crie também alertas que notificarão você se um compartilhamento estiver sendo limitado ou prestes a ser limitado. Confira Solução de problemas dos Arquivos do Azure com a criação de alertas.

1. No portal do Microsoft Azure, acesse sua conta de armazenamento.

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

3. Selecione Arquivo como o namespace de métricas do escopo da sua conta de armazenamento.

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

5. Adicione um filtro para o Tipo de resposta e verifique se alguma solicitação foi limitada.

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

   • ClientAccountRequestThrottlingError
   • ClientAccountBandwidthThrottlingError

   Para os compartilhamentos de arquivos Premium, os seguintes tipos de respostas serão registrados em log se uma solicitação for limitada no compartilhamento:

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

   Se uma solicitação limitada tiver sido 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, confira Dimensões das métricas.

   

Solução

Se você estiver usando um compartilhamento de arquivos Premium, aumente o tamanho do compartilhamento de arquivos provisionado para aumentar o limite de IOPS. Para saber mais, confira Entendendo o provisionamento de compartilhamentos de arquivos Premium.

Causa 2: metadados ou carga de trabalho pesada de namespace

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

Para determinar se a maioria das suas 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 de resposta, adicione um filtro de propriedade para o Nome da API.

Soluções Alternativas

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

• Se você estiver usando compartilhamentos de arquivos SMB premium do Azure, use o cache 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 sobre os dados. Essa abordagem funciona para cenários de gravador/leitor único com vários leitores e nenhum gravador. Como o sistema de arquivos pertence ao cliente em vez de aos Arquivos do Azure, isso permite que as operações de metadados sejam locais. A configuração oferece desempenho semelhante ao do armazenamento local anexado diretamente. No entanto, como os dados estão em um VHD, eles não podem ser acessados por meio de qualquer outro meio que não seja a montagem 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 o Gerenciamento de Disco e selecione Ação > Criar VHD.
  3. Defina Local como a unidade de rede para a qual o compartilhamento de arquivos do Azure é mapeado, defina 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ê deverá ver uma nova letra da unidade aparecer no Gerenciamento de Disco representando esse VHD com acesso de leitura/gravação (por exemplo, E:). Em Explorador de Arquivos, você deverá visualizar 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 de rede de compartilhamento de arquivos padrão do Azure em Z:, e o mapeamento VHD na unidade E:.
  8. Deve haver um desempenho muito melhor em operações de metadados pesadas em arquivos na unidade mapeada VHD (E:) versus a unidade mapeada do compartilhamento de arquivos do Azure (Z:). Se desejado, deve ser possível desconectar a unidade de rede mapeada (Z:) e ainda acessam a unidade VHD montada (E:).
  • Para montar um VHD em um cliente Windows, você também pode usar o cmdlet Mount-DiskImage do PowerShell.
  • Para montar um VHD no Linux, confira a documentação da distribuição do Linux. Aqui está um exemplo.

Causa 3: aplicativo de thread único

Se o aplicativo que você está usando for de thread único, essa configuração poderá resultar em uma taxa de transferência de 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 ampliando 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 em clientes Windows ou o comando parallel em clientes Linux.

Causa 4: a quantidade de canais SMB excede 4

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

Solução

Defina a configuração de Windows por NIC para SMB, assim a quantidade total de canais não excederá quatro. Por exemplo, se você tiver duas 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)

A partir da versão 5.4 do kernel Linux, 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 parâmetro do read_ahead_kb kernel para 15 mebibytes (MiB). Para alterar esse valor, defina o tamanho de leitura antecipada persistentemente adicionando uma regra no udev, um gerenciador de dispositivos do 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 tornar o udev ciente do novo arquivo, você só precisa executar este comando uma vez.

   sudo udevadm control --reload
   

Latência muito alta para solicitações

Causa

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

Solução

• Execute o aplicativo por meio de uma VM que está 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 no portal do Azure. Uma grande diferença entre os valores das métricas SuccessE2ELatency e SuccessServerLatency é uma indicação da latência que provavelmente é causada pela rede ou pelo cliente. Confira Métricas de transação na referência de dados de monitoramento dos Arquivos do Azure.

O cliente não consegue alcançar a taxa de transferência máxima compatível com a rede

Causa

Uma possível causa é a falta de suporte a vários canais do SMB para compartilhamentos de arquivos Standard. Atualmente, os Arquivos do Azure só dão suporte a um canal em compartilhamentos de arquivos Standard. Portanto, há apenas uma conexão da VM do cliente com o servidor. Essa conexão única é vinculada a apenas um núcleo da VM cliente, portanto, a taxa de transferência máxima alcançável por meio de uma VM é limitada por um núcleo.

Solução alternativa

• Para compartilhamentos de arquivos premium, habilite o SMB Multichannel.
• A obtenção de uma VM com um núcleo maior pode ajudar a melhorar a taxa de transferência.
• A execução do aplicativo cliente por meio de várias VMs aumentará a taxa de transferência.
• Use APIs REST sempre que possível.
• O nconnect está disponível para compartilhamentos de arquivos do Azure NFS. Confira Melhorar o desempenho do compartilhamento de arquivo do Azure NFS com o nconnect.

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

Causa 1: cache

Uma possível causa da lentidão no desempenho é 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 verificar 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 cache=strict opção ao comando de montagem para garantir que o cache padrão ou o modo de cache "estrito" esteja habilitado.

Em alguns cenários, a serverino opção mount pode fazer com que o ls comando seja executado stat em todas as entradas de diretório. Esse comportamento resulta na degradação do desempenho quando você está listando um diretório grande. Verifique as opções de montagem na 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 verificar se as opções corretas estão sendo usadas executando o sudo mount | grep cifs comando e verificando sua saída. Confira o exemplo de saída abaixo:

//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 cache=strict opção or serverino não estiver presente, desmonte e monte os Arquivos do Azure novamente executando o comando mount 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 notificam se um compartilhamento está sendo limitado ou está prestes a ser limitado. Confira Solução de problemas dos Arquivos do Azure com a criação de alertas.

Solução para a causa 2

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

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

Causa

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

Solução alternativa

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

Latências altas para cargas de trabalho repletas de metadados que envolvem operações amplas de abertura/fechamento

Causa

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.
• Nas VMs do Linux, aumente o tempo limite do cache de entrada do diretório especificando actimeo=<sec> como uma opção de montagem. Por padrão, o tempo limite é de 1 segundo, então um valor maior, como 30 segundos, pode ajudar.
• Para VMs CentOS Linux ou RHEL (Red Hat Enterprise Linux), faça upgrade do sistema para 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 dos arquivos e pastas

Causa

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

Solução

Para resolver esse problema, ajuste o valor do Registro para permitir o DirectoryCacheEntrySizeMax armazenamento em cache de listagens de diretórios maiores na máquina cliente:

• Local: 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 é aprimorado.

Lentidão na cópia de arquivos em compartilhamentos de arquivos do Azure

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

Excesso de chamadas DirectoryOpen/DirectoryClose

Causa

Se o número de chamadas DirectoryOpen/DirectoryClose está entre as principais chamadas à API e essa quantidade de chamadas do cliente não é um comportamento esperado, o problema pode estar sendo causado pelo software antivírus instalado na VM do cliente 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

Causa

Alterações recentes nas configurações do recurso SMB Multichannel sem uma remontagem.

Solução

• Após qualquer alteração no cliente SMB do Windows ou nas configurações do SMB Multichannel da conta, você precisa desmontar o compartilhamento, aguardar 60 segundos e remontar o compartilhamento para disparar o multicanal.
• Para sistemas operacionais clientes do Windows, gere carga de E/S com alta profundidade de fila, digamos QD = 8, por exemplo, copiando um arquivo para disparar o SMB Multichannel. Para sistemas operacionais servidores, o SMB Multichannel é disparado com QD = 1, o que significa assim que você iniciar qualquer E/S para o compartilhamento.

Desempenho lento ao descompactar arquivos

Dependendo do método de compactação exato e da operação descompactação usada, as operações de descompactação podem ser realizadas mais lentamente em um compartilhamento de arquivos do Azure do que no disco local. Isso ocorre frequentemente porque as ferramentas de descompactação executam várias operações de metadados no processo de execução da descompactação de um arquivo compactado. Para o melhor desempenho, recomendamos copiar o arquivo compactado do compartilhamento de arquivos do Azure para o disco local, descompactando-o lá e, em seguida, usando uma ferramenta de cópia como o 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, usando vários threads para copiar dados em paralelo, pode compensar o desempenho reduzido das operações de metadados em Arquivos do Azure em relação ao disco local.

Alta latência em sites hospedados em compartilhamentos de arquivos

Causa

A notificação de alto número de alterações de arquivo nos compartilhamentos de arquivos pode resultar em altas latências. Isso normalmente 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 é definida para cada diretório na configuração padrão. Cada alteração (ReadDirectoryChangesW) no compartilhamento para o qual o cliente está registrado efetua pushes de uma notificação de alteração do serviço de arquivo para o cliente, o que usa recursos do sistema, e o problema piora com o número de alterações. Isso pode causar a limitação de compartilhamento e resultar em maior latência do lado do cliente.

Para confirmar isso, use as Métricas do Azure no portal.

1. No portal do Microsoft Azure, acesse sua conta de armazenamento.
2. No menu esquerdo, em Monitoramento, selecione Métricas.
3. Selecione Arquivo como o namespace de métricas do escopo da sua conta de armazenamento.
4. Selecione Transações como a métrica.
5. Adicione um filtro para ResponseType e verifique 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 (preferencial).

  • Desabilite a notificação de alteração de arquivo atualizando o FCNMode.
  • Atualize o intervalo de sondagem do W3WP (processo de trabalho do IIS) para 0 definindo HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds no registro e reinicie o processo W3WP. Para saber mais sobre essa configuração, confira Chaves do Registro comuns usadas por muitas partes do IIS.

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

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

• Se o diretório físico mapeado do seu 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ções. Por padrão, o IIS usa a configuração de arquivos Web.config no diretório físico para o qual o diretório virtual está mapeado, bem como em todos os diretórios filho nesse diretório físico. Se você não quiser usar arquivos Web.config em diretórios filho, especifique false para o allowSubDirConfig atributo no diretório virtual. Encontre mais detalhes aqui.

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

Confira também

• Solucionar problemas dos Arquivos do Azure
• Solução de problemas dos Arquivos do Azure com a criação de alertas
• Entender o desempenho dos Arquivos do Azure
• Visão geral dos alertas no Microsoft Azure
• Perguntas frequentes sobre os Arquivos do Azure

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.