Miksi NVMe on hitaampi kuin SSD?

Tässä artikkelissa tarkastellaan joitain I/O-alijärjestelmän vivahteita ja niiden vaikutusta suorituskykyyn.

Pari viikkoa sitten törmäsin kysymykseen, miksi NVMe yhdellä palvelimella on hitaampi kuin SATA toisella. Katsoin palvelimien ominaisuuksia ja tajusin, että se oli temppukysymys: NVMe oli käyttäjäsegmentistä ja SSD oli palvelinsegmentistä.

Tietenkin ei ole oikein vertailla eri segmenttien tuotteita eri ympäristöissä, mutta tämä ei ole tyhjentävä tekninen vastaus. Tutkimme perusasiat, teemme kokeita ja annamme vastauksen esitettyyn kysymykseen.

Mikä on fsync ja missä sitä käytetään

Asemien kanssa työskentelyn nopeuttamiseksi tiedot puskuroidaan eli tallennetaan haihtuvaan muistiin, kunnes tulee sopiva tilaisuus tallentaa puskurin sisältö asemaan. Mahdollisuuskriteerit määräytyvät käyttöjärjestelmän ja aseman ominaisuuksien mukaan. Sähkökatkon sattuessa kaikki puskurissa olevat tiedot menetetään.

On useita tehtäviä, joissa sinun on varmistettava, että tiedoston muutokset kirjoitetaan asemaan eivätkä ole välipuskurissa. Tämä vakuutus voidaan saada käyttämällä POSIX-yhteensopivaa fsync-järjestelmäkutsua. Fsync-kutsu pakottaa kirjoituksen puskurista asemaan.

Havainnollistetaan puskurien vaikutus keinotekoisella esimerkillä lyhyen C-ohjelman muodossa.

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

Kommentit selittävät hyvin ohjelman toimintojen järjestyksen. Teksti "vastaus elämän, maailmankaikkeuden ja kaiken pääkysymykseen" puskuroidaan käyttöjärjestelmällä, ja jos käynnistät palvelimen uudelleen painamalla Reset-painiketta "laskelmien" aikana, tiedosto on tyhjä. Esimerkissämme tekstin menetys ei ole ongelma, joten fsyncia ei tarvita. Tietokannat eivät jaa tätä optimismia.

Tietokannat ovat monimutkaisia ​​ohjelmia, jotka toimivat useiden tiedostojen kanssa samanaikaisesti, joten ne haluavat olla varmoja, että kirjoittamansa tiedot tallennetaan asemalle, koska tietokannan tietojen johdonmukaisuus riippuu tästä. Tietokannat on suunniteltu tallentamaan kaikki suoritetut tapahtumat ja olemaan valmiita sähkökatkoksia varten milloin tahansa. Tämä toiminta pakottaa sinut käyttämään fsyncia jatkuvasti suuria määriä.

Mikä vaikuttaa fsyncin toistuvaan käyttöön

Normaalilla I/O:lla käyttöjärjestelmä yrittää optimoida levyviestinnän, koska ulkoiset asemat ovat muistihierarkian hitaimpia. Siksi käyttöjärjestelmä yrittää kirjoittaa niin paljon tietoa kuin mahdollista yhdellä pääsyllä asemaan.

Havainnollistetaan fsyncin käytön vaikutus tietyllä esimerkillä. Meillä on koehenkilöinä seuraavat SSD-levyt:

• Intel® DC SSD S4500 480 Gt, kytketty SATA 3.2:n kautta, 6 Gb/s;
• Samsung 970 EVO Plus 500GB, kytketty PCIe 3.0 x4:n kautta, ~31 Gbps.

Testit suoritetaan Intel® Xeon® W-2255:llä, jossa on Ubuntu 20.04. Levyjen testaamiseen käytetään sysbench 1.0.18:aa. Levyillä on yksi osio, joka on alustettu ext4:ksi. Testiin valmistautuminen on 100 Gt:n tiedostojen luominen:

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

Ajotestit:

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

Testitulokset on esitetty taulukossa.

Testi
Intel® S4500
Samsung 970 EVO+

Lue ilman fsyncia, MiB/s
5734.89
9028.86

Kirjoita ilman fsync, MiB/s
3823.26
6019.24

Lukeminen fsyncillä, MiB/s
37.76
3.27

Tallennus fsyncillä, MiB/s
25.17
2.18

On helppo nähdä, että asiakassegmentin NVMe johtaa luottavaisesti, kun käyttöjärjestelmä itse päättää, miten levyjen kanssa työskentelee, ja häviää, kun käytetään fsyncia. Tämä herättää kaksi kysymystä:

1. Miksi lukunopeus ylittää linkin fyysisen kaistanleveyden testissä ilman fsyncia?
2. Miksi palvelinsegmentin SSD käsittelee paremmin suurta määrää fsync-pyyntöjä?

Vastaus ensimmäiseen kysymykseen on yksinkertainen: sysbench luo nollalla täytetyt tiedostot. Näin ollen testi suoritettiin yli 100 gigatavua nollia. Koska tiedot ovat hyvin yhtenäisiä ja ennustettavia, tulevat käyttöön erilaiset käyttöjärjestelmän optimoinnit, jotka nopeuttavat huomattavasti suoritusta.

Jos kyseenalaistat kaikki sysbenchin tulokset, voit käyttää fioa.

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

Testi
Intel® S4500
Samsung 970 EVO+

Lue ilman fsyncia, MiB/s
45.5
178

Kirjoita ilman fsync, MiB/s
30.4
119

Lukeminen fsyncillä, MiB/s
32.6
20.9

Tallennus fsyncillä, MiB/s
21.7
13.9

Suuntaus suorituskyvyn laskuun NVMe:ssä fsyncia käytettäessä on selvästi nähtävissä. Voit siirtyä toiseen kysymykseen.

Optimointi tai bluffi

Aiemmin sanoimme, että tiedot on tallennettu puskuriin, mutta emme täsmentäneet mihin, koska se ei ollut tärkeää. Edes nyt emme syvenny käyttöjärjestelmien monimutkaisuuteen ja valitsemme kaksi yleistä puskurityyppiä:

• ohjelmoida;
• laitteisto.

Ohjelmistopuskuri viittaa käyttöjärjestelmässä oleviin puskureihin ja laitteistopuskuri levyohjaimen haihtuvaan muistiin. Fsync-järjestelmäkutsu lähettää asemalle komennon kirjoittaa tiedot puskuristaan ​​päämuistiin, mutta sillä ei ole keinoa hallita komennon oikeaa suoritusta.

Koska SSD toimii paremmin, voidaan tehdä kaksi oletusta:

• levy on suunniteltu samanlaisen suunnitelman kuormitukseen;
• levy "bluffaa" ja jättää komennon huomiotta.

Taajuusmuuttajan epärehellinen käyttäytyminen voidaan havaita, jos teet testin sähkökatkon kanssa. Voit tarkistaa tämän skriptillä. diskchecker.pl, joka oli luotu in 2005 vuotta.

Tämä komentosarja vaatii kaksi fyysistä konetta - "palvelin" ja "asiakas". Asiakas kirjoittaa pienen määrän dataa testattavalle asemalle, kutsuu fsynciä ja lähettää palvelimelle tiedot kirjoitetusta.

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

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

Komentosarjan suorittamisen jälkeen on tarpeen katkaista "asiakas" jännitteet eikä palauttaa virtaa useaan minuuttiin. On tärkeää irrottaa koehenkilö sähköstä, eikä tehdä vain kovaa sammutusta. Jonkin ajan kuluttua palvelin voidaan yhdistää ja ladata käyttöjärjestelmään. Käyttöjärjestelmän käynnistämisen jälkeen sinun on käynnistettävä uudelleen diskchecker.pl, mutta argumentin kanssa todentaa.

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

Tarkistuksen lopussa näet virheiden määrän. Jos ne ovat 0, levy läpäisi testin. Koe voidaan toistaa useita kertoja, jotta voidaan sulkea pois levylle onnistuneiden olosuhteiden yhdistelmä.

S4500-mallimme ei osoittanut tehohäviövirheitä, mikä tarkoittaa, että se on valmis kuormitukseen, jossa on paljon fsync-kutsuja.

Johtopäätös

Kun valitset levyjä tai kokonaisia ​​valmiita kokoonpanoja, sinun tulee pitää mielessä ratkaistavien tehtävien erityispiirteet. Ensi silmäyksellä näyttää ilmeiseltä, että NVMe, eli SSD, jossa on PCIe-liitäntä, on nopeampi kuin "klassinen" SATA SSD. Kuitenkin, kuten olemme tänään ymmärtäneet, tietyissä olosuhteissa ja tietyissä tehtävissä näin ei ehkä ole.

Kuinka testaat palvelinkomponentteja vuokratessasi IaaS-palveluntarjoajalta?
Odotamme sinua kommenteissa.

Lähde: will.com