Kāpēc mans NVMe ir lēnāks nekā SSD?

Kāpēc mans NVMe ir lēnāks nekā SSD?
Å ajā rakstā apskatÄ«sim dažas I/O apakÅ”sistēmas nianses un to ietekmi uz veiktspēju.

Pirms pāris nedēļām saskāros ar jautājumu, kāpēc NVMe vienā serverī bija lēnāks nekā SATA citā. Es paskatījos uz servera specifikācijām un sapratu, ka tas ir sarežģīts jautājums: NVMe bija no lietotāju segmenta, un SSD bija no servera segmenta.

Acīmredzot nav godīgi salīdzināt dažādu segmentu produktus dažādās vidēs, taču tā nav pilnīga tehniskā atbilde. Izpētīsim pamatus, veiksim eksperimentus un sniegsim atbildi uz uzdoto jautājumu.

Kas ir fsync un kur to izmanto?

Lai paātrinātu darbu ar diskdziņiem, dati tiek buferizēti, tas ir, tiek glabāti nepastāvÄ«gajā atmiņā, lÄ«dz parādās ērta iespēja saglabāt bufera saturu diskdzinÄ«. ā€œIespējasā€ kritērijus nosaka operētājsistēma un diskdziņa raksturlielumi. Strāvas padeves pārtraukuma gadÄ«jumā visi buferÄ« esoÅ”ie dati tiks zaudēti.

Ir vairāki uzdevumi, kuros jums ir jāpārliecinās, ka faila izmaiņas tiek ierakstÄ«tas diskdzinÄ«, nevis starpposma buferÄ«. Å o pārliecÄ«bu var iegÅ«t, izmantojot POSIX saderÄ«gu fsync sistēmas izsaukumu. Fsync izsaukÅ”ana liek rakstÄ«t no bufera uz disku.

Demonstrēsim buferu efektu ar mākslīgu piemēru īsas programmas veidā C valodā.

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

Komentāri labi izskaidro darbÄ«bu secÄ«bu programmā. Teksts ā€œatbilde uz galveno jautājumu par dzÄ«vÄ«bu, Visumu un visu toā€ tiks buferēts ar operētājsistēmu, un, ja ā€œaprēķinuā€ laikā restartēsit serveri, nospiežot pogu Reset, fails bÅ«s tukÅ”s. MÅ«su piemērā teksta zudums nav problēma, tāpēc fsync nav nepiecieÅ”ams. Datu bāzes nepiekrÄ«t Å”im optimismam.

Datu bāzes ir sarežģītas programmas, kas vienlaikus strādā ar daudziem failiem, tāpēc viņi vēlas bÅ«t pārliecināti, ka viņu rakstÄ«tie dati tiks saglabāti diskdzinÄ«, jo no tā ir atkarÄ«ga datu konsekvence datu bāzē. Datu bāzes ir paredzētas, lai reÄ£istrētu visus pabeigtos darÄ«jumus un bÅ«tu gatavas jebkurā laikā zaudēt enerÄ£iju. Å Ä« darbÄ«ba prasa fsync nepārtrauktu izmantoÅ”anu lielos daudzumos.

Kādas ir biežas fsync lietoŔanas sekas?

Parastā I/O laikā operētājsistēma mēģina optimizēt saziņu ar diskiem, jo ā€‹ā€‹Ärējie diskdziņi ir vislēnākie atmiņas hierarhijā. Tāpēc operētājsistēma mēģina ierakstÄ«t pēc iespējas vairāk datu vienā pieejā diskam.

ParādÄ«sim fsync izmantoÅ”anas ietekmi ar konkrētu piemēru. Mums ir Ŕādi SSD kā testa diski:

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

Testi tiek veikti ar IntelĀ® XeonĀ® W-2255, kurā darbojas Ubuntu 20.04. Disku testÄ“Å”anai tiek izmantota Sysbench 1.0.18. Diskos ir izveidots viens nodalÄ«jums, kas formatēts kā ext4. SagatavoÅ”anās pārbaudei ietver 100 GB failu izveidi:

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

SkrieŔanas testi:

# Š‘ŠµŠ· 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

Pārbaudes rezultāti ir parādīti tabulā.

Pārbaude
IntelĀ® S4500
Samsung 970 EVO+

LasīŔana bez fsync, MiB/s
5734.89
9028.86

Ieraksts bez fsync, MiB/s
3823.26
6019.24

LasīŔana ar fsync, MiB/s
37.76
3.27

Ieraksts ar fsync, MiB/s
25.17
2.18

Ir viegli redzēt, ka NVMe no klientu segmenta pārliecinoÅ”i ir vadÄ«bā, kad operētājsistēma pati izlemj, kā strādāt ar diskiem, un zaudē, kad tiek izmantots fsync. Tas rada divus jautājumus:

  1. Kāpēc lasÄ«Å”anas ātrums testā bez fsync pārsniedz kanāla fizisko joslas platumu?
  2. Kāpēc servera segmenta SSD labāk apstrādā lielu skaitu fsync pieprasījumu?

Atbilde uz pirmo jautājumu ir vienkārÅ”a: sysbench Ä£enerē failus, kas aizpildÄ«ti ar nullēm. Tādējādi tests tika veikts vairāk nekā 100 gigabaitu nulles. Tā kā dati ir ļoti viendabÄ«gi un paredzami, tiek izmantotas dažādas OS optimizācijas, kas ievērojami paātrina izpildi.

Ja apŔaubāt visus sysbench rezultātus, varat izmantot 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

Pārbaude
IntelĀ® S4500
Samsung 970 EVO+

LasīŔana bez fsync, MiB/s
45.5
178

Ieraksts bez fsync, MiB/s
30.4
119

LasīŔana ar fsync, MiB/s
32.6
20.9

Ieraksts ar fsync, MiB/s
21.7
13.9

Ir skaidri redzama tendence pasliktināties NVMe veiktspējai, izmantojot fsync. Jūs varat pāriet uz atbildi uz otro jautājumu.

Optimizācija vai blefs

IepriekÅ” mēs teicām, ka dati tiek glabāti buferÄ«, bet mēs nenorādÄ«jām, kurÅ” no tiem, jo ā€‹ā€‹tas nebija svarÄ«gi. Pat tagad mēs neiedziļināsimies operētājsistēmu sarežģītÄ«bā un izcelsim divus vispārÄ«gus buferu veidus:

  • programma;
  • aparatÅ«ra.

Programmatūras buferis attiecas uz buferiem, kas pastāv operētājsistēmā, un aparatūras buferis attiecas uz diska kontrollera nepastāvīgo atmiņu. Fsync sistēmas izsaukums nosūta diskam komandu, lai rakstītu datus no tā bufera uz galveno krātuvi, bet nevar pārbaudīt, vai komanda ir izpildīta pareizi.

Tā kā SSD uzrāda vislabākos rezultātus, var izdarīt divus pieņēmumus:

  • disks ir paredzēts lÄ«dzÄ«gai slodzei;
  • disks "blefo" un ignorē komandu.

Piedziņas negodīgu rīcību var pamanīt, veicot jaudas zuduma testu. To var pārbaudīt ar skriptu diskchecker.pl, tas bija izveidots jo 2005 gadā.

Å im skriptam ir nepiecieÅ”amas divas fiziskas maŔīnas - ā€œserverisā€ un ā€œklientsā€. Klients ieraksta nelielu datu apjomu pārbaudāmajā diskā, izsauc fsync un nosÅ«ta serverim informāciju par rakstÄ«to.

# Š—Š°ŠæусŠŗŠ°ŠµŃ‚ся Š½Š° сŠµŃ€Š²ŠµŃ€Šµ
./diskchecker.pl -l [port]

# Š—Š°ŠæусŠŗŠ°ŠµŃ‚ся Š½Š° ŠŗŠ»ŠøŠµŠ½Ń‚Šµ
./diskchecker.pl -s <server[:port]> create <file> <size_in_MB>

Pēc skripta palaiÅ”anas jums ir jāizslēdz strāva "klientam" un vairākas minÅ«tes neatgrieziet baroÅ”anu. Ir svarÄ«gi atvienot pārbaudāmo personu no elektrÄ«bas, nevis tikai veikt spēcÄ«gu izslēgÅ”anu. Pēc kāda laika serveri var izveidot savienojumu un ielādēt OS. Pēc operētājsistēmas ielādes tā ir jāsāk no jauna diskchecker.pl, bet ar argumentu pārbaudÄ«t.

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

Pārbaudes beigās redzēsit kļūdu skaitu. Ja ir 0, disks ir izturējis pārbaudi. Lai izslēgtu diska laimīgo sakritību, eksperimentu var atkārtot vairākas reizes.

MÅ«su S4500 neuzrādÄ«ja kļūdas, kad tika zaudēta jauda, ā€‹ā€‹kas nozÄ«mē, ka tas ir gatavs darba slodzei ar daudziem fsync zvaniem.

Secinājums

Izvēloties diskus vai veselas gatavās konfigurācijas, jāatceras risināmo problēmu specifika. No pirmā acu uzmetiena Ŕķiet acÄ«mredzams, ka NVMe, tas ir, SSD ar PCIe interfeisu, ir ātrāks nekā ā€œklasiskaisā€ SATA SSD. Tomēr, kā mēs Å”odien uzzinājām, Ä«paÅ”os apstākļos un ar noteiktiem uzdevumiem tas var nebÅ«t.

Kā pārbaudīt servera komponentus, īrējot no IaaS pakalpojumu sniedzēja?
Gaidām jūs komentāros.

Kāpēc mans NVMe ir lēnāks nekā SSD?

Avots: www.habr.com

Pievieno komentāru