Зошто мојот NVMe е побавен од мојот SSD?

Во оваа статија ќе разгледаме некои од нијансите на потсистемот В/И и нивното влијание врз перформансите.

Пред неколку недели се соочив со прашањето зошто NVMe на еден сервер беше побавен од SATA на друг. Ги погледнав спецификациите на серверот и сфатив дека ова е незгодно прашање: NVMe беше од корисничкиот сегмент, а SSD беше од сегментот на серверот.

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

Што е fsync и каде се користи?

За да се забрза работата со дискови, податоците се чуваат во бафер, односно се чуваат во испарлива меморија додека не се појави пригодна можност да се зачува содржината на баферот на уредот. Критериумите за „можност“ се одредуваат според оперативниот систем и карактеристиките на погонот. Во случај на прекин на електричната енергија, сите податоци во баферот ќе бидат изгубени.

Постојат голем број задачи во кои треба да бидете сигурни дека промените на датотеката се запишани на уредот, а не во среден бафер. Ова уверување може да се добие со користење на системски повик fsync во согласност со POSIX. Повикувањето на 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?

При нормален влез/излез, оперативниот систем се обидува да ја оптимизира комуникацијата со дисковите, бидејќи надворешните погони се најбавни во хиерархијата на меморијата. Затоа, оперативниот систем се обидува да напише што е можно повеќе податоци во еден пристап до дискот.

Ајде да го демонстрираме влијанието на користењето на fsync со конкретен пример. Ги имаме следниве SSD-дискови како тест дискови:

• Intel® DC SSD S4500 480 GB, поврзан преку SATA 3.2, 6 Gbit/s;
• Samsung 970 EVO Plus 500GB, поврзан преку PCIe 3.0 x4, ~31 Gbit/s.

Тестовите се спроведуваат на Intel® Xeon® W-2255 со Ubuntu 20.04. Sysbench 1.0.18 се користи за тестирање на дискови. На дисковите е креирана една партиција, форматирана како ext4. Подготовката за тестот вклучува создавање датотеки од 100 GB:

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

Тенденцијата за деградирање на перформансите на 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?
Ве очекуваме во коментари.

Извор: www.habr.com