Como otimizar o desempenho do disco permanente e do SSD local

Discos permanentes são a opção de armazenamento mais comum devido ao preço, desempenho e previsibilidade. No entanto, é possível criar instâncias com SSDs locais para ter um desempenho ainda melhor e uma latência menor, mas sem a redundância e a durabilidade de dados adquiridos com os discos permanentes. Ao configurar uma opção de armazenamento para aplicativos executados nas instâncias, use os seguintes processos:

  • Determine de quanto espaço você precisa.
  • Determine que características de desempenho seus aplicativos exigem.
  • Configure as instâncias para otimizar o desempenho do armazenamento.

Este documento aborda opções de armazenamento em bloco que você pode anexar às instâncias do Compute Engine. Para consultar uma lista completa de opções de armazenamento no Google Cloud Platform, leia Como escolher uma opção de armazenamento.

Comparação de desempenho do armazenamento em bloco

Pense nos requisitos de tamanho e desempenho do armazenamento para ajudar a determinar o tipo e o tamanho corretos de disco para as instâncias. Os requisitos de desempenho para um determinado aplicativo geralmente são divididos em dois padrões distintos de E/S.

  • Leituras e gravações pequenas
  • Leituras e gravações grandes

Para leituras e gravações pequenas, o fator de limitação são operações aleatórias de entrada/saída por segundo (IOPS, na sigla em inglês).

Para leituras e gravações grandes, o fator de limitação é a capacidade (em inglês).

Os números de capacidade e IOPS por GB representam o desempenho agregado total dos dados em um único disco, esteja ele anexado a uma única instância ou dividido entre várias. No caso de várias instâncias que leem a partir do mesmo disco, a capacidade agregada e de IOPS do disco são compartilhados entre as instâncias. Talvez você note um desempenho agregado maior, mas use essas taxas de capacidade e IOPS por GB para fins de planejamento.

Discos
permanentes
padrão por zona
Discos
permanentes
padrão regionais
Discos
permanentes
SSD por zona
Discos
permanentes
SSD regionais
SSD local (SCSI) SSD local (NVMe)
IOPS máximas sustentadas
IOPS de leitura por GB 0,75 0,75 30 30 266,7 453,3
IOPS de gravação por GB 1,5 1,5 30 30 186,7 240
IOPS de leitura por instância 3.000* 3.000* 15.000 – 60.000* 15.000 – 60.000* 400.000 680.000
IOPS de gravação por instância 15.000* 15.000* 15.000 – 30.000* 15.000 – 30.000* 280.000 360.000
Capacidade sustentada máxima (MB/s)
Capacidade de leitura por GB 0,12 0,12 0,48 0,48 1,04 1,77
Capacidade de gravação por GB 0,12 0,12 0,48 0,48 0,73 0,94
Capacidade de leitura por instância 240* 240* 240 – 1.200* 240 – 1.200* 1.560 2.650
Capacidade de gravação por instância 76 – 240** 38 – 200** 76 – 400* 38 – 200* 1.090 1.400

*O desempenho da capacidade e de IOPS do disco permanente depende do número de vCPUs de instância e tamanho de bloco de E/S. Leia os limites de desempenho do disco permanente SSD e do disco permanente padrão para detalhes sobre esses discos.

**Os discos permanentes SSD e padrão alcançam maior desempenho de capacidade em instâncias com mais vCPUs. Leia Limites de saída de rede na capacidade de gravação para mais detalhes.

Como comparar um disco permanente a um disco rígido físico

Ao especificar o tamanho dos discos permanentes, pense em como esses discos se comparam em relação aos discos rígidos físicos tradicionais. As tabelas a seguir comparam os discos permanentes SSD e os padrão quanto ao desempenho típico esperado de uma unidade SATA de 7.200 RPM, que normalmente atinge 75 IOPS ou 120 MB/s.

Tipo de E/S Padrão de E/S Tamanho necessário para atender a uma unidade SATA de 7.200 RPM
Disco permanente padrão Disco permanente SSD
Leituras pequenas aleatórias 75 leituras pequenas aleatórias 100 GB 3 GB
Gravações pequenas aleatórias 75 gravações pequenas aleatórias 50 GB 3 GB
Leituras grandes de streaming Leituras de streaming de 120 MB/s 1.000 GB 250 GB
Gravações grandes de streaming Gravações de streaming de 120 MB/s 1.000 GB 250 GB

Resumo de tamanho, preço e desempenho

Ao selecionar o tipo e o tamanho de um volume para atender à sua necessidade, há vários fatores a serem considerados, menos o preço de uso do volume. Não há custos por E/S no disco permanente. Por isso, não é necessário fazer a estimativa mensal para calcular o orçamento do que será gasto em discos.

Os exemplos de cálculo de preços abaixo usam o sistema de preços de disco permanente dos EUA. Nestes exemplos, pense apenas nos custos relativos aos discos permanentes padrão, em comparação com os discos permanentes SSD. Os discos permanentes padrão custam US$ 0,040 por GB e os persistentes SSD custam US$ 0,170 por GB. No entanto, como os limites aumentam com o tamanho do volume, verifique o preço de cargas de trabalho orientadas a IOPS.

Os discos permanentes padrão têm custos aproximados de US$ 0,053 por IOPS em leitura aleatória e US$ 0,0266 por IOPS em gravação aleatória. Os discos permanentes SSD têm custos de US$ 0,0057 por IOPS em leitura aleatória e US$ 0,0057 por IOPS em gravação aleatória. O preço por IOPS para discos permanentes SSD é válido até o ponto em que eles atingem os limites de IOPS da instância ou a contagem de vCPUs dessa instância.

Os discos permanentes SSD atingem o limite de 60.000 IOPS em leitura aleatória a 2.000 GB e de 30.000 IOPS em gravação aleatória a 1.000 GB. Por outro lado, os discos permanentes padrão atingem o limite de 3.000 IOPS em leitura aleatória a 4 TB e de 15.000 IOPS em gravação aleatória a 10 TB.

Os discos permanentes SSD são projetados para latências de milissegundo com um dígito. A latência observada é específica do aplicativo.

Disco permanente padrão

O desempenho do disco permanente padrão é escalonado de maneira linear até os limites de desempenho da VM. Uma quantidade de quatro ou mais vCPUs na instância não limita o desempenho dos discos permanentes padrão.

Uma quantidade de quatro ou menos vCPUs na instância gera um limite de gravação reduzido, principalmente em termos de IOPS. Isso acontece porque há a restrição por parte dos limites de saída de rede, que são proporcionais à quantidade de vCPUs. O limite de gravação também depende do tamanho de E/S. Por exemplo, uma E/S de 16 KB consome mais largura de banda do que uma de 8 KB no mesmo nível de IOPS.

O desempenho relacionado à capacidade e às IOPS do disco permanente padrão aumentarão de maneira linear com o tamanho do disco até atingirem os limites por instância a seguir:

  • Capacidade de leitura: até 240 MB/s com um tamanho de disco de 2 TB
  • Capacidade de gravação: até 240 MB/s com um tamanho de disco de 2 TB
  • IOPS de leitura: até 3.000 IOPS com um tamanho de disco de 4 TB
  • IOPS de gravação: até 15.000 IOPS com um tamanho de disco de 10 TB

Para conseguir benefícios em termos de desempenho do disco permanente nas instâncias existentes, redimensione os discos permanentes a fim de aumentar as IOPS e a capacidade por disco permanente.

Tamanho do volume (GB) IOPS aleatórias sustentadas Capacidade sustentada (MB/s)
Leitura
(≤ 16 KB por E/S)
Gravação
(≤ 8 KB por E/S)
Gravação
(16 KB por E/S)
Leitura Gravação
10 * * * * *
32 24 48 48 3 3
64 48 96 96 7 7
128 96 192 192 15 15
256 192 384 384 30 30
512 384 768 768 61 61
1.000 750 1.500 1.500 120 120
1.500 1.125 2.250 2.250 180 180
2.048 1.536 3.072 3.072 240 240
4.000 3.000 6.000 6.000 240 240
5.000 3.000 7.500 7.500 240 240
8.192 3.000 12.288 7.500 240 240
10.000 3.000 15.000 7.500 240 240
16.384 3.000 15.000 7.500 240 240
32.768 3.000 15.000 7.500 240 240
65.536 3.000 15.000 7.500 240 240

*Use esse tamanho somente para volumes de inicialização. O bursting de E/S será considerado para todas as tarefas significativas.

Disco permanente SSD

Ao contrário dos discos permanentes padrão, o desempenho das IOPS dos discos permanentes SSD também depende do número de vCPUs na instância além do tamanho do disco.

As VMs de núcleo menor têm limites de capacidade e de IOPS de gravação menores devido às restrições de saída de rede na capacidade de gravação. Consulte a seção Limites de saída de rede na capacidade de gravação para mais detalhes.

O desempenho do disco permanente SSD é escalonado de maneira linear até atingir os limites do volume ou de cada instância do Compute Engine. A largura de banda de leitura de SSD e/ou consistência de IOPS perto dos limites máximos dependem em grande parte da utilização da entrada de rede. Certa variabilidade é esperada, especialmente na E/S de 16 KB perto dos limites máximos de IOPS. Consulte a tabela abaixo para mais detalhes.

Contagem de vCPUs na instância IOPS aleatórias sustentadas Capacidade sustentada (MB/s)
Leitura
(≤ 16 KB por E/S)
Gravação
(≤ 8 KB por E/S)
Gravação
(16 KB por E/S)
Leitura* Gravação
1 vCPU 15.000 9.000 4.500 240 72
De 2 a 3 vCPUs 15.000 15.000 4.500/vCPU 240 72/vCPU
De 4 a 7 vCPUs 15.000 15.000 15.000 240 240
De 8 a 15 vCPUs 15.000 15.000 15.000 800 400
De 16 a 31 vCPUs 25.000 25.000 25.000 1.200 400
De 32 a 63 vCPUs 60.000 30.000 25.000 1.200 400
Mais de 64 vCPUs** 60.000 30.000 25.000 1.200 400

*Capacidade máxima com base em tamanhos de bloco de E/S de 256 KB ou maiores.

**O desempenho máximo pode não ser atingido com a utilização total da CPU.

Para melhorar o desempenho do disco permanente SSD nas instâncias atuais, altere o tipo de máquina da instância para aumentar os limites por VM e redimensione os discos permanentes para aumentar as IOPS e a capacidade por disco permanente.

Tamanho do volume (GB) IOPS aleatórias sustentadas Capacidade sustentada (MB/s)
Leitura
(≤ 16 KB por E/S)
Gravação
(≤ 8 KB por E/S)
Gravação
(16 KB por E/S)
Leitura Gravação
10 300 300 300 4,8 4,8
32 960 960 960 15 15
64 1.920 1.920 1.920 30 30
128 3.840 3.840 3.840 61 61
256 7.680 7.680 7.680 122 122
500 15.000 15.000 15.000 240 240
834 25.000 25.000 25.000 400 400
1.000 30.000 30.000 25.000 480 400
1.334 40.000 30.000 25.000 640 400
1.667 50.000 30.000 25.000 800 400
2.048 60.000 30.000 25.000 983 400
4.096 60.000 30.000 25.000 1.200 400
8.192 60.000 30.000 25.000 1.200 400
16.384 60.000 30.000 25.000 1.200 400
32.768 60.000 30.000 25.000 1.200 400
65.536 60.000 30.000 25.000 1.200 400

Limites de discos C2

Os tipos de máquina otimizados para computação estão sujeitos a limites específicos de disco permanente por vCPU, que são diferentes dos limites de outros tipos de máquina. Veja esses limites na tabela abaixo.

O desempenho por tamanho de volume permanece igual ao descrito nas seções sobre desempenho do disco padrão e do disco SSD.

Disco permanente padrão
Contagem de vCPUs na instância IOPS aleatórias sustentadas Capacidade sustentada (MB/s)
Leitura
(≤ 16 KB por E/S)
Gravação
(≤ 8 KB por E/S)
Gravação
(16 KB por E/S)
Leitura* Gravação
4 vCPUs 3.000 4.000 4.000 240 240
8 vCPUs 3.000 4.000 4.000 240 240
16 vCPUs 3.000 4.000 4.000 240 240
30 vCPUs 3.000 8.000 8.000 240 240
60 vCPUs 3.000 15.000 15.000 240 240
Disco permanente SSD
Contagem de vCPUs na instância IOPS aleatórias sustentadas Capacidade sustentada (MB/s)
Leitura
(≤ 16 KB por E/S)
Gravação
(≤ 8 KB por E/S)
Gravação
(16 KB por E/S)
Leitura* Gravação
4 vCPUs 4.000 4.000 4.000 240 240
8 vCPUs 4.000 4.000 4.000 240 240
16 vCPUs 8.000 4.000 4.000 320 240
30 vCPUs 15.000 8.000 8.000 600 240
60 vCPUs 30.000 15.000 15.000 1.200 400

Leituras e gravações simultâneas

Nos discos permanentes padrão, leituras e gravações simultâneas compartilham os mesmos limites de desempenho. À medida que a instância usa mais IOPS ou capacidade de leitura, ela pode executar menos gravações. As instâncias que usam mais capacidade de gravação podem fazer menos leituras.

Os discos permanentes SSD são capazes de atingir os respectivos limites máximos em termos de capacidade para leituras e gravações simultaneamente. No entanto, para IOPS, os discos permanentes SSD não podem atingir os respectivos limites máximos de leitura e gravação simultaneamente. Para atingir os limites máximos de capacidade durante leituras e gravações simultâneas, otimize o tamanho de E/S de maneira que o volume atenda aos limites de capacidade sem alcançar um gargalo de IOPS.

Limites de IOPS da instância para leituras e gravações simultâneas:

Os números de IOPS na tabela a seguir são baseados em E/S de 8 KB. Outros tamanhos, como 16 KB, podem ter números diferentes de IOPS, mas a mesma distribuição de leitura/gravação.

Disco permanente padrão Disco permanente SSD (8 vCPUs) Disco permanente SSD (mais de 32 vCPUs)
Leitura Gravação Leitura Gravação Leitura Gravação
3.000 IOPS 0 IOPS 15.000 IOPS 0 IOPS 60.000 IOPS 0 IOPS
2.250 IOPS 3.750 IOPS 11.250 IOPS 3.750 IOPS 45.000 IOPS 7.500 IOPS
1.500 IOPS 7.500 IOPS 7.500 IOPS 7.500 IOPS 30.000 IOPS 15.000 IOPS
750 IOPS 11.250 IOPS 3.750 IOPS 11.250 IOPS 15.000 IOPS 22.500 IOPS
0 IOPS 15.000 IOPS 0 IOPS 15.000 IOPS 0 IOPS 30.000 IOPS

Limites de capacidade da instância para leituras e gravações simultâneas:

Disco permanente padrão Disco permanente SSD (8 vCPUs) Disco permanente SSD (mais de 16 vCPUs)
Leitura Gravação Leitura Gravação Leitura Gravação
240 MB/s 0 MB/s 800 MB/s* 400 MB/s* 1.200 MB/s* 400 MB/s*
180 MB/s 60 MB/s
120 MB/s 120 MB/s
60 MB/s 180 MB/s
0 MB/s 240 MB/s

*Nos discos permanentes SSD, a capacidade máxima de leitura e de gravação são independentes entre si. Portanto, esses limites são constantes. Talvez você veja um aumento na capacidade de gravação do disco permanente SSD por instância além dos limites publicados devido à realização de melhorias contínuas.

Limites de saída de rede na capacidade de gravação

Cada operação de gravação do disco permanente contribui para o limite de saída cumulativo de rede da instância da máquina virtual.

Para calcular o tráfego máximo de gravação do disco permanente que uma instância de máquina virtual pode emitir, subtraia o tráfego de saída de outra rede da instância do limite de rede de 2 Gbit/s/vCPU. O restante representa a capacidade disponível para o tráfego de gravação do disco permanente.

O Compute Engine armazena dados em discos permanentes para que eles tenham redundância integrada. As instâncias gravam dados em discos permanentes três vezes em paralelo para alcançar essa redundância. Além disso, cada solicitação de gravação tem uma certa quantidade de sobrecarga, que usa a largura de banda de saída.

Cada instância de máquina virtual tem um limite de gravação de disco permanente com base no limite de saída de rede da máquina virtual. Em uma situação em que o disco permanente esteja competindo pela saída de rede com o tráfego IP, 60% do limite da saída de rede irá para o tráfego de disco persistente, deixando 40% para o tráfego IP. Na tabela a seguir, você vê a estimativa de largura de banda de gravação do disco permanente com tráfego IP extra e sem ele:

Disco permanente padrão Discos permanentes SSD
Número de vCPUs Limite de gravação do disco permanente padrão (MB/s) Alocação de gravação do disco permanente padrão (MB/s) Tamanho do volume padrão obrigatório para atingir o limite (GB) Limite de gravação do disco permanente SSD (MB/s) Alocação de gravação do disco permanente SSD (MB/s) Tamanho do disco permanente SSD obrigatório para atingir o limite (GB)
1 72 43 600 72 43 150
2 144 86 1.200 144 86 300
4 240 173 2000 240 173 500
Mais de 8 240 240 2000 400 346 834

Para entender como os valores dessa tabela foram criados, considere um exemplo simples com uma vCPU e um disco permanente padrão. Nesse exemplo, calculamos que o multiplicador de largura de banda para cada solicitação de gravação é 3,3. Isso significa que os dados são gravados três vezes e têm uma sobrecarga total de 10%. Para calcular o limite de saída, divida por 3,3 o limite de saída de rede, que é 2 Gbit/s ou o equivalente a 238 MB/s:

Largura de banda de gravação máxima para uma vCPU = 238 / 3,3 = aproximadamente 72 MB/s para seu disco permanente padrão

Além disso, ao usar o valor da capacidade/GB de gravação do disco permanente padrão fornecido no gráfico de desempenho mostrado anteriormente, é possível derivar a capacidade de disco necessária para alcançar esse desempenho:

Capacidade de disco necessária para alcançar a largura de banda de gravação máxima para uma vCPU = 72 / 0,12 = aproximadamente 600 GB

Assim como os discos permanentes zonais, o tráfego de gravação de discos permanentes regionais contribui para um limite cumulativo da saída de rede na instância de máquina virtual. Para calcular a rede de saída disponível para discos permanentes regionais, use o fator 6,6 em vez de 3,3, que é usado nos discos permanentes zonais.

Largura de banda de gravação máxima para uma vCPU = 238 / 6,6 = aproximadamente 36 MB/s para seu disco permanente padrão replicado

Como otimizar o desempenho do disco permanente e do SSD local

Você pode otimizar discos permanentes e SSDs locais para processar os dados de maneira mais eficiente.

Como otimizar discos permanentes

Os discos permanentes podem proporcionar o desempenho descrito no gráfico do tipo de disco, mas a máquina virtual precisa destinar uso suficiente para atingir os limites de desempenho. Depois de dimensionar os volumes de disco permanente da maneira apropriada às necessidades de desempenho, o aplicativo e o sistema operacional podem precisar de alguns ajustes.

Nesta seção, descrevemos alguns elementos-chave que podem ser ajustados tendo em vista um desempenho melhor e, em seguida, abordamos como aplicar alguns deles a tipos específicos de cargas de trabalho.

Como desativar a inicialização lenta e ativar comandos DISCARD

Os discos permanentes dão suporte a comandos DISCARD ou TRIM, que permitem aos sistemas operacionais informar os discos quando os blocos deixam de ser usados. O suporte a DISCARD permite ao sistema operacional marcar blocos do disco como não sendo mais necessários sem incorrer no custo de zerar os blocos.

Na maioria dos sistemas operacionais Linux, DISCARD é ativado quando você ativa um disco permanente na instância. As instâncias do Windows 2012 R2 ativam DISCARD por padrão quando você ativa um disco permanente. O Windows 2008 R2 não é compatível com DISCARD.

Ativar DISCARD pode melhorar o desempenho geral do tempo de execução, além de acelerar o desempenho do disco quando ele é ativado pela primeira vez. Formatar um volume de disco inteiro pode ser demorado. Assim, a chamada "formatação preguiçosa" é uma prática comum. A desvantagem da formatação preguiçosa é que o custo é frequentemente pago na primeira vez em que o volume é ativado. Ao desativar a inicialização lenta e ativar os comandos DISCARD, é possível conseguir formatação e ativação rápidas.

  • Desative a inicialização lenta e ative DISCARD durante a formatação passando os seguintes parâmetros para mkfs.ext4:

    -E lazy_itable_init=0,lazy_journal_init=0,discard
    

    O parâmetro lazy_journal_init=0 não funciona em instâncias com imagens do CentOS 6 ou do RHEL 6. Para essas instâncias, formate os discos permanentes sem esse parâmetro.

    -E lazy_itable_init=0,discard
    
  • Habilite comandos DISCARD na ativação. Transmita a sinalização a seguir para o comando de ativação:

    -o discard
    

Os discos permanentes funcionam bem com a opção discard ativa. No entanto, como alternativa, é possível executar fstrim periodicamente em vez da opção discard ou como complemento dela. Se você não usar discard, execute fstrim antes de criar um snapshot do seu disco. Ao cortar o sistema de arquivos, é possível criar imagens de snapshot menores, o que reduz o custo do armazenamento de snapshots.

Profundidade da fila de E/S

Muitos aplicativos têm configurações que influenciam a profundidade da fila de E/S para ajustar o desempenho. Profundidades de fila mais altas aumentam as IOPS, mas também podem aumentar a latência. Profundidades de fila menores diminuem a latência por E/S, às vezes, às custas de IOPS.

Cache de leitura à frente

Para melhorar o desempenho de E/S, os sistemas operacionais empregam técnicas como readahead (em inglês), também chamada de "leitura à frente", em que é lido mais do que solicitado de um arquivo nessa memória, supondo que leituras posteriores provavelmente precisarão desses dados. O readahead maior aumenta a capacidade, mas às custas da memória e IOPS. Já o readahead menor aumenta as IOPS, mas às custas da capacidade.

Em sistemas Linux, é possível receber e configurar o valor de readahead com o comando blockdev:

$ sudo blockdev --getra /dev/[DEVICE_ID]
$ sudo blockdev --setra [VALUE] /dev/[DEVICE_ID]

O valor de readahead é <desired_readahead_bytes> / 512 bytes.

Por exemplo, para um valor de readahead de 8 MB, 8 MB são 8.388.608 bytes (8 * 1024 * 1024).

8388608 bytes / 512 bytes = 16384

Configure desta forma:

$ sudo blockdev --setra 16384 /dev/[DEVICE_ID]

CPUs gratuitas

No disco permanente, a leitura e a gravação requerem ciclos de CPU da máquina virtual. Alcançar níveis de IOPS muito altos e consistentes exige CPUs livres para processar a E/S.

Cargas de trabalho orientadas a IOPS

Bancos de dados SQL ou NoSQL têm padrões de uso de acesso aleatório aos dados. Os itens abaixo são sugeridos para cargas de trabalho orientadas a IOPS:

  • Os valores mais baixos de readahead geralmente são sugeridos em documentos de práticas recomendadas do MongoDB, Apache Cassandra (páginas em inglês) e outros aplicativos de banco de dados.

  • Valores de profundidade da fila de E/S de 1 para cada 400 a 800 IOPS até o limite de 64 em grandes volumes.

  • Uma CPU livre para cada 2.000 IOPS de leitura aleatória e para cada 2.500 IOPS de gravação aleatória.

Cargas de trabalho orientadas à capacidade

Leituras sequenciais rápidas são excelentes para operações de streaming, como um job do Hadoop. Dessa forma, tamanhos de E/S maiores podem aumentar o desempenho do streaming. Para as cargas de trabalho orientadas à capacidade, os tamanhos de E/S de 256 KB ou maiores são recomendados.

Como otimizar o desempenho do disco permanente SSD

O gráfico de desempenho por tipo de disco descreve os limites de desempenho atingíveis esperados para discos permanentes em estado sólido. Para otimizar os aplicativos e as instâncias de máquina virtual para atingir essas velocidades, use as seguintes práticas recomendadas:

  • Verifique se o aplicativo está emitindo E/S suficiente

    Se o aplicativo estiver emitindo menos IOPS que o limite descrito na tabela acima, você não atingirá aquele nível de IOPS. Por exemplo, em um disco de 500 GB, o limite esperado de IOPS é de 15.000. No entanto, se você emitir menos que isso ou emitir operações de E/S maiores que 8 KB, não atingirá 15.000 IOPS.

  • Certifique-se de emitir E/S com paralelismo suficiente

    Use uma profundidade de fila alta o suficiente para aproveitar o paralelismo do sistema operacional. Se você emitir 1.000 IOPS, mas de forma síncrona com uma profundidade de fila de 1, atingirá muito menos IOPS do que o limite descrito na tabela. No mínimo, o aplicativo precisa ter uma profundidade de fila de pelo menos 1 para cada 400-800 IOPS.

  • Certifique-se de haver CPU suficiente disponível na instância da máquina virtual emitindo a E/S

    Se a instância da máquina virtual tiver pouca CPU, o aplicativo não conseguirá as IOPS descritas acima. Como regra geral, você precisa ter uma CPU disponível para cada 2.000-2.500 IOPS de tráfego esperado.

  • Verifique se o aplicativo está otimizado para uma localidade razoável de dados temporais em discos grandes

    Se o aplicativo acessar dados distribuídos em partes diferentes de um disco em um período curto (centenas de GB por vCPU), você não atingirá o número ideal de IOPS. Para conseguir um melhor desempenho, otimize para a localidade de dados temporais, ponderando fatores como fragmentação do disco e aleatoriedade das partes acessadas do disco.

  • Verifique se de o programador de E/S no sistema operacional está configurado para atender às necessidades específicas

    Em sistemas baseados em Linux, é possível configurar o programador de E/S como noop para atingir o maior número de IOPS em dispositivos com SSD.

Comparativo de mercado sobre o desempenho do disco permanente SSD

Os comandos abaixo têm como base um dispositivo PD-SSD de 2.500 GB. Se o tamanho do dispositivo for diferente, modifique o argumento --filesize. Esse tamanho de disco é necessário para atingir os atuais limites de capacidade da VM de 32 vCPUs.

    # Install dependencies
    sudo apt-get update
    sudo apt-get install -y fio
  1. Preencha o disco com dados diferentes de zero. As leituras de disco permanentes em blocos vazios têm um perfil de latência diferente dos que contêm dados. Recomendamos que você preencha o disco antes de executar qualquer comparação de latência de leitura.

    # Running this command will cause you to lose data on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=fill_disk \
      --filename=/dev/sdb --filesize=2500G \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=128K --iodepth=64 --rw=randwrite
    
  2. Teste a largura de banda de gravação usando gravações sequenciais com vários streams paralelos (mais de oito). Eles têm 1 MB como tamanho de E/S e profundidade de E/S igual ou superior a 64.

    # Running this command will cause you to lose data on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=1M --iodepth=64 --rw=write --numjobs=8
    
  3. Teste as IOPS de gravação. Para atingir o limite de IOPS do DP, é importante manter uma fila profunda de E/S. Por exemplo, quando a latência de gravação for de 1 milissegundo, a VM poderá ter no máximo 1.000 IOPS para cada E/S em andamento. Para atingir 15.000 IOPS, a VM terá que manter pelo menos 15 E/S em andamento. Para que o disco e a VM alcancem 30.000 IOPS, o número de E/S em andamento terá que ser pelo menos 30. Quando o tamanho de E/S for maior do que 4 KB, a VM poderá atingir o limite de largura de banda antes de alcançar o de IOPS.

    # Running this command will cause you to lose data on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_iops_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=64 --rw=randwrite
    
  4. Teste a latência de gravação. Ao testar a latência de E/S, é importante que a VM não atinja o limite de largura de banda ou de IOPS. Caso contrário, a latência de E/S real do disco permanente não será refletida. Por exemplo, quando o limite de IOPS for atingido em uma profundidade de 30 para E/S, e o comando "fio" tiver o dobro disso, o total de IOPS permanecerá o mesmo, e a latência de E/S relatada será duplicada.

    # Running this command will cause you to lose data on the second device.
    # We strongly recommend using a throwaway VM and disk.
    sudo fio --name=write_latency_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=4 --rw=randwrite
    
  5. Teste a largura de banda de leitura usando leituras sequenciais com vários streams paralelos (mais de oito). Eles têm 1 MB como tamanho de E/S e profundidade de E/S igual ou superior a 64.

    sudo fio --name=read_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=1M --iodepth=64 --rw=read --numjobs=8
    
  6. Teste as IOPS de leitura. Para atingir o limite de IOPS do DP, é importante manter uma fila de E/S com profundidade suficiente. Quando o tamanho de E/S for maior do que 4 KB, a VM poderá atingir o limite de largura de banda antes de alcançar o de IOPS.

    sudo fio --name=read_iops_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=64 --rw=randread
    
  7. Teste a latência de leitura. É importante preencher o disco com dados para receber uma medição de latência realista. Também é importante que a VM não atinja os limites de IOPS ou de capacidade durante esse teste. Quando o disco permanente atinge o limite de saturação, as E/S recebidas são recuadas e isso é refletido como um aumento artificial na latência de E/S.

    sudo fio --name=read_latency_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --bs=4K --iodepth=4 --rw=randread
    
  8. Teste a largura de banda de leitura sequencial.

    sudo fio --name=read_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --numjobs=4 --thread --offset_increment=500G \
      --bs=1M --iodepth=64 --rw=read
    
  9. Teste a largura de banda de gravação sequencial.

    sudo fio --name=write_bandwidth_test \
      --filename=/dev/sdb --filesize=2500G \
      --time_based --ramp_time=2s --runtime=1m \
      --ioengine=libaio --direct=1 --verify=0 --randrepeat=0 \
      --numjobs=4 --thread --offset_increment=500G \
      --bs=1M --iodepth=64 --rw=write
    

Como otimizar SSDs locais

O gráfico de desempenho por tipo de disco descreve os limites de desempenho atingíveis esperados para dispositivos SSD locais. Para otimizar os aplicativos e as instâncias de máquina virtual e atingir essas velocidades, siga as práticas recomendadas a seguir:

Usar as otimizações do ambiente de convidado para SSD local

Por padrão, a maioria das imagens Linux fornecidas pelo Compute Engine executa automaticamente um script de otimização que configura a instância para garantir o desempenho máximo de SSD local. O script também ativa determinadas configurações de arquivos sysfs de fila, o que melhora o desempenho geral da máquina e mascara solicitações de interrupção (IRQs, na sigla em inglês) para CPUs virtuais (vCPUs, na sigla em inglês) específicas (ambos os links em inglês). Esse script otimiza apenas o desempenho dos dispositivos SSD locais do Compute Engine.

Ubuntu, SLES e imagens mais antigas talvez não estejam configurados para incluir essa otimização de desempenho. Se você usa qualquer uma dessas imagens ou uma mais antiga que v20141218, é possível instalar o ambiente de convidado para ativar essas otimizações.

Selecionar a melhor imagem para interfaces NVMe ou SCSI

Os SSDs locais funcionam melhor com o tipo de interface NVMe ou SCSI, dependendo da imagem usada no disco de inicialização da sua instância. Escolha uma interface para os dispositivos SSD locais que funcione melhor com a imagem do disco de inicialização. Caso as suas instâncias se conectem a SSDs locais usando interfaces SCSI, ative o SCSI multifilas no sistema operacional convidado, para melhorar o desempenho na interface do SCSI.

Ativar o SCSI multifilas em instâncias com imagens personalizadas e SSDs locais

Algumas imagens públicas são compatíveis com o SCSI multifilas. Caso precise de recursos SCSI multifilas em imagens personalizadas importadas para seu projeto, você terá de ativá-las por conta própria. Suas imagens importadas do Linux usam SCSI multifilas somente quando elas incluem a versão 3.19 ou posterior do kernel.

Para ativar o SCSI multifilas em uma imagem personalizada, importe a imagem com o recurso do sistema operacional de convidado VIRTIO_SCSI_MULTIQUEUE ativado e inclua uma entrada na configuração do GRUB:

CentOS

Apenas para o CentOS7.

  1. Importe a imagem personalizada usando a API e inclua um item guestOsFeatures com um valor type de VIRTIO_SCSI_MULTIQUEUE.

  2. Crie uma instância usando sua imagem personalizada e anexe um ou mais SSDs locais.

  3. Conecte-se à instância pelo SSH.

  4. Verifique o valor do arquivo /sys/module/scsi_mod/parameters/use_blk_mq.

    $ cat /sys/module/scsi_mod/parameters/use_blk_mq
    

    Se o valor desse arquivo for Y, o SCSI multifilas já estará ativado na imagem importada. Se o valor for N, inclua scsi_mod.use_blk_mq=Y na entrada GRUB_CMDLINE_LINUX do arquivo de configuração GRUB e reinicie o sistema.

    1. Abra o arquivo de configuração GRUB /etc/default/grub em um editor de texto.

      $ sudo vi /etc/default/grub
      
    2. Adicione scsi_mod.use_blk_mq=Y à entrada GRUB_CMDLINE_LINUX.

      GRUB_CMDLINE_LINUX=" vconsole.keymap=us console=ttyS0,38400n8 vconsole.font=latarcyrheb-sun16 scsi_mod.use_blk_mq=Y"
      
    3. Salve o arquivo de configuração.

    4. Execute o comando grub2-mkconfig para regenerar o arquivo GRUB e concluir a configuração.

      $ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
      
    5. Reinicie a instância.

      $ sudo reboot
      

Ubuntu

  1. Importe a imagem personalizada usando a API e inclua um item guestOsFeatures com um valor type de VIRTIO_SCSI_MULTIQUEUE.

  2. Crie uma instância usando a imagem personalizada e anexe um ou mais SSDs locais usando a interface SCSI.

  3. Conecte-se à instância pelo SSH.

  4. Verifique o valor do arquivo /sys/module/scsi_mod/parameters/use_blk_mq.

    $ cat /sys/module/scsi_mod/parameters/use_blk_mq
    

    Se o valor desse arquivo for Y, o SCSI multifilas já estará ativado na imagem importada. Se o valor for N, inclua scsi_mod.use_blk_mq=Y na entrada GRUB_CMDLINE_LINUX do arquivo de configuração GRUB e reinicie o sistema.

    1. Abra o arquivo de configuração GRUB sudo nano /etc/default/grub em um editor de texto.

      $ sudo nano /etc/default/grub
      
    2. Adicione scsi_mod.use_blk_mq=Y à entrada GRUB_CMDLINE_LINUX.

      GRUB_CMDLINE_LINUX="scsi_mod.use_blk_mq=Y"
      
    3. Salve o arquivo de configuração.

    4. Execute o comando update-grub para gerar novamente o arquivo GRUB e concluir a configuração.

      $ sudo update-grub
      
    5. Reinicie a instância.

      $ sudo reboot
      

Desativar a limpeza do cache de gravação

Os sistemas de arquivos, bancos de dados e outros aplicativos usam a limpeza de cache (em inglês) para garantir que os dados sejam confirmados para armazenamento durável em diversos checkpoints. Para a maioria dos dispositivos de armazenamento, esse padrão faz sentido. No entanto, as limpezas do cache de gravação são muito lentas em SSDs locais. Você pode melhorar o desempenho de gravação para alguns aplicativos desativando comandos de limpeza automática nesses aplicativos ou opções de limpeza no nível do sistema de arquivos.

Os SSDs locais sempre limpam gravações em cache dentro de dois segundos, independentemente dos comandos de limpeza que você definiu para os sistemas de arquivos e os aplicativos. Dessa forma, as falhas de hardware temporárias podem fazer você perder, no máximo, apenas dois segundos de gravações armazenados em cache. As falhas de hardware permanentes ainda podem causar perda de todos os dados no dispositivo, mesmo que eles sejam limpos. Por isso, faça o backup de dados importantes para os discos permanentes ou intervalos do Cloud Storage.

Para desativar a limpeza do cache de gravação em sistemas de arquivos ext4, inclua nobarrier nas opções de ativação ou nas entradas de /etc/fstab. Por exemplo:

$ sudo mount -o discard,defaults,nobarrier /dev/[LOCAL_SSD_ID] /mnt/disks/[MNT_DIR]

[LOCAL_SSD_ID] é o ID do dispositivo do SSD local que quer ativar.

Como comparar o desempenho do SSD local

Os valores de desempenho do SSD local fornecidos na seção Desempenho foram conseguidos usando-se configurações específicas na instância do SSD local. Se a instância estiver enfrentando problemas para atingir esses limites de desempenho e você já tiver configurado a instância usando as configurações do SSD local recomendadas, compare os limites de desempenho com os limites publicados replicando as configurações usadas pela equipe do Compute Engine.

  1. Crie uma instância de SSD local que tenha quatro ou oito vCPUs para cada dispositivo, dependendo da carga de trabalho. Por exemplo, para anexar quatro dispositivos SSD locais a uma instância, use um tipo de máquina com 16 ou 32 vCPUs.

    O comando abaixo cria uma máquina virtual com oito vCPUs e um único SSD local:

    gcloud compute instances create ssd-test-instance \
    --machine-type "n1-standard-8" \
    --local-ssd interface="SCSI"
    
  2. Execute o script a seguir na máquina, que replica as configurações usadas para atingir essas velocidades. O parâmetro --bs define o tamanho do bloco, o que afeta os resultados para diferentes tipos de operações de leitura e gravação.

    # install dependencies
    sudo apt-get update -y
    sudo apt-get install -y build-essential git libtool gettext autoconf \
    libgconf2-dev libncurses5-dev python-dev fio bison autopoint
    
    # blkdiscard
    git clone https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git
    cd util-linux/
    ./autogen.sh
    ./configure --disable-libblkid
    make
    sudo mv blkdiscard /usr/bin/
    sudo blkdiscard /dev/disk/by-id/google-local-ssd-0
    
    # full write pass - measures write bandwidth with 1M blocksize
    sudo fio --name=writefile --size=100G --filesize=100G \
    --filename=/dev/disk/by-id/google-local-ssd-0 --bs=1M --nrfiles=1 \
    --direct=1 --sync=0 --randrepeat=0 --rw=write --refill_buffers --end_fsync=1 \
    --iodepth=200 --ioengine=libaio
    
    # rand read - measures max read IOPS with 4k blocks
    sudo fio --time_based --name=benchmark --size=100G --runtime=30 \
    --filename=/dev/disk/by-id/google-local-ssd-0 --ioengine=libaio --randrepeat=0 \
    --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 \
    --numjobs=4 --rw=randread --blocksize=4k --group_reporting
    
    # rand write - measures max write IOPS with 4k blocks
    sudo fio --time_based --name=benchmark --size=100G --runtime=30 \
    --filename=/dev/disk/by-id/google-local-ssd-0 --ioengine=libaio --randrepeat=0 \
    --iodepth=128 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 \
    --numjobs=4 --rw=randwrite --blocksize=4k --group_reporting
    

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Compute Engine