Я тестирую небольшую серверную коробку на основе SuperMicro E300-8D. Я установил последнюю версию CentOS 7.5 с последними обновлениями, 64 ГБ оперативной памяти DDR4-2100 и SSD-накопитель NVMe Samsung 970 EVO емкостью 1 ТБ. ОС устанавливается на USB-накопитель во внутренний USB-порт, поэтому SSD полностью не используется, кроме как во время моего тестирования.

Цель моего тестирования - найти оптимальный уровень параллелизма для этого SSD, вдохновленный подходом к тестированию, используемым ScyllaDB. С этой целью я использую дископтер который внутренне использует fio чтобы изучить взаимосвязь между параллелизмом и IOPS и задержкой. Он создает удобные графики, подобные приведенным ниже. Во всех случаях я использую рабочую нагрузку случайного чтения 4K.

Проблема в том, что я получаю бессмысленные результаты. Вот первый результат:

Сырье /dev/nvme0n1

$ sudo ./diskplorer.py --device=/dev/nvme0n1 --filesize=256G 

Это фантастика! Собственная спецификация Samsung утверждает, что IOPS при чтении составляет 500 тыс., А при 20 одновременных операциях чтения я получаю почти 600 тыс. Операций чтения. Ось справа - задержка чтения в наносекундах, красная линия - средняя задержка, а полосы ошибок - задержка 5% и 95%. Таким образом, похоже, что идеальный уровень параллелизма для этого SSD составляет около 20 одновременных чтений, что дает потрясающую задержку <100 мкс.

Это просто необработанный SSD. Я поставлю на него XFS, который оптимизирован для асинхронного ввода-вывода, и я уверен, что это не добавит значительных накладных расходов ...

С новой файловой системой XFS на /dev/nvme0n1

$ sudo mkfs.xfs /dev/nvme0n1
$ sudo mount /dev/nvme0n1 /mnt
$ sudo ./diskplorer.py --mountpoint=/mnt --filesize=256G 

Какой!? Это ужасно! Похоже, XFS привнесла абсурдную задержку и резко снизила количество операций ввода-вывода в секунду. Что могло быть не так?

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

XFS на /dev/nvme0n1 после перезагрузки

$ sudo shutdown -r now
(reboot happens)
$ sudo mount /dev/nvme0n1 /mnt
$ sudo ./diskplorer.py --mountpoint=/mnt --filesize=256G 

Без изменений. Это не связано с кешем.

На данный момент существует действующая файловая система XFS на /dev/nvme0n1, и он установлен на /mnt. Я собираюсь повторить тест, который я сделал вначале, на размонтированном необработанном блочном устройстве, оставив при этом содержимое файловой системы XFS на месте.

Сырье /dev/nvme0n1 очередной раз

$ sudo umount /mnt
$ sudo ./diskplorer.py --device=/dev/nvme0n1 --filesize=256G 

О нет, XFS испортила производительность моего SSD! /sarcasm

Ясно, что дело не в том, что XFS дьявольски испортила производительность моего SSD или что XFS плохо подходит для этой рабочей нагрузки. Но что это могло быть? Даже если размонтировать диск, чтобы XFS не использовалась, производительность кажется значительно сниженной?

Догадываясь, я попробовал DISCARDвсе содержимое SSD, которое должно сбросить распределение ячеек на диске в исходное состояние ...

Сырье /dev/nvme0n1 после blkdiscard

$ sudo blkdiscard /dev/nvme0n1
$ sudo ./diskplorer.py --device=/dev/nvme0n1 --filesize=256G

Чудом у меня SSD восстановилась работоспособность. Весь мир сошел с ума?

На основе предложения @shodanshok, что, если я сделаю dd на SSD после того, как я "починил" его, выполнив blkdiscard?

Сырье /dev/nvme0n1 после blkdiscard затем обнуляется с помощью dd

$ sudo blkdiscard /dev/nvme0n1
$ sudo dd if=/dev/zero of=/dev/nvme0n1 bs=1M status=progress oflag=direct
$ sudo ./diskplorer.py --device=/dev/nvme0n1 --filesize=256G 

Это интересный результат, который подтверждает мою уверенность в том, что XFS не виноват. Простое заполнение SSD нулями приводит к значительному снижению задержки чтения и пропускной способности. Так что, должно быть, сам SSD имеет некоторый оптимизированный путь чтения для нераспределенных секторов.

Гипотеза

Ясно, что XFS не убивает мой SSD, и если бы это было так, blkdiscard не восстанавливает его волшебным образом. Я еще раз подчеркиваю, что все эти тесты читать тесты, поэтому проблемы с журналированием записи, усилением записи, выравниванием износа и т. д. не применимы.

Моя теория заключается в том, что этот SSD и, возможно, SSD в целом имеют оптимизацию пути чтения, которая обнаруживает чтение нераспределенной области диска и выполняет высоко оптимизированный путь кода, который отправляет все нули обратно по шине PCIe.

Мой вопрос: кто-нибудь знает, правильно ли это? Если да, то являются ли обычно подозрительными тесты новых SSD без файловых систем, и документировано ли это где-нибудь? Если это неверно, есть ли у кого-нибудь другое объяснение этих странных результатов?