🥇Защо моят 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;
}

Коментарите добре обясняват последователността на действията в програмата. Текстът ‘отговор на основния въпрос за живота, Вселената и всичко останало’ ще бъде буфериран от операционната система, и ако рестартирате сървъра, натискайки бутона за нулиране по време на ‘изчисленията’, файлът ще остане празен. В нашия пример загубата на текст не е проблем, така че fsync не е необходим. Базите данни не споделят такъв оптимизъм.

Базите данни са сложни програми, които работят едновременно с много файлове, поради което искат да са сигурни, че записваните от тях данни ще бъдат запазени на носителя, тъй като от това зависи последователността на данните в БД. Базите данни са проектирани да записват всички завършени транзакции и да бъдат готови за загуба на захранване по всяко време. Такова поведение налага постоянно използване на fsync в големи количества.

Какво оказва влияние честото използване на fsync

При нормален вход-изход операционната система се стреми да оптимизира комуникацията с дисковете, тъй като във иерархията на паметта външните носители са най-бавните. Затова операционната система се опитва да запише възможно най-много данни с едно искане към носителя.

Нека демонстрираме влиянието на използването на fsync с конкретен пример. В нашето изследване имаме следните SSD носители:

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. За тестовете на дисковете се използва 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, МиБ/с
5734.89
9028.86

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

Четене с fsync, МиБ/с
37.76
3.27

Запис с fsync, МиБ/с
25.17
2.18

Не е трудно да се забележи, че NVMe от клиентския сегмент уверено води, когато операционната система сама решава как да работи с дисковете, и губи, когато се използва fsync. Оттук произлизат два въпроса:

Защо в теста без fsync скоростта на четене надвишава физическата пропускна способност на канала?
Защо 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 е добре забележима. Можем да преминем към отговора на втория въпрос.

Оптимизация или bluff

По-рано говорехме, че данните се съхраняват в буфер, но не уточнихме в какъв точно, тъй като това не беше принципно. И сега няма да се задълбочаваме в нюансите на операционните системи и ще изолира две общи вида буфери:

софтуерни;
хардуерни.

Под буфером в операционной системе подразумеваются буферы, а под аппаратным - энергозависимая память контроллера диска. Системный вызов fsync отправляет команде накопителя указание записать данные из его буфера в основное хранилище, но не может контролировать корректность выполнения этой команды.

Поскольку SSD показывают лучшие результаты, можно сделать два предположения:

диск спроектирован под нагрузку подобного рода;
диск «блефует» и игнорирует команду.

Нечестное поведение накопителя можно заметить, если провести тест с отключением питания. Проверить это можно с помощью скрипта diskchecker.pl, который был създаден в 2005 году.

Данный скрипт требует две физические машины — «сервер» и «клиент». Клиент записывает небольшое количество данных на тестируемый диск, вызывает fsync и отправляет серверу информацию о том, что было записано.

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

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

После запуска скрипта необходимо отключить «клиента» от питания и не возвращать его в течение нескольких минут. Важно именно отключить тестируемый от электричества, а не просто выполнить жесткое выключение. По истечении некоторого времени сервер можно подключить и загрузить в ОС. После загрузки ОС необходимо снова запустить diskchecker.pl, но с аргументом verify.

.\/diskchecker.pl -s  verify

В конце проверки вы увидите количество ошибок. Если ошибок нет, значит, диск успешно выдержал испытание. Для исключения удачного для диска стечения обстоятельств опыт можно повторить несколько раз.

Наш S4500 не показал ошибок при потере питания, что позволяет утверждать, что он готов к нагрузкам с большим количеством вызовов fsync.

Заключение

При выборе дисков или целых готовых конфигураций стоит помнить о специфике задач, которые необходимо решить. На первый взгляд кажется очевидным, что NVMe, то есть SSD с PCIe-интерфейсом, быстрее «классического» SATA SSD. Однако, как мы сегодня поняли, это может не всегда быть верно при специфических условиях и определённых задачах.

А как вы тестируете комплектующие серверов при аренде у IaaS-провайдера?
Ждем вас в комментариях.

Източник: habr.com