Perchè u mo NVMe hè più lento chè un SSD?

In questu articulu, guardemu alcune di e sfumature di u subsistema I / O è u so impattu nantu à u rendiment.

Un paru di settimane fà aghju fattu una quistione perchè NVMe in un servitore hè più lento chè SATA in un altru. Aghju guardatu e caratteristiche di i servitori è aghju realizatu chì era una quistione di truccu: NVMe era da u segmentu di l'utilizatori, è SSD era da u segmentu di u servitore.

Ovviamente, ùn hè micca currettu paragunà i prudutti di diversi segmenti in diversi ambienti, ma ùn hè micca una risposta tecnica exhaustiva. Studiaremu i fundamenti, cunduceremu esperimenti è daremu una risposta à a quistione posta.

Cosa hè fsync è induve hè utilizatu

Per accelerà u travagliu cù l'unità, i dati sò buffered, vale à dì, almacenati in memoria volatile finu à chì una oportunità conveniente si prisenta per salvà u cuntenutu di u buffer à l'unità. I criteri di l'opportunità sò determinati da u sistema operatore è e caratteristiche di u drive. In casu di una mancanza di energia, tutti i dati in u buffer seranu persi.

Ci hè una quantità di compiti in quale avete bisognu à esse sicuru chì i cambiamenti in u schedariu sò scritti à u discu, è ùn si trovanu micca in un buffer intermediariu. Questa assicuranza pò esse ottenuta usendu a chjama di u sistema fsync POSIX-compliant. A chjama fsync forza una scrittura da u buffer à l'unità.

Dimustremu l'effettu di i buffers cù un esempiu artificiale in a forma di un prugramma C curtu.

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

I cumenti spieganu bè a sequenza di l'azzioni in u prugramma. U testu "a risposta à a quistione principale di a vita, l'universu è tuttu ciò" serà buffered da u sistema upirativu, è se riavviate u servitore pressu u buttone Reset durante i "calculazioni", u schedariu serà viotu. In u nostru esempiu, a perdita di testu ùn hè micca un prublema, cusì fsync ùn hè micca necessariu. E basa di dati ùn sparte micca stu ottimisimu.

E basa di dati sò prugrammi cumplessi chì travaglianu cù parechji schedari à u stessu tempu, cusì volenu esse sicuru chì e dati chì scrivenu seranu guardati in u discu, postu chì a cunsistenza di e dati in a basa di dati depende di questu. I basa di dati sò pensati per registrà tutte e transazzione cumplette è esse pronti per una mancanza di energia in ogni mumentu. Stu cumpurtamentu vi obliga à aduprà fsync constantemente in quantità grandi.

Ciò chì afecta l'usu frequente di fsync

Cù l'I / O normale, u sistema operatore prova di ottimisà a cumunicazione di discu, postu chì i discu esterni sò i più lenti in a ghjerarchia di memoria. Dunque, u sistema upirativu prova di scrive quant'è più dati pussibule in un accessu à u drive.

Dimustrà l'impattu di l'usu di fsync cun un esempiu specificu. Avemu i seguenti SSD cum'è sughjetti di teste:

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

I testi sò realizati nantu à un Intel® Xeon® W-2255 cù Ubuntu 20.04. Per pruvà i dischi, si usa sysbench 1.0.18. I dischi anu una sola partizione furmatu cum'è ext4. A preparazione per a prova hè di creà schedarii di 100 GB:

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

Testi in esecuzione:

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

I risultati di a prova sò presentati in a tavula.

Test
Intel® S4500
Samsung 970 EVO+

Leghjite senza fsync, MiB/s
5734.89
9028.86

Scrivite senza fsync, MiB/s
3823.26
6019.24

Lettura cù fsync, MiB/s
37.76
3.27

Registrazione cù fsync, MiB/s
25.17
2.18

Hè faciule per vede chì NVMe da u segmentu di u cliente cunfidenza cunduce quandu u sistema operatore stessu decide cumu travaglià cù dischi, è perde quandu fsync hè utilizatu. Questu pone duie dumande:

1. Perchè a velocità di lettura supera a larghezza di banda fisica di u ligame in a prova senza fsync?
2. Perchè un segmentu di servitore SSD hè megliu per trattà un gran numaru di richieste fsync?

A risposta à a prima quistione hè simplice: sysbench genera file zero-filled. Cusì, a prova hè stata realizata nantu à 100 gigabytes di zeri. Siccomu i dati sò assai uniformi è prevedibili, diverse ottimisazioni OS entranu in ghjocu, è acceleranu significativamente l'esekzione.

Se dumandate tutti i risultati di sysbench, pudete aduprà 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+

Leghjite senza fsync, MiB/s
45.5
178

Scrivite senza fsync, MiB/s
30.4
119

Lettura cù fsync, MiB/s
32.6
20.9

Registrazione cù fsync, MiB/s
21.7
13.9

A tendenza versu a calata di rendiment in NVMe quandu si usa fsync hè chjaramente visibile. Pudete passà à a seconda quistione.

Ottimizazione o bluff

Prima avemu dettu chì i dati sò guardati in un buffer, ma ùn hà micca specificatu in quale, postu chì ùn era micca impurtante. Ancu avà ùn avemu micca sfondate in l'intricacies di i sistemi operativi è smarcate dui tipi generali di buffers:

• prugramma;
• hardware.

U buffer di software si riferisce à i buffers chì sò in u sistema operatore, è u buffer hardware si riferisce à a memoria volatile di u controller di discu. A chjama di u sistema fsync manda un cumandamentu à u drive per scrive dati da u so buffer à l'almacenamiento principale, ma ùn hà micca manera di cuntrullà l'esekzione curretta di u cumandamentu.

Siccomu u SSD funziona megliu, ponu esse fatte duie ipotesi:

• u discu hè pensatu per una carica di un pianu simili;
• u discu "bluffs" è ignora u cumandamentu.

U cumpurtamentu dishonest di l'unità pò esse nutatu se fate una prova cù una mancanza di energia. Pudete cuntrollà questu cun un script. diskchecker.pl, chì era stabilitu in 2005 annata.

Stu script richiede duie macchine fisiche - "server" è "client". U cliente scrive una piccula quantità di dati à l'unità in prova, chjama fsync, è manda l'infurmazioni di u servitore nantu à ciò chì hè statu scrittu.

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

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

Dopu avè eseguitu u script, hè necessariu di de-energize u "cliente" è ùn rinvià u putere per parechji minuti. Hè impurtante di disconnect u sughjettu di prova da l'electricità, è micca solu fà un fermu duru. Dopu qualchì tempu, u servitore pò esse cunnessu è carricu in u SO. Dopu avè avviatu l'OS, avete bisognu di ripiglià diskchecker.pl, ma cù un argumentu verificate.

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

À a fine di u cuntrollu, vi vede u numeru di errori. Se sò 0, u discu hà passatu a prova. Per escludiri una cumminazione di circustanze chì hè successu per u discu, l'esperimentu pò esse ripetutu parechje volte.

U nostru S4500 ùn hà dimustratu micca errori di perdita di energia, chì significa chì hè prontu per carichi cù parechje chjamate fsync.

cunchiusioni

Quandu sceglite dischi o cunfigurazioni intere pronti, duvete tene in mente i specifichi di i travaglii chì deve esse risolti. À u primu sguardu, pare evidenti chì NVMe, vale à dì, un SSD cù una interfaccia PCIe, hè più veloce di un SSD SATA "classicu". Tuttavia, cum'è avemu capitu oghje, in cundizioni specifichi è cù certi compiti ùn pò esse micca u casu.

Cumu testate i cumpunenti di u servitore quandu affittu da un fornitore IaaS?
Vi aspittemu in i cumenti.

Source: www.habr.com