🥇Por que meu NVMe é mais lento que o SSD?

Neste artigo, vamos discutir algumas nuances do subsistema de entrada e saída e seu impacto no desempenho.

Algumas semanas atrás, me deparei com a questão de por que um NVMe em um servidor era mais lento do que um SATA em outro. Olhei para as especificações dos servidores e percebi que era uma questão enganosa: o NVMe era de segmento consumidor, enquanto o SSD era de segmento servidor.

É evidente que comparar produtos de diferentes segmentos em ambientes distintos não é correto, mas isso não é uma resposta técnica completa. Vamos estudar os fundamentos, realizar experimentos e dar uma resposta à questão levantada.

O que é fsync e onde ele é utilizado

Para acelerar o trabalho com dispositivos de armazenamento, os dados são armazenados em buffer, ou seja, guardados na memória volátil até que haja uma oportunidade adequada para gravar o conteúdo do buffer no dispositivo. Os critérios para o que constitui uma "oportunidade adequada" são determinados pelo sistema operacional e pelas características do dispositivo. Em caso de falta de energia, todos os dados no buffer serão perdidos.

Existem várias tarefas nas quais é necessário ter certeza de que as alterações em um arquivo foram gravadas no dispositivo e não estão apenas no buffer intermediário. Essa certeza pode ser obtida ao usar a chamada de sistema compatível com POSIX, fsync. A chamada fsync inicia a gravação forçada do buffer no dispositivo.

Vamos demonstrar o impacto dos buffers com um exemplo artificial na forma de um pequeno programa em C.

#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 no programa. O texto "resposta à pergunta principal da vida, do universo e de tudo" será armazenado em buffer pelo sistema operacional, e se o servidor for reiniciado pressionando o botão Reset durante os "cálculos", o arquivo ficará vazio. No nosso exemplo, a perda de texto não é um problema, portanto, fsync não é necessário. Bancos de dados não compartilham desse otimismo.

Bancos de dados são programas complexos que lidam com muitos arquivos simultaneamente, portanto, querem ter certeza de que os dados gravados serão salvos no dispositivo, pois isso afeta a consistência dos dados dentro do BD. Eles são projetados para gravar todas as transações concluídas e estar prontos para uma falha de energia a qualquer momento. Esse comportamento exige o uso constante do fsync em grande quantidade.

Como o uso frequente de fsync afeta o desempenho

Ao realizar operações de leitura e escrita, o sistema operacional busca otimizar a comunicação com os discos, uma vez que, na hierarquia de memória, os dispositivos de armazenamento externos são os mais lentos. Portanto, o sistema operacional tenta gravar o máximo de dados possível em uma única operação no dispositivo.

Vamos demonstrar o impacto do uso de fsync com um exemplo específico. Os dispositivos testados são os seguintes:

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

Os testes são conduzidos em um Intel® Xeon® W-2255 sob o sistema operacional Ubuntu 20.04. Para testar os discos, utilizamos o sysbench 1.0.18. Um único partição foi criada nos discos, formatada como ext4. A preparação para o teste consiste na criação de arquivos de 100 GB:

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

Iniciando os 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 dos testes estão apresentados na tabela.

Teste
Intel® S4500
Samsung 970 EVO+

Leitura sem fsync, MiB/s
5734.89
9028.86

Gravação sem fsync, MiB/s
3823.26
6019.24

Leitura com fsync, MiB/s
37.76
3.27

Gravação com fsync, MiB/s
25.17
2.18

É fácil notar que o NVMe do segmento de consumo é claramente superior quando o sistema operacional decide como trabalhar com os discos, mas perde desempenho quando se utiliza fsync. Isso levanta duas perguntas:

Por que no teste sem fsync a velocidade de leitura excede a largura de banda física do canal?
Por que os SSDs do segmento servidor lidam melhor com um grande número de solicitações de fsync?

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

Se houver dúvidas sobre todos os resultados do sysbench, pode-se utilizar 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+

Leitura sem fsync, MiB/s
45.5
178

Gravação sem fsync, MiB/s
30.4
119

Leitura com fsync, MiB/s
32.6
20.9

Gravação com fsync, MiB/s
21.7
13.9

A tendência à queda de desempenho do NVMe ao usar fsync é claramente visível. Podemos avançar para a resposta à segunda pergunta.

Otimização ou ilusão

Anteriormente, mencionamos que os dados são armazenados em cache, mas não especificamos em qual tipo, pois isso não era crucial. E agora, também não iremos nos aprofundar nas sutilezas dos sistemas operacionais, mas destacaremos dois tipos gerais de caches:

software;
hardware.

O buffer de software refere-se aos buffers que existem no sistema operacional, enquanto o buffer de hardware se refere à memória volátil do controlador de disco. A chamada de sistema fsync envia ao dispositivo o comando de gravar os dados de seu buffer no armazenamento principal, mas não pode controlar a correção da execução desse comando.

Uma vez que o SSD apresenta melhores resultados, podemos fazer duas suposições:

o disco foi projetado para uma carga desse tipo;
o disco está "blefando" e ignorando o comando.

O comportamento desonesto do dispositivo pode ser notado se um teste for realizado com a falha de energia. Isso pode ser verificado com o script diskchecker.pl, que foi uma seção separada para scripts de identificação oculta. Além disso, o FP-Inspector permitiu identificar algumas novas formas de usar APIs da web para identificação, que antes não tinham sido observadas na prática. em 2005.

Este script requer duas máquinas físicas - "servidor" e "cliente". O cliente grava uma pequena quantidade de dados no disco em teste, chama fsync e envia ao servidor as informações sobre o que foi gravado.

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

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

Após iniciar o script, é necessário desligar o "cliente" e não restabelecer a energia por vários minutos. É importante desconectar o testado da energia, e não apenas desligá-lo abruptamente. Após algum tempo, o servidor pode ser reconectado e inicializado no SO. Após a inicialização do SO, deve-se reiniciar diskchecker.pl, mas com o argumento verify.

.\/diskchecker.pl -s  verify

No final da verificação, você verá a quantidade de erros. Se forem 0, significa que o disco passou no teste. Para evitar uma feliz coincidência para o disco, o teste pode ser repetido várias vezes.

Nosso S4500 não apresentou erros durante a perda de energia, ou seja, podemos afirmar que ele está preparado para cargas com um grande número de chamadas fsync.

Conclusão

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

E como você testa os componentes dos servidores ao alugar de um provedor IaaS?
Esperamos por você nos comentários.

Fonte: habr.com