Miért lassabb az NVMe, mint az SSD?

Ebben a cikkben megvizsgáljuk a bemeneti-kimeneti alrendszer néhány jellemzőjét és hatását a teljesítményre.

Pár héttel ezelőtt találkoztam azzal a kérdéssel, hogy miért lassabb az NVMe egy szerveren, mint a SATA egy másikon. Megnéztem a szerverek specifikációit, és rájöttem, hogy ez egy trükkös kérdés volt: az NVMe a fogyasztói szegmensből származott, míg az SSD a szerverek közül.

Nyilvánvaló, hogy helytelen különböző szegmensekből származó termékeket, különböző környezetben összehasonlítani, de ez nem tartalmazza a kimerítő műszaki választ. Vizsgáljuk meg az alapokat, végezzünk el kísérleteket, és adjunk választ a feltett kérdésre.

Mi az fsync és hol használják?

A tárolók gyorsabb működése érdekében az adatok pufferezve vannak, azaz az energiatároló memóriában tárolják őket, amíg nem lesz alkalmas idő a puffertartalom tárolására a tárolón. A "megfelelő alkalom" kritériumait az operációs rendszer és a tároló jellemzői határozzák meg. Az áramellátás megszűnése esetén a puffertartalom minden adata elveszik.

Számos olyan feladat létezik, ahol biztosnak kell lennünk abban, hogy a fájlban végrehajtott változások a tárolóra kerültek, és nem maradtak a közbenső pufferen. Ezt a biztonságot a POSIX-kompatibilis rendszerhívás, az fsync használatával nyerhetjük el. Az fsync hívás kezdeményezi a pufferből való kényszerített írást a tárolóra.

Demonstráljuk a pufferek hatását egy mesterséges példával, amely egy rövid C nyelvű programban jelenik meg.

#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;
}

A megjegyzések jól magyarázzák a programban végrehajtott lépések sorrendjét. A "válasz az élet, a világmindenség és minden ilyesmi fő kérdésére" szöveget az operációs rendszer pufferezni fogja, és ha a szervert a Reset gomb megnyomásával újraindítjuk a "számítások" alatt, a fájl üres marad. Példánkban a szöveg elvesztése nem okoz problémát, ezért az fsync nem szükséges. Az adatbázisok nem osztják ezt az optimizmust.

Az adatbázisok összetett programok, amelyek egyszerre sok fájllal dolgoznak, ezért biztosnak akarnak lenni abban, hogy az általuk írt adatok a tárolón maradnak, mivel ez befolyásolja az adatok konzisztenciáját az adatbázison belül. Az adatbázisok úgy vannak tervezve, hogy minden befejezett tranzakciót rögzítsenek, és készen álljanak az áramellátás bármikor való megszűnésére. Ez a viselkedés folyamatos fsync használatát vonja maga után nagy mennyiségben.

Mire hatással van a fsync gyakori használata?

Normál I/O esetén az operációs rendszer igyekszik optimalizálni a kommunikációt a lemezekkel, mivel a memóriahierarchiában a külső tárolók a leglassabbak. Ezért az operációs rendszer próbál egyetlen lemezhozzáférés alkalmával minél több adatot írni.

Demonstráljuk a fsync használatának hatását egy konkrét példán keresztül. A teszt alanyaink a következő SSD-k:

• Intel® DC SSD S4500 480 GB, SATA 3.2, 6 Gbit/s sebességgel csatlakoztatva;
• Samsung 970 EVO Plus 500GB, PCIe 3.0 x4, ~31 Gbit/s sebességgel csatlakoztatva.

A teszteket Intel® Xeon® W-2255 processzoron végeztük, Ubuntu 20.04 operációs rendszer alatt. A lemezek teszteléséhez a sysbench 1.0.18-at használtuk. A lemezeken egyetlen partíció található, amely ext4 formátumúra van formázva. A tesztre való felkészülés során 100 GB-os fájlokat hozunk létre:

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

Tesztelés indítása:

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

A teszteredmények táblázatban találhatók.

Teszt
Intel® S4500
Samsung 970 EVO+

Olvasás fsync nélkül, MiB/s
5734.89
9028.86

Írás fsync nélkül, MiB/s
3823.26
6019.24

Olvasás fsync használatával, MiB/s
37.76
3.27

Írás fsync használatával, MiB/s
25.17
2.18

Nem nehéz észrevenni, hogy az ügyfélszegmens NVMe világosan vezet, amikor az operációs rendszer saját magának dönti el, hogyan dolgozzon a lemezekkel, és elmarad, amikor fsync-et használnak. Innen két kérdés merül fel:

1. Miért haladja meg az fsync nélküli tesztben az olvasási sebesség a fizikai sávszélességet?
2. Miért kezeli jobban a szerver szegmensbe tartozó SSD a nagy számú fsync kérést?

Az első kérdésre a válasz egyszerű: a sysbench nulla értékekkel megtöltött fájlokat generál. Így a teszt 100 gigabyte nullával zajlott. Mivel az adatok meglehetősen egységesek és kiszámíthatóak, különféle operációs rendszerbeli optimalizációk lépnek életbe, amelyek jelentősen felgyorsítják a végrehajtást.

Ha megkérdőjelezzük a sysbench összes eredményét, akkor a fio-t lehet használni.

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

Teszt
Intel® S4500
Samsung 970 EVO+

Olvasás fsync nélkül, MiB/s
45.5
178

Írás fsync nélkül, MiB/s
30.4
119

Olvasás fsync használatával, MiB/s
32.6
20.9

Írás fsync használatával, MiB/s
21.7
13.9

A teljesítmény csökkenésének tendenciája az NVMe-nél fsync használata mellett jól látható. Jöhet a válasz a második kérdésre.

Optimalizálás vagy átverés

Korábban azt mondtuk, hogy az adatok a pufferben tárolódnak, de nem pontosítottuk, hogy pontosan melyikben, mivel ez nem volt lényeges. Most sem szeretnénk elmélyedni az operációs rendszerek kifinomultságaiban, és két általános puffertípust emelünk ki:

• szoftveres;
• hardveres.

A program buffer refers to the buffers present in the operating system, while a hardware buffer refers to the volatile memory of the disk controller. The system call fsync sends a command to the storage device to write data from its buffer to the main storage but cannot verify the correctness of the command's execution.

Since SSDs show better results, two assumptions can be made:

• the disk is designed to handle such loads;
• the disk is 'bluffing' and ignoring the command.

Dishonest behavior of the storage can be observed if a test is performed during a power outage. You can check this with the script diskchecker.pl, which was készült created in 2005.

This script requires two physical machines - a 'server' and a 'client'. The client writes a small amount of data to the test disk, calls fsync, and sends information about what was written to the server.

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

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

After running the script, you must cut power to the 'client' and not restore it for several minutes. It is important to disconnect the tested device from power rather than simply performing a hard shutdown. After some time, the server can be connected and booted into the OS. Once the OS is loaded, you need to restart diskchecker.pl, but with the argument verify.

./diskchecker.pl -s  verify

At the end of the check, you will see the number of errors. If it is 0, it means the disk passed the test. To exclude a lucky coincidence for the disk, the experiment can be repeated several times.

Our S4500 showed no errors during a power loss, meaning it can be confirmed that it is ready for workloads with a high number of fsync calls.

Zárás

When choosing disks or complete configurations, it is important to remember the specifics of the tasks that need to be solved. At first glance, it seems obvious that NVMe, which is SSD with a PCIe interface, is faster than 'classic' SATA SSDs. However, as we understood today, in specific conditions and with certain tasks, this may not be the case.

How do you test server components when renting from an IaaS provider?
We look forward to your comments.

Forrás: habr.com