Чаму мой NVMe павольней SSD?

У дадзеным артыкуле мы разгледзім некаторыя нюансы падсістэмы ўводу-вываду і іх уплыў на прадукцыйнасць.

Пару тыдняў таму я сутыкнуўся з пытаннем, чаму 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;
}

Каментары добра тлумачаць паслядоўнасць дзеянняў у праграме. Тэкст "адказ на галоўнае пытанне жыцця, Сусвету і ўсяго такога" будзе буферызаваны аперацыйнай сістэмай, і калі перазагрузіць сервер націскам на кнопку Reset падчас "вылічэнняў", то файл апынецца пусты. У нашым прыкладзе страта тэксту не з'яўляецца праблемай, таму fsync не патрэбен. Базы дадзеных такога аптымізму не падзяляюць.

Базы дадзеных - гэта складаныя праграмы, якія адначасова працуюць з мноствам файлаў, таму жадаюць быць упэўненымі, што якія запісваюцца імі дадзеныя будуць захаваны на назапашвальніку, бо ад гэтага залежыць кансістэнтнасць дадзеных усярэдзіне БД. Базы даных спраектаваны запісваць усе завершаныя транзакцыі і быць гатовымі да адключэння харчавання ў любы момант. Такія паводзіны абавязваюць выкарыстоўваць fsync увесь час у вялікіх колькасцях.

На што ўплывае частае выкарыстанне fsync

Пры звычайным уводзе-выснове аперацыйная сістэма імкнецца аптымізаваць зносіны з дыскамі, бо ў іерархіі памяці вонкавыя назапашвальнікі самыя павольныя. Таму аперацыйная сістэма імкнецца за адзін зварот да назапашвальніка запісаць як мага больш дадзеных.

Прадэманструем уплыў выкарыстання fsync на пэўным прыкладзе. У якасці падыспытных у нас наступныя цвёрдацельныя назапашвальнікі:

• Intel DC SSD S4500 480 GB, падлучаны па SATA 3.2, 6 Гбіт / с;
• Samsung 970 EVO Plus 500GB, падлучаны па PCIe 3.0 x4, ~31 Гбіт / с.

Тэсты праводзяцца на Intel Xeon W-2255 пад кіраваннем АС Ubuntu 20.04/1.0.18. Для тэсціравання дыскаў выкарыстоўваецца sysbench 4. На дысках створаны адзін раздзел, адфарматаваны як ext100. Падрыхтоўка да тэсту заключаецца ў стварэнні файлаў аб'ёмам у XNUMX ГБ:

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, МіБ / с
5734.89
9028.86

Запіс без fsync, МіБ/с
3823.26
6019.24

Чытанне з fsync, МіБ / с
37.76
3.27

Запіс з fsync, МіБ/с
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, МіБ / с
45.5
178

Запіс без fsync, МіБ/с
30.4
119

Чытанне з fsync, МіБ / с
32.6
20.9

Запіс з fsync, МіБ/с
21.7
13.9

Тэндэнцыя да прасадкі прадукцыйнасці ў NVMe пры выкарыстанні fsync добра прыкметная. Можна пераходзіць да адказу на другое пытанне.

Аптымізацыя або блеф

Раней мы казалі, што дадзеныя захоўваюцца ў буферы, але не ўдакладнялі ў якім менавіта, бо гэта было не прынцыпова. Мы і зараз не будзем паглыбляцца ў тонкасці аперацыйных сістэм і вылучым два агульныя выгляду буфераў:

• праграмны;
• апаратны.

Пад праграмным буферам маюцца на ўвазе буферы, якія ёсць у аперацыйнай сістэме, а пад апаратным - энергазалежная памяць кантролера дыска. Сістэмны выклік 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, гэта значыць SSD з PCIe-інтэрфейсам, хутчэй "класічнага" SATA SSD. Аднак, як мы зразумелі сёньня, у спэцыфічных умовах і з пэўнымі задачамі гэта можа быць ня так.

А як вы тэстуеце камплектавалыя сервераў пры арэндзе ў IaaS-правайдэра?
Чакаем вас у каментарах.

Крыніца: habr.com