Miks on minu NVMe aeglasem kui SSD?

Selles artiklis vaatleme mõningaid I / O alamsüsteemi nüansse ja nende mõju jõudlusele.

Paar nädalat tagasi tekkis mul küsimus, miks NVMe ühes serveris on aeglasem kui SATA teises. Vaatasin serverite omadusi ja mõistsin, et see oli trikiga küsimus: NVMe oli kasutajate segmendist ja SSD oli serveri segmendist.

Ilmselgelt ei ole õige võrrelda eri segmentide tooteid erinevates keskkondades, kuid see pole ammendav tehniline vastus. Uurime põhitõdesid, teeme katseid ja anname vastuse esitatud küsimusele.

Mis on fsync ja kus seda kasutatakse

Draividega töötamise kiirendamiseks puhverdatakse andmed, st salvestatakse muutmälus, kuni avaneb mugav võimalus puhvri sisu draivi salvestada. Võimaluse kriteeriumid määravad operatsioonisüsteem ja draivi omadused. Elektrikatkestuse korral kaovad kõik puhvris olevad andmed.

On mitmeid ülesandeid, mille puhul peate olema kindel, et faili muudatused kirjutatakse draivi ega asu vahepealses puhvris. Selle kinnituse saate POSIX-iga ühilduva fsynci süsteemikutsega. Fsynci kutse sunnib puhvrist draivi kirjutama.

Demonstreerime puhvrite mõju tehisnäite abil lühikese C programmi näol.

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

Kommentaarid selgitavad hästi programmi toimingute jada. Tekst "vastus põhiküsimusele elu, universum ja kõik see" puhverdab operatsioonisüsteem ja kui "arvutuste" ajal Reset nuppu vajutades taaskäivitada server, jääb fail tühjaks. Meie näites pole teksti kadu probleem, seega pole fsynci vaja. Andmebaasid seda optimismi ei jaga.

Andmebaasid on keerulised programmid, mis töötavad korraga paljude failidega, nii et nad tahavad olla kindlad, et nende kirjutatud andmed salvestatakse draivile, kuna sellest sõltub andmete järjepidevus andmebaasis. Andmebaasid on loodud selleks, et salvestada kõik sooritatud tehingud ja olla igal ajal valmis elektrikatkestusteks. See käitumine kohustab teid kasutama fsynci pidevalt suurtes kogustes.

Mis mõjutab fsynci sagedast kasutamist

Tavalise I/O-ga üritab operatsioonisüsteem kettasidet optimeerida, kuna välised draivid on mäluhierarhias kõige aeglasemad. Seetõttu proovib operatsioonisüsteem draivi ühe juurdepääsuga kirjutada võimalikult palju andmeid.

Näitame konkreetse näitega fsynci kasutamise mõju. Meil on katsealusteks järgmised SSD-d:

• Intel® DC SSD S4500 480 GB, ühendatud SATA 3.2 kaudu, 6 Gb/s;
• Samsung 970 EVO Plus 500GB, ühendatud läbi PCIe 3.0 x4, ~31 Gbps.

Testid viiakse läbi Intel® Xeon® W-2255-ga, milles töötab Ubuntu 20.04. Ketaste testimiseks kasutatakse sysbench 1.0.18. Ketastel on üks sektsioon, mis on vormindatud kujul ext4. Testiks valmistumine on 100 GB failide loomine:

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

Testide jooksmine:

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

Testi tulemused on toodud tabelis.

Test
Intel® S4500
Samsung 970 EVO+

Loe ilma fsyncita, MiB/s
5734.89
9028.86

Kirjutage ilma fsyncita, MiB/s
3823.26
6019.24

Lugemine fsynciga, MiB/s
37.76
3.27

Salvestamine fsynciga, MiB/s
25.17
2.18

On lihtne näha, et kliendisegmendi NVMe juhib enesekindlalt, kui operatsioonisüsteem ise otsustab, kuidas ketastega töötada, ja kaotab, kui kasutatakse fsynci. See tõstatab kaks küsimust:

1. Miks ületab lugemiskiirus testis ilma fsyncita lingi füüsilise ribalaiuse?
2. Miks suudab serverisegmendi SSD paremini käsitleda suurt hulka fsynci taotlusi?

Vastus esimesele küsimusele on lihtne: sysbench genereerib nulliga täidetud failid. Seega viidi test läbi üle 100 gigabaidi nulli. Kuna andmed on väga ühtlased ja etteaimatavad, tulevad mängu erinevad OS-i optimeerimised, mis kiirendavad oluliselt täitmist.

Kui kahtlete kõigis sysbenchi tulemustes, võite kasutada 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+

Loe ilma fsyncita, MiB/s
45.5
178

Kirjutage ilma fsyncita, MiB/s
30.4
119

Lugemine fsynciga, MiB/s
32.6
20.9

Salvestamine fsynciga, MiB/s
21.7
13.9

Trend NVMe jõudluse languse suunas fsynci kasutamisel on selgelt nähtav. Võite liikuda teise küsimuse juurde.

Optimeerimine või bluff

Varem rääkisime, et andmeid hoitakse puhvris, kuid ei täpsustanud, millises, kuna see polnud oluline. Isegi praegu ei süvene me operatsioonisüsteemide keerukusesse ja eristame kahte tüüpi puhvreid:

• programm;
• riistvara.

Tarkvarapuhver viitab operatsioonisüsteemis olevatele puhvritele ja riistvarapuhver viitab kettakontrolleri lenduvale mälule. Fsynci süsteemikutse saadab draivile käsu kirjutada andmed oma puhvrist põhimällu, kuid tal pole võimalust käsu õiget täitmist juhtida.

Kuna SSD töötab paremini, võib teha kaks eeldust:

• ketas on mõeldud sarnase plaani koormuse jaoks;
• ketas "bluffib" ja ignoreerib käsku.

Ajami ebaaus käitumist võib märgata, kui sooritate elektrikatkestuse testi. Saate seda kontrollida skripti abil. diskchecker.pl, mis oli loodud aastal 2005 aastal.

See skript nõuab kahte füüsilist masinat – "serverit" ja "klient". Klient kirjutab testitavale draivile väikese koguse andmeid, kutsub fsynci ja saadab serverile info kirjutatu kohta.

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

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

Pärast skripti käivitamist on vaja "klient" pingest välja lülitada ja toidet ei tagastata mitu minutit. Oluline on katsealune elektrivõrgust lahti ühendada, mitte teha lihtsalt kõva väljalülitamist. Mõne aja pärast saab serveri ühendada ja OS-i laadida. Pärast OS-i käivitamist peate uuesti alustama diskchecker.pl, kuid argumendiga kontrollima.

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

Kontrollimise lõpus näete vigade arvu. Kui need on 0, läbis ketas testi. Ketta jaoks edukate asjaolude kombinatsiooni välistamiseks võib katset mitu korda korrata.

Meie S4500 ei näidanud voolukadu vigu, mis tähendab, et see on valmis koormusteks, kus on palju fsynci kõnesid.

Järeldus

Ketaste või tervete valmiskonfiguratsioonide valimisel tuleks silmas pidada lahendamist vajavate ülesannete spetsiifikat. Esmapilgul tundub ilmselge, et NVMe ehk PCIe liidesega SSD on kiirem kui "klassikaline" SATA SSD. Kuid nagu me täna aru oleme saanud, ei pruugi see konkreetsetes tingimustes ja teatud ülesannete puhul nii olla.

Kuidas testite serveri komponente IaaS-i pakkujalt rentides?
Ootame teid kommentaaridesse.

Allikas: www.habr.com