Por que meu NVMe é mais lento que um SSD?

Neste artigo, veremos algumas nuances do subsistema de E/S e seu impacto no desempenho.

Algumas semanas atrás, me deparei com a questão de por que o NVMe em um servidor é mais lento do que o SATA em outro. Observei as características dos servidores e percebi que era uma pegadinha: NVMe era do segmento de usuários e SSD era do segmento de servidores.

Obviamente não é correto comparar produtos de diferentes segmentos em diferentes ambientes, mas esta não é uma resposta técnica exaustiva. Estudaremos o básico, realizaremos experimentos e daremos uma resposta à questão colocada.

O que é fsync e onde é usado

Para agilizar o trabalho com as unidades, os dados são armazenados em buffer, ou seja, armazenados em memória volátil até que surja uma oportunidade conveniente para salvar o conteúdo do buffer na unidade. Os critérios de oportunidade são determinados pelo sistema operacional e pelas características da unidade. No caso de uma falha de energia, todos os dados no buffer serão perdidos.

Há uma série de tarefas nas quais você precisa ter certeza de que as alterações no arquivo foram gravadas na unidade e não em um buffer intermediário. Essa garantia pode ser obtida usando a chamada de sistema fsync compatível com POSIX. A chamada fsync força uma gravação do buffer na unidade.

Vamos demonstrar o efeito dos buffers com um exemplo artificial na forma de um programa C curto.

#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>

int main(void) {
    /* Открываем файл answer.txt на запись, если его нет -- создаём */
    int fd = open("answer.txt", O_WRONLY | O_CREAT);
    /* Записываем первый набор данных */
    write(fd, "Answer to the Ultimate Question of Life, The Universe, and Everything: ", 71);
    /* Делаем вид, что проводим вычисления в течение 10 секунд */
    sleep(10);
    /* Записываем результат вычислений */
    write(fd, "42n", 3); 

    return 0;
}

Os comentários explicam bem a sequência de ações do programa. O texto “a resposta à questão principal da vida, do universo e tudo mais” será armazenado em buffer pelo sistema operacional, e se você reiniciar o servidor pressionando o botão Reset durante os “cálculos”, o arquivo ficará vazio. Em nosso exemplo, a perda de texto não é um problema, portanto o fsync não é necessário. Os bancos de dados não compartilham desse otimismo.

Bancos de dados são programas complexos que trabalham com muitos arquivos ao mesmo tempo, por isso querem ter certeza de que os dados que gravam serão armazenados no drive, pois disso depende a consistência dos dados dentro do banco de dados. Os bancos de dados são projetados para registrar todas as transações concluídas e estar prontos para uma queda de energia a qualquer momento. Este comportamento obriga você a usar fsync constantemente em grandes quantidades.

O que afeta o uso frequente de fsync

Com E/S normal, o sistema operacional tenta otimizar a comunicação do disco, uma vez que as unidades externas são as mais lentas na hierarquia de memória. Portanto, o sistema operacional tenta gravar o máximo de dados possível em um acesso à unidade.

Vamos demonstrar o impacto do uso do fsync com um exemplo específico. Temos os seguintes SSDs como cobaias:

• SSD Intel® DC S4500 480 GB, conectado via SATA 3.2, 6 Gb/s;
• Samsung 970 EVO Plus 500 GB, conectado via PCIe 3.0 x4, ~31 Gbps.

Os testes são realizados em um Intel® Xeon® W-2255 executando Ubuntu 20.04. Para testar discos, é usado o sysbench 1.0.18. Os discos possuem uma única partição formatada como ext4. A preparação para o teste é criar arquivos de 100 GB:

sysbench --test=fileio --file-total-size=100G prepare

Executando testes:

# Без fsync
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=0 run

# С fsync после каждой записи
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=1 run

Os resultados do teste são apresentados na tabela.

Teste
Intel® S4500
Samsung 970 EVO+

Leia sem fsync, MiB/s
5734.89
9028.86

Escreva sem fsync, MiB/s
3823.26
6019.24

Lendo com fsync, MiB/s
37.76
3.27

Gravando com fsync, MiB/s
25.17
2.18

É fácil ver que o NVMe do segmento cliente lidera com segurança quando o sistema operacional decide como trabalhar com discos e perde quando o fsync é usado. Isso levanta duas questões:

1. Por que a velocidade de leitura excede a largura de banda física do link no teste sem fsync?
2. Por que um SSD de segmento de servidor é melhor para lidar com um grande número de solicitações fsync?

A resposta à primeira pergunta é simples: o sysbench gera arquivos preenchidos com zero. Assim, o teste foi realizado em mais de 100 gigabytes de zeros. Como os dados são muito uniformes e previsíveis, várias otimizações do sistema operacional entram em ação e aceleram significativamente a execução.

Se você questionar todos os resultados do sysbench, poderá usar o fio.

# Без fsync
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=0 --filename=/dev/sdb

# С fsync после каждой записи
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=1 --filename=/dev/sdb

Teste
Intel® S4500
Samsung 970 EVO+

Leia sem fsync, MiB/s
45.5
178

Escreva sem fsync, MiB/s
30.4
119

Lendo com fsync, MiB/s
32.6
20.9

Gravando com fsync, MiB/s
21.7
13.9

A tendência de queda de desempenho no NVMe ao usar fsync é claramente visível. Você pode passar para a segunda pergunta.

Otimização ou blefe

Anteriormente dissemos que os dados são armazenados em um buffer, mas não especificamos em qual, pois não era importante. Mesmo agora não iremos nos aprofundar nos meandros dos sistemas operacionais e destacar dois tipos gerais de buffers:

• programa;
• hardware.

O buffer de software refere-se aos buffers que estão no sistema operacional e o buffer de hardware refere-se à memória volátil do controlador de disco. A chamada do sistema fsync envia um comando à unidade para gravar dados de seu buffer no armazenamento principal, mas não tem como controlar a execução correta do comando.

Como o SSD tem melhor desempenho, duas suposições podem ser feitas:

• o disco foi projetado para carregar um plano semelhante;
• o disco "blefa" e ignora o comando.

O comportamento desonesto da unidade pode ser percebido se você realizar um teste com falha de energia. Você pode verificar isso com um script. diskchecker.plque foi criado por no ano 2005.

Este script requer duas máquinas físicas – “servidor” e “cliente”. O cliente grava uma pequena quantidade de dados na unidade em teste, chama fsync e envia ao servidor informações sobre o que foi gravado.

# Запускается на сервере
./diskchecker.pl -l [port]

# Запускается на клиенте
./diskchecker.pl -s <server[:port]> create <file> <size_in_MB>

Após a execução do script, é necessário desenergizar o “cliente” e não retornar a energia por vários minutos. É importante desconectar a cobaia da eletricidade e não apenas realizar um desligamento forçado. Depois de algum tempo, o servidor pode ser conectado e carregado no sistema operacional. Depois de inicializar o sistema operacional, você precisa começar novamente diskchecker.pl, mas com um argumento verificar.

./diskchecker.pl -s <server[:port]> verify <file>

Ao final da verificação, você verá a quantidade de erros. Se forem 0, o disco passou no teste. Para excluir uma combinação de circunstâncias que seja bem-sucedida para o disco, o experimento pode ser repetido várias vezes.

Nosso S4500 não apresentou erros de perda de energia, o que significa que está pronto para cargas com muitas chamadas fsync.

Conclusão

Ao escolher discos ou configurações completas prontas, você deve ter em mente as especificidades das tarefas que precisam ser resolvidas. À primeira vista, parece óbvio que o NVMe, ou seja, um SSD com interface PCIe, é mais rápido que um SSD SATA “clássico”. No entanto, como hoje entendemos, em condições específicas e com determinadas tarefas pode não ser o caso.

Como você testa os componentes do servidor ao alugar de um provedor de IaaS?
Esperamos por você nos comentários.

Fonte: habr.com