Como otimizar o desempenho do disco permanente e do SSD local

Discos permanentes são a opção de armazenamento mais comum por questões de preço, desempenho e durabilidade. Também é possível escolher SSDs locais, que oferecem desempenho ainda mais alto e menor latência, mas não são redundantes e existem apenas durante a vida útil de uma instância específica. Ao configurar uma opção de armazenamento para aplicativos executados nas instâncias, use os seguintes processos:

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

Nas seções a seguir, descrevemos as opções disponíveis de armazenamento em blocos que podem ser anexadas às instâncias do Compute Engine. Para ver uma lista completa das opções de armazenamento no Google Cloud Platform, consulte Produtos do Cloud Storage.

Comparação de desempenho do armazenamento em blocos

Para ajudar a determinar o tipo e tamanho de disco corretos para suas instâncias, considere o tamanho do armazenamento e os requisitos de desempenho. 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 fragmentado entre várias. No caso de várias instâncias que leem do mesmo disco, as capacidades agregada e de IOPS do disco são compartilhadas entre as instâncias. Para fins de planejamento, recomendamos o uso dos seguintes IOPS por GB e taxas de capacidade:

Discos permanentes
padrão
zonais
Discos
permanentes
padrão regionais
Discos
permanentes
SSD zonais
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. Nas tabelas a seguir, veja a comparação entre discos permanentes SSD e 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 7200 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

Quando você seleciona o tipo e o tamanho de um volume para seu app, há vários fatores a serem considerados, menos o preço de uso do volume. Como não há custos por E/S no disco permanente, não é necessário fazer a estimativa mensal para calcular o orçamento do que será gasto em discos. No entanto, para cargas de trabalho orientadas para IOPS, é possível detalhar o custo por mês para analisar o preço por IOPS, para fins de comparação.

Nos exemplos de cálculo de preços abaixo, usamos o sistema de preços de disco permanente dos EUA. Neles, pense 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 discos permanentes SSD custam US$ 0,170 por GB. Ao aumentar o tamanho de um volume, você também aumenta os limites de desempenho automaticamente, sem nenhum custo extra.

Para determinar o custo por IOPS de um disco permanente, divida o preço por GB por mês pelo número de IOPS por GB. Na tabela a seguir, veja o cálculo do preço por IOPS de leitura aleatória por GB. Use os mesmos cálculos para calcular também o preço por IOPS de gravação.

Tipo de disco Preço por GB/mês IOPS de leitura por GB Preço por IOPS por GB
Disco permanente padrão US$ 0,040 0,75 US$ 0,040 / 0,75 = US$ 0,0533
Disco permanente SSD US$ 0,170 30 US$ 0,170 / 30 = US$ 0,2267

Os discos permanentes SSD atingem os limites de 60.000 IOPS de leitura aleatória a 2.000 GB e 30.000 IOPS de gravação aleatória a 1.000 GB. Por outro lado, os discos permanentes padrão atingem os limites de 3.000 IOPS em leitura aleatória a 4 TB e 15.000 IOPS de 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 app.

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 reduz o limite de gravação de IOPS porque os limites de saída da rede 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 a capacidade e IOPS do disco permanente padrão aumentam 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 atuais, 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 fornece um desempenho mais alto para volumes de inicialização do que o escalonamento linear descrito aqui.

Disco permanente SSD

O desempenho de IOPS dos discos permanentes SSD depende do número de vCPUs na instância e 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. Para mais informações, consulte Limites de saída de rede na capacidade de gravação.

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 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.

Quantidade 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 blocos 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 com otimização de 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 nas tabelas a seguir.

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

Disco permanente padrão
Quantidade 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
Quantidade 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. Enquanto a instância estiver usando mais capacidade de leitura ou IOPS, ela poderá executar menos gravações. Por outro lado, as instâncias que executam mais capacidade de gravação são capazes de 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, esse não é o caso das IOPS, isto é, os discos permanentes SSD não conseguem atingir os limites máximos de leitura e gravação simultaneamente. Para atingir os limites máximos de capacidade de 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 de 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 de E/S, 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 de 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 de rede cumulativo da instância da máquina virtual (VM, na sigla em inglês).

Para calcular o tráfego máximo de gravação do disco permanente que uma instância de VM 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.

Os discos permanentes do Compute Engine oferecem 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 tem um limite de gravação de disco permanente com base no limite de saída da rede da VM. 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 vai para o tráfego de disco permanente, 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 permanente de estado sólido
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 2.000 240 173 500
Mais de 8 240 240 2.000 400 346 834

Para entender como os valores dessa tabela foram calculados, considere um exemplo 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,3x. 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 o disco permanente padrão

Quando você usa a capacidade por 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 VM. Para calcular a saída de rede disponível para discos permanentes regionais, use o fator 6,6.

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

Como otimizar o desempenho do disco permanente e do SSD local

É possível otimizar discos permanentes e SSDs locais para processar os dados de maneira mais eficiente.

Como otimizar discos permanentes

Os discos permanentes poderão proporcionar o desempenho descrito no gráfico do tipo de disco se a VM impulsionar o uso suficiente para atingir os limites de desempenho. Após o dimensionamento dos volumes de disco permanente para atender às necessidades de desempenho, o app e o sistema operacional poderão precisar de algum ajuste.

Nas seções a seguir, descrevemos alguns elementos principais que podem ser ajustados para melhorar o desempenho e como aplicar alguns deles a tipos específicos de cargas de trabalho.

Desativar a inicialização lenta e ativar comandos DISCARD

Os discos permanentes aceitam comandos DISCARD ou TRIM, que permitem aos sistemas operacionais informar os discos quando os blocos deixam de ser usados. A compatibilidade com DISCARD permite ao SO marcar blocos de 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 ambiente de execução, além de acelerar o desempenho do disco quando ele é ativado pela primeira vez. A formatação de um volume de disco inteiro pode ser demorada, portanto, a "formatação lenta" é uma prática comum. A desvantagem da formatação lenta é 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
    
  • Para ativar comandos DISCARD na ativação, passe a sinalização a seguir ao 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. O corte do sistema de arquivos permite 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 afetam a profundidade da fila de E/S. 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, mas podem resultar em IOPS máximas mais baixas.

Cache de leitura antecipada

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

Em sistemas Linux, é possível receber e definir 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, no caso de um readahead de 8 MB, 8 MB equivalem a 8.388.608 bytes (8 * 1024 * 1024).

8388608 bytes / 512 bytes = 16384

Defina blockdev como 16384:

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

CPUs gratuitas

No disco permanente, a leitura e a gravação requerem ciclos de CPU da VM. Para atingir níveis de IOPS mais altos e consistentes, as CPUs precisam estar livres para processar 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. O Google recomenda os seguintes valores para cargas de trabalho orientadas a IOPS:

  • 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.

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.

Cargas de trabalho orientadas à capacidade

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

Como otimizar o desempenho do disco permanente SSD

No gráfico de desempenho por tipo de disco veja a descrição dos limites de desempenho atingíveis esperados para discos permanentes de estado sólido. Para otimizar os apps e as instâncias de VM visando atingir essas velocidades, use as seguintes práticas recomendadas:

  • Verifique se o app está gerando E/S suficiente

    Se o app estiver gerando menos IOPS do que o limite descrito no gráfico anterior, esse nível de IOPS não será alcançado. Por exemplo, em um disco de 500 GB, o limite de IOPS esperado é de 15.000 IOPS. No entanto, se você gerar menos IOPS ou as operações de E/S forem maiores que 8 KB, não será possível alcançar 15.000 IOPS.

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

    Use uma profundidade de fila alta o suficiente para aproveitar o paralelismo do sistema operacional. Se você fornecer 1.000 IOPS, mas fizer isso de maneira síncrona com uma profundidade de fila de 1, serão alcançadas muito menos IOPS do que o limite descrito no gráfico. No mínimo, o app precisa ter uma profundidade de fila de pelo menos 1 para cada 400-800 IOPS.

  • Verifique se há CPU disponível suficiente na instância que está gerando a E/S

    Se a instância de VM tiver pouca CPU, o app não conseguirá gerenciar as IOPS descritas acima. Recomendamos que você tenha uma CPU disponível para cada 2.000–2.500 IOPS de tráfego esperado.

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

    Se o app 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 o programador de E/S no SO está configurado para suas necessidades específicas

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

Como comparar o desempenho do disco permanente SSD

Os comandos a seguir presumem um dispositivo PD-SSD de 2.500 GB. Se o tamanho do dispositivo for diferente, modifique o valor do argumento --filesize. Esse tamanho de disco é necessário para atingir os 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 permanente 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 causes data loss 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 causes data loss 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 --offset_increment=100G
    
  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 trânsito. Para atingir 15.000 IOPS, a VM terá que manter pelo menos 15 E/S em trânsito. Para que o disco e a VM alcancem 30.000 IOPS, o número de E/S em trânsito 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 causes data loss 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. Durante o teste da 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 causes data loss 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 realizando leituras sequenciais com vários streams paralelos (mais de oito), usando 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 --offset_increment=100G
    
  6. Teste as IOPS de leitura. Para atingir o limite de IOPS do DP, é importante manter uma fila profunda de E/S. 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. É importante que a VM não atinja os limites de IOPS ou de capacidade durante este teste, porque após o disco permanente atingir o limite de saturação, ele retornará as E/Ss recebidas, o que se refletirá 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

No gráfico de desempenho por tipo de disco, veja os limites de desempenho atingíveis esperados para dispositivos SSD locais. Para otimizar os apps e as instâncias de VM visando atingir essas velocidades, use as seguintes práticas recomendadas:

Como usar otimizações do ambiente convidado para SSDs locais

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 que melhoram o desempenho geral da máquina e mascaram 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.

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

Selecionar a melhor imagem para interfaces NVMe ou SCSI

Os SSDs locais expõem uma interface NVMe ou SCSI, e a melhor opção depende do sistema operacional que você está usando. 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 type de valor 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 type de valor 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 apps 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. É possível melhorar o desempenho de gravação para alguns apps desativando comandos de limpeza automática neles 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 apps. 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 permanentes de hardware ainda podem causar perda de todos os dados no dispositivo, mesmo que eles sejam limpos. Por isso, faça o backup de dados importantes em discos permanentes ou intervalos do Cloud Storage.

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

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

em que [LOCAL_SSD_ID] é o ID de dispositivo do SSD local que você quer ativar e [MNT_DIR] é o diretório em que será ativado.

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 recomendadas de SSD local, 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 VM. Ele replica as configurações usadas para atingir os valores de desempenho do SSD fornecidos na seção Desempenho. O parâmetro --bs define o tamanho do bloco, o que afeta os resultados de 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