Зашто је мој НВМе спорији од мог ССД-а?

У овом чланку ћемо погледати неке од нијанси И/О подсистема и њихов утицај на перформансе.

Пре пар недеља сам се суочио са питањем зашто је НВМе на једном серверу спорији од САТА на другом. Погледао сам спецификације сервера и схватио да је ово шкакљиво питање: НВМе је из сегмента корисника, а ССД из сегмента сервера.

Очигледно, није фер поредити производе из различитих сегмената у различитим окружењима, али ово није потпун технички одговор. Хајде да проучимо основе, спроведемо експерименте и дамо одговор на постављено питање.

Шта је фсинц и где се користи?

Да би се убрзао рад са диск јединицама, подаци се баферују, односно чувају у нестабилној меморији док се не укаже згодна прилика да се садржај бафера сачува на диск јединици. Критеријуми за „прилику“ одређују оперативни систем и карактеристике драјва. У случају нестанка струје, сви подаци у баферу ће бити изгубљени.

Постоји велики број задатака у којима морате да будете сигурни да су промене у датотеци записане на диск јединици, а не у међубаферу. Ова гаранција се може добити коришћењем ПОСИКС-компатибилног фсинц системског позива. Позивање фсинц присиљава уписивање из бафера у диск јединицу.

Хајде да демонстрирамо ефекат бафера на вештачком примеру у виду кратког програма у Ц.

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

Коментари добро објашњавају редослед радњи у програму. Текст „одговор на главно питање живота, универзума и свега тога“ ће бити баферован од стране оперативног система, а ако поново покренете сервер притиском на дугме Ресет током „калкулација“, датотека ће бити празна. У нашем примеру, губитак текста није проблем, тако да фсинц није потребан. Базе података не деле овај оптимизам.

Базе података су сложени програми који истовремено раде са више датотека, па желе да буду сигурни да ће подаци које пишу бити сачувани на диску, пошто од тога зависи конзистентност података унутар базе података. Базе података су дизајниране да евидентирају све завршене трансакције и да буду спремне да изгубе струју у било ком тренутку. Ово понашање захтева константну употребу фсинц у великим количинама.

Какав је ефекат честе употребе фсинц-а?

Током нормалног И/О, оперативни систем покушава да оптимизује комуникацију са дисковима, пошто су спољни дискови најспорији у хијерархији меморије. Због тога оперативни систем покушава да упише што више података у једном приступу диску.

Хајде да демонстрирамо утицај коришћења фсинц-а на конкретном примеру. Имамо следеће ССД дискове као пробне дискове:

• Интел® ДЦ ССД С4500 480 ГБ, повезан преко САТА 3.2, 6 Гбит/с;
• Самсунг 970 ЕВО Плус 500ГБ, повезан преко ПЦИе 3.0 к4, ~31 Гбит/с.

Тестови се спроводе на Интел® Ксеон® В-2255 који користи Убунту 20.04. Сисбенцх 1.0.18 се користи за тестирање дискова. Једна партиција је креирана на дисковима, форматирана као ект4. Припрема за тест укључује креирање датотека од 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

Резултати испитивања су приказани у табели.

Тест
Интел® С4500
Самсунг 970 ЕВО+

Читање без фсинц, МиБ/с
5734.89
9028.86

Снимање без фсинц, МиБ/с
3823.26
6019.24

Читање са фсинц, МиБ/с
37.76
3.27

Снимање са фсинц, МиБ/с
25.17
2.18

Лако је видети да је НВМе из сегмента клијената самоуверено у предности када сам оперативни систем одлучује како ће радити са дисковима, а губи када се користи фсинц. Ово поставља два питања:

1. Зашто брзина читања у тесту без фсинц премашује физички пропусни опсег канала?
2. Зашто је ССД сегмент сервера бољи у руковању великим бројем фсинц захтева?

Одговор на прво питање је једноставан: сисбенцх генерише датотеке испуњене нулама. Тако је тест обављен преко 100 гигабајта нула. Пошто су подаци веома уједначени и предвидљиви, разне оптимизације ОС долазе у обзир и значајно убрзавају извршење.

Ако доводите у питање све резултате сисбенцх-а, можете користити фио.

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

Тест
Интел® С4500
Самсунг 970 ЕВО+

Читање без фсинц, МиБ/с
45.5
178

Снимање без фсинц, МиБ/с
30.4
119

Читање са фсинц, МиБ/с
32.6
20.9

Снимање са фсинц, МиБ/с
21.7
13.9

Јасно је видљива тенденција да се перформансе НВМе деградирају када се користи фсинц. Можете прећи на одговор на друго питање.

Оптимизација или блеф

Раније смо рекли да се подаци чувају у баферу, али нисмо прецизирали који, јер то није важно. Чак ни сада нећемо улазити у замршености оперативних система и истаћи ћемо два општа типа бафера:

• програм;
• хардвер.

Софтверски бафер се односи на бафере који постоје у оперативном систему, а хардверски бафер се односи на нестабилну меморију контролера диска. Системски позив фсинц шаље команду драјву за писање података из свог бафера у главну меморију, али нема начина да провери да ли је команда исправно извршена.

Пошто ССД показује најбоље резултате, могу се направити две претпоставке:

• диск је дизајниран за слично оптерећење;
• диск "блефира" и игнорише команду.

Непоштено понашање погона може се приметити ако извршите тест губитка снаге. Ово можете проверити помоћу скрипте дискцхецкер.пл, то је било креирано у КСНУМКС године.

Ова скрипта захтева две физичке машине - „сервер“ и „клијент“. Клијент уписује малу количину података на диск који се тестира, позива фсинц и шаље серверу информације о томе шта је написано.

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

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

Након покретања скрипте, морате искључити напајање „клијента“ и не враћати напајање неколико минута. Важно је искључити особу која се тестира са струје, а не само извршити тешко искључивање. Након неког времена, сервер се може повезати и учитати у ОС. Након учитавања ОС-а морате га поново покренути дискцхецкер.пл, али са аргументом верификовати.

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

На крају провере видећете број грешака. Ако их има 0, диск је прошао тест. Да би се искључила срећна случајност за диск, експеримент се може поновити неколико пута.

Наш С4500 није показао грешке када је дошло до губитка напајања, што значи да је спреман за радна оптерећења са пуно фсинц позива.

Закључак

Када бирате дискове или читаве готове конфигурације, треба да запамтите специфичности проблема које треба решити. На први поглед делује очигледно да је НВМе, односно ССД са ПЦИе интерфејсом, бржи од „класичног“ САТА ССД-а. Међутим, како данас сазнајемо, у специфичним условима и са одређеним задацима то можда није случај.

Како тестирате компоненте сервера када изнајмљујете од ИааС провајдера?
Чекамо вас у коментарима.

Извор: ввв.хабр.цом