Ինչու՞ է իմ NVMe-ն ավելի դանդաղ, քան SSD-ը:

Այս հոդվածում մենք կդիտարկենք I/O ենթահամակարգի որոշ նրբերանգներ և դրանց ազդեցությունը կատարողականի վրա:

Մի քանի շաբաթ առաջ ես բախվեցի այն հարցին, թե ինչու է NVMe-ն մի սերվերի վրա ավելի դանդաղ, քան SATA-ն մյուսի վրա: Ես նայեցի սերվերի բնութագրերին և հասկացա, որ սա բարդ հարց էր. NVMe-ն օգտատերերի հատվածից էր, իսկ SSD-ը՝ սերվերի հատվածից:

Ակնհայտ է, որ ազնիվ չէ համեմատել տարբեր սեգմենտների արտադրանքները տարբեր միջավայրերում, բայց սա ամբողջական տեխնիկական պատասխան չէ: Եկեք ուսումնասիրենք հիմունքները, կատարենք փորձեր և պատասխան տանք տրված հարցին.

Ի՞նչ է fsync-ը և որտեղ է այն օգտագործվում:

Սկավառակների հետ աշխատանքը արագացնելու համար տվյալները բուֆերացվում են, այսինքն՝ պահվում են անկայուն հիշողության մեջ, մինչև բուֆերի պարունակությունը սկավառակում պահելու հարմար հնարավորություն հայտնվի: «Հնարավորության» չափանիշները որոշվում են օպերացիոն համակարգով և սկավառակի բնութագրերով: Էլեկտրաէներգիայի խափանման դեպքում բուֆերի բոլոր տվյալները կկորչեն:

Կան մի շարք առաջադրանքներ, որոնցում դուք պետք է վստահ լինեք, որ ֆայլի փոփոխությունները գրված են դրայվում և ոչ թե միջանկյալ բուֆերում: Այս երաշխիքը կարելի է ստանալ՝ օգտագործելով POSIX-ին համապատասխան fsync համակարգի զանգը: Fsync-ը կանչելը ստիպում է գրել բուֆերից դեպի սկավառակ:

Եկեք արհեստական ​​օրինակով ցույց տանք բուֆերների ազդեցությունը կարճ ծրագրի տեսքով 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;
}

Մեկնաբանությունները լավ բացատրում են ծրագրում գործողությունների հաջորդականությունը։ «Կյանքի, Տիեզերքի և այդ ամենի հիմնական հարցի պատասխանը» տեքստը կփակվի օպերացիոն համակարգի կողմից, և եթե «հաշվարկների ժամանակ» սեղմելով «Վերագործարկեք» կոճակը, ֆայլը դատարկ կլինի, եթե վերագործարկեք սերվերը: Մեր օրինակում տեքստի կորուստը խնդիր չէ, ուստի fsync-ի կարիքը չկա: Տվյալների բազաները չեն կիսում այս լավատեսությունը:

Տվյալների բազաները բարդ ծրագրեր են, որոնք միաժամանակ աշխատում են բազմաթիվ ֆայլերի հետ, ուստի նրանք ցանկանում են վստահ լինել, որ իրենց գրած տվյալները կպահվեն սկավառակի վրա, քանի որ տվյալների բազայի ներսում տվյալների հետևողականությունը կախված է դրանից: Տվյալների շտեմարանները նախատեսված են բոլոր ավարտված գործարքները գրանցելու և ցանկացած պահի պատրաստ լինելու կորցնելու հզորությունը: Այս վարքագիծը պահանջում է fsync-ի օգտագործումը մշտապես մեծ քանակությամբ:

Ի՞նչ ազդեցություն է ունենում fsync-ի հաճախակի օգտագործումը:

Սովորական I/O-ի ժամանակ օպերացիոն համակարգը փորձում է օպտիմալացնել սկավառակների հետ շփումը, քանի որ արտաքին կրիչներն ամենադանդաղն են հիշողության հիերարխիայում: Հետեւաբար, օպերացիոն համակարգը փորձում է հնարավորինս շատ տվյալներ գրել սկավառակի մեկ մուտքի մեջ:

Եկեք ցույց տանք fsync-ի օգտագործման ազդեցությունը կոնկրետ օրինակով: Որպես թեստային կրիչներ ունենք հետևյալ SSD-ները.

• Intel® DC SSD S4500 480 ԳԲ, միացված SATA 3.2-ի միջոցով, 6 Գբիտ/վրկ;
• Samsung 970 EVO Plus 500 ԳԲ, միացված է PCIe 3.0 x4-ի միջոցով, ~31 Գբիտ/վ:

Փորձարկումներն անցկացվում են Intel® Xeon® W-2255-ի վրա, որն աշխատում է Ubuntu 20.04-ով: Sysbench 1.0.18-ն օգտագործվում է սկավառակների փորձարկման համար: Սկավառակների վրա ստեղծվել է մեկ բաժանում՝ ext4 ձևաչափով: Թեստի նախապատրաստումը ներառում է 100 ԳԲ ֆայլերի ստեղծում.

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

Վազքի թեստեր.

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

Թեստի արդյունքները ներկայացված են աղյուսակում:

Փորձարկում
Intel® S4500
Samsung 970 EVO+

Ընթերցանություն առանց fsync, MiB/s
5734.89
9028.86

Ձայնագրում առանց fsync, MiB/s
3823.26
6019.24

Ընթերցանություն fsync-ով, MiB/s
37.76
3.27

Ձայնագրում fsync, MiB/s-ով
25.17
2.18

Հեշտ է տեսնել, որ հաճախորդի հատվածից NVMe-ն վստահորեն առաջատար է, երբ օպերացիոն համակարգն ինքն է որոշում, թե ինչպես աշխատել սկավառակների հետ, և կորցնում է, երբ օգտագործվում է fsync: Սա երկու հարց է առաջացնում.

1. Ինչո՞ւ է առանց fsync-ի թեստի ընթերցման արագությունը գերազանցում ալիքի ֆիզիկական թողունակությունը:
2. Ինչու՞ է սերվերի հատվածի SSD-ն ավելի լավ մշակել մեծ թվով fsync հարցումներ:

Առաջին հարցի պատասխանը պարզ է՝ sysbench-ը ստեղծում է զրոներով լցված ֆայլեր։ Այսպիսով, փորձարկումն իրականացվել է ավելի քան 100 գիգաբայթ զրո: Քանի որ տվյալները շատ միատեսակ և կանխատեսելի են, ՕՀ-ի տարբեր օպտիմիզացումներ են գործում և զգալիորեն արագացնում են կատարումը:

Եթե ​​կասկածի տակ եք դնում բոլոր sysbench արդյունքները, կարող եք օգտագործել 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

Փորձարկում
Intel® S4500
Samsung 970 EVO+

Ընթերցանություն առանց fsync, MiB/s
45.5
178

Ձայնագրում առանց fsync, MiB/s
30.4
119

Ընթերցանություն fsync-ով, MiB/s
32.6
20.9

Ձայնագրում fsync, MiB/s-ով
21.7
13.9

Fsync-ի օգտագործման ժամանակ NVMe-ի կատարողականի վատթարացման միտումը հստակ տեսանելի է: Կարող եք անցնել երկրորդ հարցին պատասխանելուն։

Օպտիմալացում կամ բլեֆ

Նախկինում մենք ասում էինք, որ տվյալները պահվում են բուֆերում, բայց չենք նշել, թե որն է, քանի որ դա կարևոր չէ։ Նույնիսկ հիմա մենք չենք խորանա օպերացիոն համակարգերի խճճվածությունների մեջ և կնշենք բուֆերների երկու ընդհանուր տեսակ.

• ծրագիր;
• ապարատային.

Ծրագրային ապահովման բուֆերը վերաբերում է օպերացիոն համակարգում գոյություն ունեցող բուֆերներին, իսկ ապարատային բուֆերը վերաբերում է սկավառակի կարգավորիչի անկայուն հիշողությանը: Fsync համակարգի կանչը հրաման է ուղարկում սկավառակին՝ իր բուֆերից տվյալները հիմնական պահեստարան գրելու համար, բայց ոչ մի միջոց չունի ստուգելու, որ հրամանը ճիշտ է կատարվել:

Քանի որ SSD-ը ցույց է տալիս լավագույն արդյունքները, կարելի է երկու ենթադրություն անել.

• սկավառակը նախատեսված է նմանատիպ բեռի համար.
• սկավառակը «բլեֆ է անում» և անտեսում հրամանը:

Սկավառակի անազնիվ վարքագիծը կարելի է նկատել, եթե դուք անցկացնեք հոսանքի կորստի փորձարկում: Դուք կարող եք դա ստուգել սցենարով diskchecker.plորը եղել է ստեղծվել է ի 2005 թ.

Այս սցենարը պահանջում է երկու ֆիզիկական մեքենա՝ «սերվեր» և «հաճախորդ»: Հաճախորդը գրում է փոքր քանակությամբ տվյալներ փորձարկվող սկավառակի վրա, զանգում է fsync և սերվերին ուղարկում տեղեկատվություն գրվածի մասին:

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

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

Սցենարը գործարկելուց հետո դուք պետք է անջատեք «հաճախորդին» հոսանքը և մի քանի րոպե չվերադարձնեք հոսանքը: Կարևոր է անջատել փորձարկվող անձին էլեկտրաէներգիայից, այլ ոչ թե պարզապես կոշտ անջատում կատարել: Որոշ ժամանակ անց սերվերը կարող է միացվել և բեռնվել ՕՀ-ում: ՕՀ-ը բեռնելուց հետո անհրաժեշտ է այն նորից սկսել diskchecker.pl, բայց փաստարկով ստուգել.

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

Ստուգման վերջում կտեսնեք սխալների քանակը: Եթե ​​կա 0, ապա սկավառակը անցել է թեստը: Սկավառակի համար հաջող զուգադիպությունը բացառելու համար փորձը կարելի է մի քանի անգամ կրկնել։

Մեր S4500-ը ոչ մի սխալ ցույց չի տվել, երբ հոսանքազրկվել է, ինչը նշանակում է, որ այն պատրաստ է ծանրաբեռնվածության՝ բազմաթիվ fsync զանգերով:

Ամփոփում

Սկավառակներ կամ ամբողջական պատրաստի կոնֆիգուրացիաներ ընտրելիս պետք է հիշել այն խնդիրների առանձնահատկությունները, որոնք պետք է լուծվեն: Առաջին հայացքից ակնհայտ է թվում, որ NVMe-ն, այսինքն՝ PCIe ինտերֆեյսով SSD-ն ավելի արագ է, քան «դասական» SATA SSD-ը։ Սակայն, ինչպես այսօր տեղեկացանք, կոնկրետ պայմաններում և որոշակի առաջադրանքների դեպքում դա կարող է չլինել։

Ինչպե՞ս եք ստուգում սերվերի բաղադրիչները IaaS մատակարարից վարձելիս:
Սպասում ենք ձեզ մեկնաբանություններում։

Source: www.habr.com