Solucionar problemas de desempenho e isolar gargalos no Linux

Aplica-se a: ✔️ VMs Linux

Resumo

Solucione problemas de desempenho de entrada e saída de CPU, memória e disco e isole gargalos em VMs (máquinas virtuais) do Linux no Azure.

Problemas de desempenho e gargalos

Problemas de desempenho podem ocorrer em diferentes sistemas operacionais e aplicativos. Cada cenário requer uma abordagem de solução de problemas direcionada. Em VMs do Linux, os problemas de desempenho normalmente aparecem em uma ou mais áreas de recursos principais: CPU, memória, rede e E/S (entrada/saída). Cada recurso apresenta sintomas distintos, muitas vezes sobrepostos, e requer diferentes métodos de diagnóstico e estratégias de correção.

Em muitos casos, problemas de aplicativo ou configuração causam degradação de desempenho, não a própria plataforma. Por exemplo, um aplicativo Web com uma camada de cache configurada incorretamente pode rotear solicitações excessivas para o servidor de origem em vez de servi-las do cache. Essa configuração incorreta aumenta os tempos de carga e resposta da CPU. Da mesma forma, o posicionamento do armazenamento pode afetar as cargas de trabalho do banco de dados. Se o redo log de um banco de dados MySQL ou MariaDB residir no disco do sistema operacional ou no armazenamento que não atenda aos requisitos de desempenho do banco de dados, a contenção de E/S poderá causar maior latência e redução de transações por segundo (TPS).

A solução de problemas efetiva começa com a compreensão do problema e a identificação de onde o gargalo existe na pilha, seja processador, memória, rede ou entrada/saída. Estabelecer uma linha de base de desempenho é fundamental, pois permite comparar as métricas antes e depois das alterações e determinar se essas alterações resultam em melhoria mensurável.

Solucionar problemas de desempenho em uma máquina virtual é fundamentalmente o mesmo que em um sistema físico: a meta é determinar qual recurso está limitando o desempenho geral. Gargalos sempre existem em qualquer sistema. A solução de problemas de desempenho é o processo de identificar o gargalo atual e, quando possível, transferi-lo para um recurso menos restritivo.

Este guia ajuda você a identificar e resolver problemas de desempenho em VMs do Azure baseadas em Linux, concentrando-se em isolar gargalos e aplicar diagnósticos direcionados.

Identificar o gargalo provável

Comece a solução de problemas observando o comportamento do sistema e as relações de métrica, não a utilização de recursos individuais isoladamente. Os gargalos de desempenho geralmente aparecem indiretamente, e o recurso restrito nem sempre é o mais óbvio.

A tabela a seguir mapeia observações comuns e padrões de métrica para o recurso mais provável a ser investigado primeiro.

Depois de identificar o padrão mais relevante, prossiga para a seção de recursos correspondente para diagnóstico detalhado e validação.

Coletar informações de desempenho

Use esses insights de desempenho para validar se existe um gargalo de recursos.

Diferentes ferramentas coletam dados de desempenho dependendo do recurso em investigação. A tabela a seguir mostra ferramentas de exemplo para os recursos primários.

As seções a seguir discutem dados de desempenho e ferramentas que você pode usar para investigação.

Recurso de CPU

O uso da CPU representa a porcentagem de tempo que o processador realiza ativamente trabalho em vez de permanecer ocioso. Da mesma forma, os processos gastam tempo na CPU (como 80% usr de uso) ou não (como 80% ociosos). A principal ferramenta para confirmar o uso da CPU é top.

A top ferramenta é executada no modo interativo por padrão. Ele é atualizado a cada segundo e mostra os processos classificados pelo uso da CPU:

top

top - 19:02:00 up  2:07,  2 users,  load average: 1.04, 0.97, 0.96
Tasks: 191 total,   3 running, 188 sleeping,   0 stopped,   0 zombie
%Cpu(s): 29.2 us, 22.0 sy,  0.0 ni, 48.5 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
KiB Mem :  7990204 total,  6550032 free,   434112 used,  1006060 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  7243640 avail Mem

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 22804 root      20   0  108096    616    516 R  99.7  0.0   1:05.71 dd
  1680 root      20   0  410268  38596   5644 S   3.0  0.5   2:15.10 python
   772 root      20   0   90568   3240   2316 R   0.3  0.0   0:08.11 rngd
  1472 root      20   0  222764   6920   4112 S   0.3  0.1   0:00.55 rsyslogd
 10395 theuser   20   0  162124   2300   1548 R   0.3  0.0   0:11.93 top
     1 root      20   0  128404   6960   4148 S   0.0  0.1   0:04.97 systemd
     2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd
     4 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H
     6 root      20   0       0      0      0 S   0.0  0.0   0:00.56 ksoftirqd/0
     7 root      rt   0       0      0      0 S   0.0  0.0   0:00.07 migration/0
     8 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_bh
     9 root      20   0       0      0      0 S   0.0  0.0   0:06.00 rcu_sched
    10 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 lru-add-drain
    11 root      rt   0       0      0      0 S   0.0  0.0   0:00.05 watchdog/0
    12 root      rt   0       0      0      0 S   0.0  0.0   0:00.04 watchdog/1
    13 root      rt   0       0      0      0 S   0.0  0.0   0:00.03 migration/1
    14 root      20   0       0      0      0 S   0.0  0.0   0:00.21 ksoftirqd/1
    16 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/1:0H
    18 root      20   0       0      0      0 S   0.0  0.0   0:00.01 kdevtmpfs
    19 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 netns
    20 root      20   0       0      0      0 S   0.0  0.0   0:00.00 khungtaskd
    21 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 writeback
    22 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kintegrityd

Agora, olhe para a linha de processo dd dessa saída:

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 22804 root      20   0  108096    616    516 R  99.7  0.0   1:05.71 dd

Você pode ver que o dd processo está consumindo 99,7% da CPU.

Outra referência útil é a média de carga. A média de carga mostra uma carga média do sistema em intervalos de 1 minuto, 5 minutos e 15 minutos. O valor mostra o nível de carga do sistema. A interpretação desse valor depende do número de CPUs disponíveis. Por exemplo, se a média de carga for 2 em um sistema com uma CPU, o sistema estará tão sobrecarregado que os processos começarão a se acumular na fila. Se houver uma média de carga de 2 em um sistema de quatro CPUs, haverá cerca de 50% de uso geral da CPU.

No exemplo anterior, a média de carga é de 1,04. Este é um sistema de duas CPUs, o que significa que há cerca de 50% de uso da CPU. Você pode verificar esse resultado se observar o valor de CPU ociosa de 48,5%. Na saída do comando top, o valor da CPU ociosa é mostrado antes do rótulo id.

Use a média de carga como uma visão geral rápida do desempenho do sistema.

Execute o uptime comando para obter a média de carga.

Recurso de disco (E/S)

Os termos a seguir ajudam a explicar como identificar e entender os contadores de desempenho de E/S.

IOPS

O IOPS (Operações de Saída de Entrada por Segundo) mede o número de operações de E/S (entrada e saída) em um tempo específico, geralmente segundos. As operações de E/S incluem leituras e gravações. O sistema também pode contar exclusões ou descartes como operações no sistema de armazenamento. Cada operação tem uma unidade de alocação que corresponde ao tamanho de E/S.

Os aplicativos normalmente definem o tamanho de E/S como a quantidade de dados gravados ou lidos por transação. Um tamanho de E/S comum é 4K. No entanto, um tamanho de E/S menor com mais threads resulta em um valor de IOPS mais alto. Como cada transação é concluída rapidamente devido ao seu tamanho pequeno, um tamanho menor de E/S permite que mais transações são concluídas no mesmo período de tempo.

Por outro lado, se você usar o mesmo número de threads, mas escolher um tamanho maior de E/S, o IOPS diminuirá porque cada transação levará mais tempo para ser concluída. No entanto, a taxa de transferência aumenta.

Considere o seguinte exemplo:

1.000 IOPS significa que, a cada segundo, mil operações são concluídas. Cada operação leva cerca de um milissegundo. (Há 1.000 milissegundos em um segundo.) Em teoria, cada transação tem cerca de um milissegundo para concluir ou cerca de 1 ms de latência.

Se você souber o valor de IOSize e o IOPS, poderá calcular a taxa de transferência multiplicando IOSize por IOPS.

Por exemplo:

• 1.000 IOPS em 4K IOSize = 4.000 KB/s ou 4 MB/s (3,9 MB/s para ser mais preciso)

• 1.000 IOPS a 1M IOSize = 1.000 MB/s ou 1 GB/s (976 MB/s para ser mais preciso)

Você pode escrever uma versão mais amigável à equação da seguinte maneira:

IOPS * IOSize = IOSize/s (Throughput)

Vazão

Ao contrário do IOPS, a taxa de transferência é uma função da quantidade de dados ao longo do tempo. Essa medida significa que, durante cada segundo, uma determinada quantidade de dados é gravada ou lida. Você mede essa velocidade em <quantidade de dados por tempo>/<ou megabytes por segundo (MB/s).>

Quando você souber os valores de taxa de transferência e tamanho de E/S, poderá calcular IOPS dividindo a taxa de transferência pelo tamanho de E/S. Você precisa normalizar os dois valores para a mesma unidade de medida. Por exemplo, se o tamanho de E/S for definido em quilobytes (KB), você deverá converter a taxa de transferência em KB antes de executar o cálculo.

O formato da equação é escrito da seguinte forma:

Throughput / IOSize = IOPS

Para contextualizar essa equação, considere uma taxa de transferência de 10 MB/s em um IOSize de 4K. Quando você insere os valores na equação, o resultado é 10.240/4=2.560 IOPS.

Latência

A latência é a medida do tempo médio que cada operação leva para ser concluída. IOPS e latência estão relacionados porque ambos os conceitos são uma função do tempo. Por exemplo, a 100 IOPS, cada operação leva aproximadamente 10 ms para ser concluída. Mas a mesma quantidade de dados pode ser buscada ainda mais rapidamente com IOPS mais baixas. A latência também é conhecida como tempo de busca.

Entenda a saída do iostat

Como parte do pacote sysstat, a iostat ferramenta fornece insights sobre o desempenho do disco e as métricas de uso. iostat pode ajudar a identificar gargalos relacionados ao subsistema de disco.

Você pode executar o iostat utilitário usando um comando simples. A sintaxe básica é mostrada da seguinte maneira:

iostat <parameters> <time-to-refresh-in-seconds> <number-of-iterations> <block-devices>

Os parâmetros ditam quais informações iostat fornecem. Sem qualquer parâmetro de comando, iostat exibe detalhes básicos:

iostat

Linux 3.10.0-957.21.3.el7.x86_64 (rhel76)       08/05/2019      _x86_64_        (1 CPU)
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          41.06    0.00   30.47   21.00    0.00    7.47
Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             182.77      5072.69      1066.64     226090      47540
sdd               2.04        42.56        22.98       1897       1024
sdb              12.61       229.23     96065.51      10217    4281640
sdc               2.56        46.16        22.98       2057       1024
md0               2.67        73.60        45.95       3280       2048

Por padrão, iostat exibe dados para todos os dispositivos de bloco existentes, embora forneçam dados mínimos para cada dispositivo. Para ajudar a identificar problemas, use parâmetros que fornecem dados estendidos, como taxa de transferência, IOPS, tamanho da fila e latência.

Execute iostat com a especificação de gatilhos:

iostat -dxctm 1

Para expandir ainda mais os iostat resultados, use os parâmetros a seguir.

O numeral 1 no comando indica iostat para atualizar a cada segundo. Para interromper a atualização, selecione Ctrl+C.

Se você incluir os parâmetros extras, a saída será semelhante ao seguinte texto:

iostat -dxctm 1

        Linux 3.10.0-957.21.3.el7.x86_64 (rhel76)       08/05/2019      _x86_64_        (1 CPU)
        08/05/2019 07:03:36 PM
    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
               3.09    0.00    2.28    1.50    0.00   93.14
    
    Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
    sda               0.02     0.52    9.66    2.46     0.31     0.10    70.79     0.27   23.97    6.68   91.77   2.94   3.56
    sdd               0.00     0.00    0.12    0.00     0.00     0.00    64.20     0.00    6.15    6.01   12.50   4.44   0.05
    sdb               0.00    22.90    0.47    0.45     0.01     5.74 12775.08     0.17  183.10    8.57  367.68   8.01   0.74
    sdc               0.00     0.00    0.15    0.00     0.00     0.00    54.06     0.00    6.46    6.24   14.67   5.64   0.09
    md0               0.00     0.00    0.15    0.01     0.00     0.00    89.55     0.00    0.00    0.00    0.00   0.00   0.00

Entenda os valores

As colunas principais da iostat saída são mostradas na tabela a seguir.

Os dados apresentados por iostat são informativos, mas a presença de determinados dados em determinadas colunas não significa que haja um problema. Sempre capture e analise dados de iostat para possíveis gargalos. A alta latência pode indicar que o disco está atingindo um ponto de saturação.

Recurso de rede

As redes podem enfrentar dois gargalos principais: baixa largura de banda e alta latência.

Você pode usar vmstat para capturar detalhes de largura de banda ao vivo. No entanto, vnstat não está disponível em todas as distribuições. A ferramenta amplamente disponível iptraf-ng é outra opção para visualizar o tráfego da interface em tempo real.

Latência da rede

Você pode determinar a latência de rede entre dois sistemas diferentes usando o comando simples ping no Protocolo de Mensagem de Controle de Internet (ICMP):

ping 1.1.1.1

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=5.33 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=5.29 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=5.29 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=53 time=5.24 ms
^C
--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 5.240/5.291/5.339/0.035 ms

Para interromper a atividade de ping, selecione Ctrl+C.

Largura de banda da rede

Verifique a largura de banda de rede usando ferramentas como iperf3. A iperf3 ferramenta funciona no modelo de servidor/cliente. Inicie o aplicativo especificando a flag -s no servidor. Em seguida, os clientes se conectam ao servidor especificando o endereço IP ou o FQDN (nome de domínio totalmente qualificado) do servidor em conjunto com o -c sinalizador. Os snippets de código a seguir mostram como usar a iperf3 ferramenta no servidor e no cliente.

• Servidor

  iperf3 -s
  

  -----------------------------------------------------------
  Server listening on 5201
  -----------------------------------------------------------
  

• Cliente

iperf3 -c 10.1.0.4

Connecting to host 10.1.0.4, port 5201
[  5] local 10.1.0.4 port 60134 connected to 10.1.0.4 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  5.78 GBytes  49.6 Gbits/sec    0   1.25 MBytes
[  5]   1.00-2.00   sec  5.81 GBytes  49.9 Gbits/sec    0   1.25 MBytes
[  5]   2.00-3.00   sec  5.72 GBytes  49.1 Gbits/sec    0   1.25 MBytes
[  5]   3.00-4.00   sec  5.76 GBytes  49.5 Gbits/sec    0   1.25 MBytes
[  5]   4.00-5.00   sec  5.72 GBytes  49.1 Gbits/sec    0   1.25 MBytes
[  5]   5.00-6.00   sec  5.64 GBytes  48.5 Gbits/sec    0   1.25 MBytes
[  5]   6.00-7.00   sec  5.74 GBytes  49.3 Gbits/sec    0   1.31 MBytes
[  5]   7.00-8.00   sec  5.75 GBytes  49.4 Gbits/sec    0   1.31 MBytes
[  5]   8.00-9.00   sec  5.75 GBytes  49.4 Gbits/sec    0   1.31 MBytes
[  5]   9.00-10.00  sec  5.71 GBytes  49.1 Gbits/sec    0   1.31 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  57.4 GBytes  49.3 Gbits/sec    0             sender
[  5]   0.00-10.04  sec  57.4 GBytes  49.1 Gbits/sec                  receiver

iperf Done.

A tabela a seguir mostra alguns parâmetros comuns iperf3 para o cliente.

Recurso de memória

A memória é outro recurso de solução de problemas a ser verificado porque os aplicativos podem ou não usar uma parte da memória. Você pode usar ferramentas como free e top para examinar a utilização geral da memória e determinar a quantidade de memória que vários processos estão consumindo:

free -m

              total        used        free      shared  buff/cache   available
Mem:           7802         435        5250           9        2117        7051
Swap:             0           0           0

Em sistemas Linux, é comum ver 99% de utilização de memória. free Na saída, há uma coluna chamada buff/cache. O kernel do Linux usa memória livre (não utilizada) para armazenar em cache solicitações de E/S para melhores tempos de resposta. Esse processo é chamado de cache de página. Durante a pressão de memória (cenários em que a memória está acabando), o kernel retorna a memória usada para o cache de página para que os aplicativos possam usar essa memória.

Na saída, a coluna disponível indica quanta freememória está disponível para os processos consumirem. Este valor é calculado adicionando as quantidades de memória buff/cache e memória livre.

Você pode configurar o top comando para classificar processos por utilização de memória. Por padrão, top classifica por porcentagem de CPU (%). Para classificar por utilização de memória (%), selecione Shift+M ao executar .top O texto a seguir mostra a saída do top comando:

top

top - 22:40:15 up  5:45,  2 users,  load average: 0.08, 0.08, 0.06
Tasks: 194 total,   2 running, 192 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.3 us, 41.8 sy,  0.0 ni, 45.4 id,  0.0 wa,  0.0 hi,  0.5 si,  0.0 st
KiB Mem :  7990204 total,   155460 free,  5996980 used,  1837764 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  1671420 avail Mem

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 45283 root      20   0 5655348   5.3g    512 R  99.7 69.4   0:03.71 tail
  3124 omsagent  20   0  415316  54112   5556 S   0.0  0.7   0:30.16 omsagent
  1680 root      20   0  413500  41552   5644 S   3.0  0.5   6:14.96 python
[...]

A RES coluna indica memória residente. Esse valor representa o uso real do processo. A top ferramenta fornece uma saída semelhante em free termos de KB (kilobytes).

A utilização da memória pode aumentar mais do que o esperado se o aplicativo tiver vazamentos de memória. Em um cenário de vazamento de memória, os aplicativos não podem liberar páginas de memória que não são mais usadas.

Aqui está outro comando usado para exibir os principais processos que consomem memória:

ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head

O texto a seguir mostra um exemplo de saída do comando:

ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head

   PID COMMAND         USER     COMMAND                     %CPU %MEM
 45922 tail            root     tail -f /dev/zero           82.7 61.6
[...]

Você pode identificar a pressão de memória por meio de eventos de Kill de OOM, como mostrado na saída de exemplo a seguir:

Jun 19 22:42:14 rhel78 kernel: Out of memory: Kill process 45465 (tail) score 902 or sacrifice child
Jun 19 22:42:14 rhel78 kernel: Killed process 45465 (tail), UID 0, total-vm:7582132kB, anon-rss:7420324kB, file-rss:0kB, shmem-rss:0kB

O sistema invoca o OOM depois que RAM (memória física) e SWAP (disco) são consumidos.

Determinar se existe uma restrição de recurso

Você pode identificar restrições de recursos correlacionando indicadores com a configuração atual.

Aqui está um exemplo de uma restrição de disco:

Uma VM D2s_v3 é capaz de 48 MB/s de taxa de transferência não armazenada em cache. A essa VM, um disco P30 é anexado com capacidade para 200 MB/s. O aplicativo requer um mínimo de 100 MB/s.

Neste exemplo, o recurso limitante é a taxa de transferência da VM geral. O requisito do aplicativo versus o que a configuração de disco ou VM pode fornecer indica o recurso restritivo.

Se o aplicativo exigir <um recurso> de medição1<> e a configuração atual do <recurso> for capaz de fornecer apenas <medição2>, esse requisito poderá ser um fator de restrição.

Definir o recurso limitante

Depois de identificar um gargalo de recursos na configuração atual, avalie possíveis alterações e avalie o impacto na carga de trabalho. Em alguns casos, o gargalo existe como uma opção de otimização de custo e o aplicativo continua operando dentro dos limites de desempenho aceitáveis.

Por exemplo, quando um aplicativo requer 128 GB (medida) de RAM (recurso), mas a configuração atual fornece apenas 64 GB (recurso), a memória se torna um gargalo para a carga de trabalho.

Depois de identificar o recurso de gargalo, defina a restrição e execute as medidas apropriadas. Essa abordagem se aplica a todos os recursos.

Alguns gargalos resultam de configurações de economia de custos e são aceitáveis quando o aplicativo pode tolerá-los. Quando o aplicativo não pode tolerar os recursos reduzidos, a configuração se torna problemática.

Faça alterações com base nos dados obtidos

Projetar para o desempenho não é resolver problemas, mas entender onde o próximo gargalo pode ocorrer e como contorná-lo. Gargalos sempre existem e você só pode posicioná-los em um local diferente no projeto.

Por exemplo, se o desempenho do disco limitar o aplicativo, você poderá aumentar o tamanho do disco para permitir mais taxa de transferência. No entanto, a rede se torna o próximo gargalo. Como os recursos são limitados, não há uma configuração ideal e você deve resolver os problemas regularmente.

Depois de coletar dados das etapas anteriores, ajuste o sistema com base em dados reais e mensuráveis. Compare essas alterações com a linha de base estabelecida anteriormente para verificar uma melhoria mensurável.

Considere o seguinte exemplo:

Uma linha de base mostrou 100% de uso da CPU em um sistema com duas CPUs e uma média de carga de 4, indicando o enfileiramento de requisições. Depois de redimensionar para oito CPUs, a mesma carga de trabalho reduziu o uso da CPU para 25% e reduziu a média de carga para 2.

Neste exemplo, você verá uma diferença mensurável ao comparar os resultados obtidos com os recursos alterados. Antes da mudança, havia uma clara restrição de recursos. Mas após a mudança, há recursos suficientes para aumentar a carga.

Migrar do local para a nuvem

Várias diferenças de desempenho podem afetar as migrações de uma configuração local para a computação em nuvem.

CPU

Dependendo da arquitetura, uma configuração local pode executar CPUs com velocidades de clock mais altas e caches maiores. O resultado é tempos de processamento reduzidos e IPC (instruções mais altas por ciclo). É importante entender as diferenças nos modelos e métricas de CPU ao trabalhar em migrações. Nesse caso, uma relação um-para-um entre as contagens de CPU pode não ser suficiente.

Por exemplo:

Em um sistema local que tem quatro CPUs executadas a 3,7 GHz, há um total de 14,8 GHz disponíveis para processamento. Se você criar o equivalente na contagem de CPU usando uma VM D4s_v3 com suporte de CPUs de 2,1 GHz, a VM migrada terá 8,1 GHz disponíveis para processamento. Isso representa uma redução de cerca de 44% no desempenho.

Disk

O desempenho do disco no Azure depende do tipo e do tamanho do disco, exceto para o disco Ultra, que oferece flexibilidade em tamanho, IOPS e taxa de transferência. O tamanho do disco define os limites de IOPS e taxa de transferência.

A latência depende do tipo de disco em vez do tamanho do disco. A maioria das soluções de armazenamento local usa matrizes de disco com caches DRAM. Esse tipo de cache fornece latência de sub-milissegundos (cerca de 200 microssegundos) e alta taxa de transferência de leitura/gravação (IOPS).

As latências médias do Azure são mostradas na tabela a seguir.

A diferença de latência entre uma configuração local (geralmente menor que um milissegundo) e o SSD Premium (milissegundos de dígito único) pode ser um fator limitante. Observe as diferenças de latência entre as ofertas de armazenamento e selecione a oferta que melhor atende aos requisitos do seu aplicativo.

Rede

A maioria das configurações de rede local usa links de 10 Gbps. No Azure, o tamanho das VMs determina diretamente a largura de banda de rede. Algumas larguras de banda de rede podem exceder 40 Gbps. Selecione um tamanho que forneça largura de banda suficiente para as necessidades do aplicativo. Na maioria dos casos, os limites de taxa de transferência da VM ou disco, em vez da rede, são o fator limitante.

Memória

Selecione um tamanho de VM que tenha RAM suficiente para o que está configurado no momento.

Diagnóstico de desempenho (PerfInsights)

O suporte do Azure recomenda o PerfInsights para problemas de desempenho de VM. Ele fornece práticas recomendadas e guias de análise dedicadas para CPU, memória e E/S. Você pode executá-lo sob demanda por meio do portal do Azure ou de dentro da VM e, em seguida, compartilhar os dados com a equipe de suporte do Azure.

Executar PerfInsights

O PerfInsights está disponível para o sistema operacional Linux . Verifique se a distribuição do Linux está na lista de distribuições com suporte para Diagnóstico de Desempenho para Linux.

Executar e analisar relatórios por meio do portal do Azure

Quando você instala o PerfInsights por meio do portal do Azure, o software instala uma extensão na VM. Você também pode instalar o PerfInsights como uma extensão acessando diretamente extensões e selecionando uma opção de diagnóstico de desempenho.

Opção 1 do portal do Azure

Navegue até a folha da VM e selecione Diagnóstico de desempenho. Em seguida, instale-a na VM de destino (usa extensões).

Opção 2 do portal do Azure

Navegue até a guia Diagnosticar e Resolver Problemas no painel da VM e procure o link Solução de Problemas em Problemas de Desempenho da VM.

O que procurar no relatório PerfInsights

Depois de executar o relatório PerfInsights, o local do conteúdo dependerá se você executará o relatório por meio do portal do Azure ou como executável. Para qualquer opção, você pode acessar a pasta de log gerada ou (se estiver no portal do Azure) baixar localmente para análise.

Executar pelo portal do Azure

Abra o relatório PerfInsights. A aba Descobertas registra possíveis valores discrepantes em termos de consumo de recursos. Se houver instâncias de desempenho lento devido ao uso de recursos específicos, a guia Descobertas categorizará cada descoberta como Alto impacto ou Médio impacto.

Por exemplo, no relatório a seguir, você verá que a ferramenta detectou descobertas de impacto médio relacionadas ao armazenamento e verá as recomendações correspondentes. Se você expandir o evento Descobertas , verá vários detalhes importantes.

Para obter mais informações sobre o PerfInsights no sistema operacional Linux, consulte Como usar o PerfInsights Linux no Microsoft Azure.

Mais informações

• Solução de problemas de desempenho da máquina virtual do Azure no Linux ou no Windows

• Diagnóstico de desempenho de máquinas virtuais do Azure