Varför är min NVMe långsammare än SSD?

I denna artikel kommer vi att gå igenom några nyanser av in- och utmatningssystemet och deras påverkan på prestanda.

För ett par veckor sedan ställdes jag inför frågan varför NVMe på en server var långsammare än SATA på en annan. Jag kollade servernas specifikationer och insåg att det var en ledande fråga: NVMe kom från konsumentsegmentet, medan SSD:n var från serversegmentet.

Det är uppenbart att det är felaktigt att jämföra produkter från olika segment i olika miljöer, men det är inte ett uttömmande tekniskt svar. Låt oss utforska grunderna, genomföra experiment och ge ett svar på den ställda frågan.

Vad är fsync och var används det?

För att påskynda arbetet med lagringsenheter buffras data, vilket innebär att de sparas i icke-flyktig minne tills en lämplig tidpunkt för att spara innehållet i bufferten till lagringsenheten. Kriterier för en "lämplig tidpunkt" bestäms av operativsystemet och lagringsenhetens egenskaper. I händelse av strömavbrott kommer all data i bufferten att gå förlorad.

Det finns en rad uppgifter där det är viktigt att vara säker på att ändringar i en fil skrivs till lagringsenheten och inte ligger i en mellanbuffert. Denna säkerhet kan uppnås genom att använda det POSIX-kompatibla systemanropet fsync. Anropet fsync initierar en tvingad skrivning från bufferten till lagringsenheten.

Vi kommer att demonstrera buffrarnas påverkan genom ett konstruerat exempel i form av ett kort program på 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;
}

Kommentarerna förklarar väl sekvensen av åtgärder i programmet. Texten "svaret på den stora frågan om livet, universum och allt sådant" kommer att buffras av operativsystemet, och om servern startas om genom att trycka på Reset-knappen under "beräkningarna", kommer filen att vara tom. I vårt exempel är förlusten av text inte ett problem, därför behövs inte fsync. Databaser delar inte denna optimism.

Databaser är komplexa program som arbetar med många filer samtidigt, så de vill vara säkra på att de data som skrivs av dem kommer att sparas på lagringsenheten, eftersom detta påverkar datakonsistensen inom databasen. Databaser är designade för att skriva alla avslutade transaktioner och vara beredda på att strömmen kan gå när som helst. Detta beteende kräver att fsync används ständigt i stora mängder.

Hur frekvent användning av fsync påverkar

Vid vanlig in- och utdata försöker operativsystemet optimera kommunikationen med diskarna, eftersom externa lagringsenheter är de långsammaste i minneshierarkin. Därför försöker operativsystemet att skriva så mycket data som möjligt vid ett enda diskåtkomst.

Vi kommer att demonstrera effekten av att använda fsync med ett konkret exempel. De testade enheterna är följande SSD-enheter:

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

Tester utförs på Intel® Xeon® W-2255 som kör Ubuntu 20.04. För diskprov används sysbench 1.0.18. Det finns en partition på diskarna som är formaterad som ext4. Förberedelsen för testet innebär att skapa filer på 100 GB:

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

Starta tester:

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

Testresultaten presenteras i tabellen.

Test
Intel® S4500
Samsung 970 EVO+

Läsning utan fsync, MiB/s
5734.89
9028.86

Skrivning utan fsync, MiB/s
3823.26
6019.24

Läsning med fsync, MiB/s
37.76
3.27

Skrivning med fsync, MiB/s
25.17
2.18

Det är lätt att se att NVMe-enheter från konsumentsegmentet ledigt leder när operativsystemet själv beslutar hur det ska arbeta med diskar, men förlorar när fsync används. Här uppstår två frågor:

1. Varför överstiger läshastigheten utan fsync den fysiska bandbredden i kanalen?
2. Varför hanterar SSD-enheter från serversegmentet ett stort antal fsync-förfrågningar bättre?

Svaret på den första frågan är enkelt: sysbench genererar filer som är fyllda med nollor. Därför testades 100 gigabyte av nollor. Eftersom data är ganska homogena och förutsägbara kommer olika optimeringar från operativsystemet in i spelet och de påskyndar processen avsevärt.

Om man ifrågasätter alla resultat från sysbench kan man använda 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

Test
Intel® S4500
Samsung 970 EVO+

Läsning utan fsync, MiB/s
45.5
178

Skrivning utan fsync, MiB/s
30.4
119

Läsning med fsync, MiB/s
32.6
20.9

Skrivning med fsync, MiB/s
21.7
13.9

Trenden med nedgång i prestanda för NVMe vid användning av fsync är tydlig. Vi kan gå vidare till svaret på den andra frågan.

Optimering eller bluff

Tidigare nämnde vi att data lagras i en buffer men specificerade inte i vilken typ av buffer, eftersom det inte var kritiskt. Vi kommer inte att dyka ner i operativsystemens detaljer nu, utan skiljer mellan två allmänna typer av buffertar:

• programvaru;
• hårdvaru.

Med programbuffert avses buffrar som finns i operativsystemet, medan hårdvarubuffert avser den energiberoende minnet hos diskens kontroller. Systemanropet fsync skickar en beställning till lagringsenheten att skriva data från sin buffert till det primära lagret, men kan inte kontrollera att beställningen utförs korrekt.

Eftersom SSD:er visar bättre resultat kan man göra två antaganden:

• disken är designad för sådan belastning;
• disken "bluffar" och ignorerar kommandot.

Oärligt beteende från lagringsenheten kan observeras om man genomför ett test med strömavbrott. Detta kan kontrolleras med skriptet diskchecker.pl, som skapades skapat 2005.

Detta skript kräver två fysiska maskiner - en "server" och en "klient". Klienten skriver en liten mängd data till den testade disken, anropar fsync och skickar information om vad som har skrivits till servern.

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

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

Efter att skriptet har startats måste man stänga av "klienten" och hålla strömmen avstängd i flera minuter. Det är viktigt att verkligen koppla bort den testade enheten från strömmen och inte bara göra en hård avstängning. Efter en tid kan servern anslutas igen och operativsystemet laddas. När OS har laddats måste man köra diskchecker.pl, men med argumentet — körning av tester av den resulterande konfigurationen med hjälp av.

.\/diskchecker.pl -s  verify

I slutet av testet kommer du att se antalet fel. Om det är 0, betyder det att disken klarade testet. För att utesluta lyckliga omständigheter kan man upprepa testet flera gånger.

Vår S4500 visade inga fel vid strömavbrott, vilket innebär att man kan påstå att den är redo för belastning med många fsync-anrop.

Slutsats

Vid val av diskar eller hela färdiga konfigurationer bör man tänka på specifikationen av de uppgifter som behöver lösas. Vid första anblick verkar det uppenbart att NVMe, det vill säga SSD med PCIe-gränssnitt, är snabbare än "klassisk" SATA SSD. Men som vi har förstått idag, under specifika förhållanden och med vissa uppgifter, kan detta vara annorlunda.

Hur testar ni serverkomponenter när ni hyr från en IaaS-leverantör?
Vi ser fram emot era kommentarer.

Källa: habr.com