Solucionar problemas de desempenho e isolar gargalos no Linux
Aplica-se a: ✔️ VMs linux
Problemas de desempenho e gargalos
Quando ocorrem problemas de desempenho ocorrem em diferentes sistemas operacionais e aplicativos, e cada caso requer uma abordagem exclusiva para solucionar problemas. CPU, memória, rede e entrada/saída (E/S) são as princiipais áreas em que podem ocorrer problemas. Cada uma dessas áreas exibe sintomas diferentes (às vezes simultaneamente) e requer um diagnóstico e uma solução diferentes.
Os problemas de desempenho podem ser causados por uma configuração incorreta do aplicativo ou da instalação. Um exemplo seria um aplicativo Web que tem uma camada de cache que não está configurada corretamente. Essa situação aciona mais solicitações fluindo de volta para o servidor de origem em vez de serem atendidas de um cache.
Em outro exemplo, o log de restauração de um banco de dados MySQL ou MariaDB está localizado no disco do sistema operacional (SO) ou em um disco que não atende aos requisitos do banco de dados. Nesse cenário, você pode ver menos transações por segundo (TPS) devido à competição por recursos e tempos de resposta mais altos (latência).
Se você entender completamente o problema, poderá identificar melhor onde procurar na pilha (CPU, memória, rede, E/S). Para solucionar problemas de desempenho, você precisa estabelecer uma linha de base que permita comparar métricas depois de fazer alterações e avaliar se o desempenho geral melhorou.
A solução de problemas de desempenho de uma VM (máquina virtual) não é diferente de resolver um problema de desempenho em um sistema físico. Trata-se de determinar qual recurso ou componente está causando um gargalo no sistema.
É importante entender que os gargalos sempre existem. A solução de problemas de desempenho tem tudo a ver com entender onde ocorre um gargalo e como movê-lo para um recurso menos ofensivo.
Este guia ajuda você a descobrir e resolver problemas de desempenho em Máquinas Virtuais do Azure no ambiente Linux.
Obter ponteiros de desempenho
Você pode obter ponteiros de desempenho que confirmam ou negam se a restrição de recurso existe.
Dependendo do recurso investigado, muitas ferramentas podem ajudá-lo a obter dados que pertencem a esse recurso. A tabela a seguir inclui exemplos para os principais recursos.
Recurso | Ferramenta |
---|---|
CPU | top , htop , mpstat , pidstat , vmstat |
Disco | iostat , iotop , vmstat |
Rede | ip , vnstat , iperf3 |
Memória | free , top , vmstat |
As seções a seguir discutem ponteiros e ferramentas que você pode usar para procurar os principais recursos.
Recurso de CPU
Uma certa porcentagem de CPU é usada ou não. 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
o .
A top
ferramenta é executada no modo interativo por padrão. Ele é atualizado a cada segundo e mostra os processos classificados pelo uso da CPU:
[root@rhel78 ~]$ 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 dd
linha de processo 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.
Observação
Você pode exibir o uso por CPU na
top
ferramenta selecionando 1.A
top
ferramenta exibe um uso total de mais de 100% se o processo for multithread e abranger mais de uma 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 indica 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 de uma CPU, o sistema será carregado de forma que os processos comecem a enfileirar. Se houver uma média de carga de 2 em um sistema de quatro CPUs, haverá cerca de 50% de uso geral da CPU.
Observação
Você pode obter rapidamente a contagem de CPU executando o nproc
comando.
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, o valor da CPU ociosa top
é mostrado antes do id
rótulo.)
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)
Quando você investiga problemas de desempenho de E/S, os termos a seguir ajudam a entender onde o problema ocorre.
Termo | Descrição |
---|---|
Tamanho de E/S | A quantidade de dados que é processada por transação, normalmente definida em bytes. |
Threads de E/S | O número de processos que estão interagindo com o dispositivo de armazenamento. Esse valor depende do aplicativo. |
Tamanho do bloco | O tamanho de E/S conforme definido pelo dispositivo de bloco de apoio. |
Tamanho do setor | O tamanho de cada um dos setores no disco. Esse valor normalmente é de 512 bytes. |
IOPS | Operações de entrada e saída por segundo. |
Latência | O tempo que uma operação de E/S leva para ser concluída. Esse valor é normalmente medido em milissegundos (ms). |
Taxa de transferência | Uma função da quantidade de dados transferidos que está em um período de tempo específico. Esse valor normalmente é definido como megabytes por segundo (MB/s). |
IOPS
Operações de entrada e saída por segundo (IOPS) é uma função do número de operações de entrada e saída (E/S) que são medidas ao longo de um determinado tempo (neste caso, segundos). As operações de E/S podem ser leituras ou gravações. Exclusões ou descartes também podem ser contados como uma operação no sistema de armazenamento. Cada operação tem uma unidade de alocação que corresponde igualmente ao tamanho de E/S.
O tamanho de E/S normalmente é definido no nível do aplicativo como a quantidade de dados gravados ou lidos por transação. Um tamanho de E/S comumente usado é 4K. No entanto, um tamanho de E/S menor que contém mais threads produz um valor de IOPS mais alto. Como cada transação pode ser concluída de forma relativamente rápida (devido ao seu tamanho pequeno), uma E/S menor permite que mais transações sejam concluídas no mesmo período de tempo.
Pelo contrário, suponha que você tenha o mesmo número de threads, mas use uma E/S maior. O IOPS diminui porque cada transação leva mais tempo para ser concluída. No entanto, a taxa de transferência aumenta.
Considere o seguinte exemplo:
1.000 IOPS significa que, para 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 aproximadamente um milissegundo para ser concluída, ou cerca de 1 ms de latência.
Conhecendo o valor do IOSize e o IOPS, você pode calcular a taxa de transferência multiplicando o IOSize pelo 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)
Uma versão mais amigável à equação poderia ser escrita da seguinte forma:
IOPS * IOSize = IOSize/s (Throughput)
Taxa de transferência
Ao contrário do IOPS, a taxa de transferência é uma função da quantidade de dados ao longo do tempo. Isso significa que, durante cada segundo, uma certa quantidade de dados é gravada ou lida. Essa velocidade é medida em quantidade de tempo> de dados></ou megabytes por segundo (MB/s).<
Se você souber os valores de taxa de transferência e IOSize, poderá calcular o IOPS dividindo a taxa de transferência por IOSize. Você deve normalizar as unidades para a menor conotação. Por exemplo, se IOSize for definido em kilobytes (kb), a taxa de transferência deverá ser convertida.
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.
Observação
10 MB é precisamente igual a 10.240 KB.
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 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 iostat
em um comando simples. A sintaxe básica é a seguinte:
iostat <parameters> <time-to-refresh-in-seconds> <number-of-iterations> <block-devices>
Os parâmetros ditam quais informações iostat
fornecem. Sem ter nenhum parâmetro de comando, iostat
exibe detalhes básicos:
[host@rhel76 ~]$ 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 dados mínimos sejam fornecidos para cada dispositivo. Estão disponíveis parâmetros que ajudam a identificar problemas fornecendo dados estendidos (como taxa de transferência, IOPS, tamanho da fila e latência).
Execute iostat
especificando gatilhos:
sudo iostat -dxctm 1
Para expandir ainda mais os iostat
resultados, use os parâmetros a seguir.
Parâmetro | Action |
---|---|
-d |
Exiba o relatório de utilização do dispositivo. |
-x |
Exibir estatísticas estendidas. Esse parâmetro é importante porque fornece IOPS, latência e tamanhos de fila. |
-c |
Exiba o relatório de utilização da CPU. |
-t |
Imprima o tempo para cada relatório exibido. Esse parâmetro é útil para execuções longas. |
-m |
Exiba estatísticas em megabytes por segundo, uma forma mais legível por humanos. |
O numeral 1
no comando diz 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:
[host@rhel76 ~]$ 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.
Coluna | Descrição |
---|---|
r/s |
Leituras por segundo (IOPS) |
w/s |
Gravações por segundo (IOPS) |
rMB/s |
Ler megabytes por segundo (taxa de transferência) |
wMB/s |
Gravar megabytes por segundo (taxa de transferência) |
avgrq-sz |
Tamanho médio de E/S em setores; multiplique esse número pelo tamanho do setor, que geralmente é de 512 bytes, para obter o tamanho de E/S em bytes (Tamanho de E/S) |
avgqu-sz |
Tamanho médio da fila (o número de operações de E/S enfileiradas aguardando para serem atendidas) |
await |
Tempo médio em milissegundos para E/S atendida pelo dispositivo (latência) |
r_await |
Tempo médio de leitura em milissegundos para E/S atendida pelo dispositivo (latência) |
w_await |
Tempo médio de leitura em milissegundos para E/S atendida pelo dispositivo (latência) |
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. Os dados devem sempre ser capturados iostat
e analisados quanto a possíveis gargalos. A alta latência pode indicar que o disco está atingindo um ponto de saturação.
Observação
Você pode usar o comando para exibir estatísticas de pidstat -d
E/S por processo.
Recurso de rede
As redes podem enfrentar dois gargalos principais: baixa largura de banda e alta latência.
Você pode usar vnstat
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
A latência de rede em dois sistemas diferentes pode ser determinada usando um comando simples ping
no Internet Control Message Protocol (ICMP):
[root@rhel78 ~]# 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
Você pode verificar a largura de banda da rede usando ferramentas como iperf3
. A iperf3
ferramenta funciona no modelo de servidor/cliente no qual o aplicativo é iniciado especificando o -s
sinalizador 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
root@ubnt:~# iperf3 -s ----------------------------------------------------------- Server listening on 5201 -----------------------------------------------------------
Cliente
root@ubnt2:~# 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.
Alguns parâmetros comuns iperf3
para o cliente são mostrados na tabela a seguir.
Parâmetro | Descrição |
---|---|
-P |
Especifica o número de fluxos de cliente paralelos a serem executados. |
-R |
Inverte o tráfego. Por padrão, o cliente envia dados para o servidor. |
--bidir |
Testa upload e download. |
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 revisar a utilização geral da memória e determinar quanta memória vários processos estão consumindo:
[root@rhel78 ~]# 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 free
memó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:
[root@rhel78 ~]# 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 a memória residente. Isso 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:
[root@rhel78 ~]# 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 de eventos de eliminação de OOM (falta de memória), conforme mostrado na seguinte saída de exemplo:
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 OOM é invocado depois que a RAM (memória física) e o SWAP (disco) são consumidos.
Observação
Você pode usar o pidstat -r
comando para exibir estatísticas de memória por processo.
Determinar se existe uma restrição de recurso
Você pode determinar se existe uma restrição usando os indicadores anteriores e conhecendo a configuração atual. A restrição pode ser comparada à configuração existente.
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 <o recurso> measurement1><e a configuração< atual do recurso> for capaz de fornecer apenas< measurement2>, esse requisito poderá ser um fator limitante.
Definir o recurso limitante
Depois de determinar um recurso como o fator limitante na configuração atual, identifique como ele pode ser alterado e como ele afeta a carga de trabalho. Há situações em que a limitação de recursos pode existir devido a uma medida de economia de custos, mas o aplicativo ainda é capaz de lidar com o gargalo sem problemas.
Por exemplo:
Se o aplicativo exigir 128 GB (medição) de RAM (recurso) e a configuração atual de RAM (recurso) for capaz de fornecer apenas 64 GB (medição), esse requisito poderá ser um fator limitante.
Agora, você pode definir o recurso limitante e executar ações com base nesse recurso. O mesmo conceito se aplica a outros recursos.
Se esses recursos limitantes forem esperados como uma medida de economia de custos, o aplicativo deverá contornar os gargalos. No entanto, se as mesmas medidas de economia de custos existirem e o aplicativo não puder lidar facilmente com a falta de recursos, essa configuração poderá causar problemas.
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. Os gargalos sempre existem e só podem ser movidos para um local diferente do projeto.
Por exemplo, se o aplicativo estiver sendo limitado pelo desempenho do disco, 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.
Ao obter dados nas etapas anteriores, agora você pode fazer alterações com base em dados reais e mensuráveis. Você também pode comparar essas alterações com a linha de base medida anteriormente para verificar se há uma diferença tangível.
Considere o seguinte exemplo:
Quando você obteve uma linha de base enquanto o aplicativo estava em execução, determinou que o sistema tinha um uso constante de 100% da CPU em uma configuração de duas CPUs. Você observou uma média de carga de 4. Isso significava que o sistema estava enfileirando solicitações. Uma mudança para um sistema de 8 CPUs reduziu o uso da CPU para 25% e a média de carga foi reduzida para 2 quando a mesma carga foi aplicada.
Neste exemplo, há uma diferença mensurável quando você compara 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
As migrações de uma configuração local para a computação em nuvem podem ser afetadas por várias diferenças de desempenho.
CPU
Dependendo da arquitetura, uma configuração local pode executar CPUs com velocidades de clock mais altas e caches maiores. O resultado seria tempos de processamento reduzidos e instruções por ciclo (IPC) mais altas. É 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 o equivalente na contagem de CPUs for criado 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.
Disco
O desempenho do disco no Azure é definido pelo tipo e tamanho do disco (exceto para o disco Ultra, que fornece flexibilidade em relação ao tamanho, IOPS e taxa de transferência). O tamanho do disco define os limites de IOPS e taxa de transferência.
A latência é uma métrica que depende do tipo de disco em vez do tamanho do disco. A maioria das soluções de armazenamento local são matrizes de disco que têm caches DRAM. Esse tipo de cache fornece latência inferior a um milissegundo (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.
Tipo de disco | Latência |
---|---|
Disco Ultra/SSD Premium v2 | μs de três dígitos (microssegundos) |
SSD Premium/SSD Padrão | ms de um dígito (milissegundos) |
HDD Standard | Dois dígitos ms (milissegundos) |
Observação
Um disco é limitado se atingir seus limites de IOPS ou largura de banda, caso contrário, a latência pode aumentar para 100 milissegundos ou mais.
A diferença de latência entre um SSD local (geralmente menos de um milissegundo) e Premium (milissegundos de um dígito) torna-se um fator limitante. Observe as diferenças de latência entre as ofertas de armazenamento e selecione a oferta que melhor se adapta aos requisitos do aplicativo.
Rede
A maioria das configurações de rede local usa links de 10 Gbps. No Azure, a largura de banda da rede é definida diretamente pelo tamanho das VMs (máquinas virtuais). Algumas larguras de banda de rede podem exceder 40 Gbps. Certifique-se de selecionar um tamanho que tenha largura de banda suficiente para as necessidades do seu aplicativo. Na maioria dos casos, o fator limitante são os limites de taxa de transferência da VM ou do disco em vez da rede.
Memória
Selecione um tamanho de VM que tenha RAM suficiente para o que está configurado no momento.
Diagnóstico de desempenho (PerfInsights)
PerfInsights é a ferramenta recomendada do suporte do Azure para problemas de desempenho de VM. Ele foi projetado para cobrir as 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 os sistemas operacionais Windows e Linux. Verifique se a distribuição do Linux está na lista de distribuições com suporte para o Diagnóstico de Desempenho para Linux.
Executar e analisar relatórios por meio do portal do Azure
Quando o PerfInsights é instalado por meio do portal do Azure, o software instala uma extensão na VM. Os usuários também podem instalar o PerfInsights como uma extensão acessando diretamente a folha Extensões na VM e selecionando uma opção de diagnóstico de desempenho.
Opção 1 do portal do Azure
Navegue pela folha da VM e selecione a opção Diagnóstico de desempenho. Você será solicitado a instalar a opção (usa extensões) na VM para a qual você a selecionou.
Opção 2 do portal do Azure
Navegue até a guia Diagnosticar e Resolver Problemas na folha 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 do PerfInsights, o local do conteúdo depende se o relatório foi executado por meio do portal do Azure ou como um executável. Para qualquer uma das opções, acesse a pasta de log gerada ou (se estiver no portal do Azure) baixe localmente para análise.
Executar pelo portal do Azure
Abra o relatório PerfInsights. A guia Descobertas registra todos os 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, vemos que foram detectadas descobertas de impacto médio relacionadas ao armazenamento e vemos 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
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.