Per què el meu NVMe és més lent que un SSD?

En aquest article analitzarem alguns dels matisos del subsistema d'E/S i el seu impacte en el rendiment.

Fa un parell de setmanes em vaig preguntar per què NVMe en un servidor és més lent que SATA en un altre. Vaig mirar les característiques dels servidors i em vaig adonar que era una pregunta enganyosa: NVMe era del segment d'usuaris i SSD era del segment del servidor.

Òbviament, no és just comparar productes de diferents segments en diferents entorns, però aquesta no és una resposta tècnica completa. Estudiarem les bases, realitzarem experiments i donarem resposta a la pregunta plantejada.

Què és fsync i on s'utilitza

Per accelerar el treball amb les unitats, les dades s'emmagatzemen en memòria intermèdia, és a dir, s'emmagatzemen a la memòria volàtil fins que es presenta una oportunitat convenient per desar el contingut de la memòria intermèdia a la unitat. Els criteris d'oportunitat estan determinats pel sistema operatiu i les característiques de la unitat. En cas de fallada de corrent, es perdran totes les dades de la memòria intermèdia.

Hi ha una sèrie de tasques en les quals cal assegurar-se que els canvis en un fitxer s'escriuen a la unitat i no en un buffer intermedi. Aquesta garantia es pot obtenir mitjançant la trucada al sistema fsync compatible amb POSIX. La trucada fsync força una escriptura des de la memòria intermèdia a la unitat.

Demostrem l'efecte dels buffers amb un exemple artificial en forma de programa breu en 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;
}

Els comentaris expliquen bé la seqüència d'accions del programa. El text "la resposta a la pregunta principal de la vida, l'univers i tot això" serà emmagatzemat pel sistema operatiu, i si reinicieu el servidor prement el botó Restableix durant els "càlculs", el fitxer estarà buit. En el nostre exemple, la pèrdua de text no és un problema, de manera que no cal fsync. Les bases de dades no comparteixen aquest optimisme.

Les bases de dades són programes complexos que funcionen simultàniament amb molts fitxers, per la qual cosa volen estar segurs que les dades que escriuen es desaran a la unitat, ja que d'això depèn la consistència de les dades dins de la base de dades. Les bases de dades estan dissenyades per registrar totes les transaccions realitzades i estar preparats per perdre energia en qualsevol moment. Aquest comportament us obliga a utilitzar fsync constantment en grans quantitats.

Quin és l'efecte de l'ús freqüent de fsync?

Durant l'E/S normal, el sistema operatiu intenta optimitzar la comunicació amb els discs, ja que les unitats externes són les més lentes de la jerarquia de memòria. Per tant, el sistema operatiu intenta escriure tantes dades com sigui possible en un accés a la unitat.

Demostrem l'impacte de l'ús de fsync amb un exemple específic. Tenim els següents SSD com a subjectes de prova:

• Intel® DC SSD S4500 480 GB, connectat mitjançant SATA 3.2, 6 Gb/s;
• Samsung 970 EVO Plus 500 GB, connectat mitjançant PCIe 3.0 x4, ~31 Gbit/s.

Les proves es realitzen en un Intel® Xeon® W-2255 amb Ubuntu 20.04. Sysbench 1.0.18 s'utilitza per provar discs. S'ha creat una partició als discs, formatada com a ext4. La preparació per a la prova implica la creació de fitxers de 100 GB:

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

Execució de proves:

# Без 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

Els resultats de la prova es presenten a la taula.

Prova
Intel® S4500
Samsung 970 EVO+

Lectura sense fsync, MiB/s
5734.89
9028.86

Gravació sense fsync, MiB/s
3823.26
6019.24

Lectura amb fsync, MiB/s
37.76
3.27

Gravació amb fsync, MiB/s
25.17
2.18

És fàcil veure que NVMe del segment de clients lidera amb confiança quan el propi sistema operatiu decideix com treballar amb els discs i perd quan s'utilitza fsync. Això planteja dues preguntes:

1. Per què la velocitat de lectura de la prova sense fsync supera l'ample de banda físic del canal?
2. Per què un SSD de segment de servidor és millor per gestionar un gran nombre de sol·licituds fsync?

La resposta a la primera pregunta és senzilla: sysbench genera fitxers plens de zero. Així, la prova es va dur a terme sobre 100 gigabytes de zeros. Com que les dades són molt uniformes i predictibles, entren en joc diverses optimitzacions del sistema operatiu i acceleren significativament l'execució.

Si poseu en dubte tots els resultats de sysbench, podeu utilitzar 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

Prova
Intel® S4500
Samsung 970 EVO+

Lectura sense fsync, MiB/s
45.5
178

Gravació sense fsync, MiB/s
30.4
119

Lectura amb fsync, MiB/s
32.6
20.9

Gravació amb fsync, MiB/s
21.7
13.9

La tendència a la caiguda del rendiment a NVMe quan s'utilitza fsync és clarament visible. Podeu passar a la segona pregunta.

Optimització o farol

Abans dèiem que les dades s'emmagatzemen en un buffer, però no hem especificat en quin, ja que no era important. Fins i tot ara no aprofundirem en les complexitats dels sistemes operatius i distingirem dos tipus generals de buffers:

• programa;
• maquinari.

La memòria intermèdia de programari es refereix a la memòria intermèdia que hi ha al sistema operatiu, i la memòria intermèdia de maquinari fa referència a la memòria volàtil del controlador de disc. La trucada al sistema fsync envia una ordre a la unitat per escriure dades des del seu buffer a l'emmagatzematge principal, però no té cap manera de controlar l'execució correcta de l'ordre.

Com que l'SSD mostra els millors resultats, es poden fer dues hipòtesis:

• el disc està dissenyat per a una càrrega d'un pla similar;
• el disc "enfada" i ignora l'ordre.

Es pot notar un comportament deshonest de la unitat si feu una prova amb una fallada de corrent. Podeu comprovar-ho amb un script. discchecker.pl, això va ser creat l'any 2005.

Aquest script requereix dues màquines físiques: "servidor" i "client". El client escriu una petita quantitat de dades a la unitat que s'està provant, crida a fsync i envia la informació del servidor sobre el que s'ha escrit.

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

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

Després d'executar l'script, heu d'apagar l'alimentació al "client" i no retornar l'alimentació durant uns quants minuts. És important desconnectar la persona que s'està provant de l'electricitat i no només fer un apagat fort. Després d'un temps, el servidor es pot connectar i carregar al sistema operatiu. Després d'arrencar el sistema operatiu, heu de tornar a començar discchecker.pl, però amb un argument verificar.

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

Al final de la comprovació, veureu el nombre d'errors. Si són 0, el disc ha passat la prova. Per excloure una combinació de circumstàncies que tingui èxit per al disc, l'experiment es pot repetir diverses vegades.

El nostre S4500 no va mostrar cap error quan es va perdre energia, el que significa que està preparat per a càrregues de treball amb moltes trucades fsync.

Conclusió

Quan escolliu discs o configuracions senceres ja fetes, haureu de recordar les especificitats dels problemes que cal resoldre. A primera vista, sembla obvi que NVMe, és a dir, un SSD amb una interfície PCIe, és més ràpid que el "clàssic" SSD SATA. Tanmateix, com hem après avui, en condicions concretes i amb determinades tasques pot ser que no sigui així.

Com proveu els components del servidor quan llogueu a un proveïdor d'IaaS?
T'esperem als comentaris.

Font: www.habr.com