LINUX.ORG.RU
ФорумAdmin

SSD тестирование

 ,


0

2

Дали потестировать 5 штук SSD NVMe )))

Но какая то ерунда получается со скоростями. Скорость почти не отличается от обычного вита... Почему так?

есть SSD диск, создаю на нем ext3 и монтирую:

mkfs.ext3 /dev/nvme0n1 mount /dev/nvme0n1 /mnt

Запускаю dd:

sync; dd if=/dev/zero of=/mnt/test bs=1M count=1024; sync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 1.3259 s, 810 MB/s

Теперь то же самое на обычном харде в разделе /tmp:

sync; dd if=/dev/zero of=/tmp/test bs=1M count=1024; sync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 1.2151 s, 884 MB/s

Ну да немного быстрее но всего на ~10%...

В чем подвох? Может буфера мешают?...

★★

Теперь то же самое на обычном харде в разделе /tmp

Опустим обычную газету в серную кислоту, а ТВ-Парк - в дистиллированную воду.

/tmp в tmpfs монтируется.

Deleted
()
Ответ на: ЛУЛ от anonymous

Быстрее, но почти то же самое :(

Вот SDD:

sync; dd oflag=direct if=/dev/zero of=/mnt/test bs=1M count=1024; sync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 0.61965 s, 1.7 GB/s

А это простой хард:

sync; dd oflag=direct if=/dev/zero of=/tmp/test bs=1M count=1024; sync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 0.658395 s, 1.6 GB/s

qqqq ★★
() автор топика
Ответ на: комментарий от Deleted

Не везде, да и тормознутый тогда у ТС'а результат для tmpfs.

Deleted
()
Ответ на: комментарий от Deleted

Точно же )))

Попробовал на другой раздел:

Вот SSD:

sync; dd oflag=direct if=/dev/zero of=/mnt/test bs=1M count=1024; sync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 0.61366 s, 1.7 GB/s

А вот обычный хард (точнее рейд)

sync; dd oflag=direct if=/dev/zero of=/u02/test bs=1M count=1024; sync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 2.84214 s, 378 MB/s

Скорость, отличается в ~5 раз, ну уже все же лучше! )))

qqqq ★★
() автор топика
Последнее исправление: qqqq (всего исправлений: 1)

Теперь то же самое на обычном харде в разделе /tmp:

Как уже выше заметили, /tmp по дефолту монтируется в tmpfs. А по поводу скорости, задайте больше блоков для записи dd. К примеру, на 10ГБ. Тогда и значения скорости будут правдивыми. Потому как 810МБ/с - это какой-то убер-SSD. Вот пример моего SSD:

10000+0 records in
10000+0 records out
10485760000 bytes (10 GB, 9.8 GiB) copied, 62.6995 s, 167 MB/s

FluffyPillow
()
Ответ на: комментарий от qqqq

Что-то у вас оперативка медленная.

Deleted
()
Ответ на: комментарий от FluffyPillow

Увеличил до 10Gb, результат такой:

SSD

sync; dd oflag=direct if=/dev/zero of=/mnt/test bs=1M count=10240; sync 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 6.10846 s, 1.8 GB/s

Обычный хард:

sync; dd oflag=direct if=/dev/zero of=/u02/test bs=1M count=10240; sync 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 70.7857 s, 152 MB/s

Разница в 10 раз, это очень хорошо! )

qqqq ★★
() автор топика
Ответ на: комментарий от Pyzia

Файловай система ext3

C 512К получилось примерно то же самое, но лучше. До 6 раз подросла скорость SSD :)

SSD

sync; dd oflag=direct if=/dev/zero of=/mnt/test bs=512K count=20240; sync 20240+0 records in 20240+0 records out 10611589120 bytes (11 GB) copied, 5.91338 s, 1.8 GB/s

Обычный хард:

sync; dd oflag=direct if=/dev/zero of=/u02/test bs=512K count=20240; sync 20240+0 records in 20240+0 records out 10611589120 bytes (11 GB) copied, 34.811 s, 305 MB/s

qqqq ★★
() автор топика
Последнее исправление: qqqq (всего исправлений: 1)

Используй Bonnie++

anonymous
()
Ответ на: комментарий от FluffyPillow

Ну вот, какой дали поносить, такой и смотрю ))) Да наверное он стоит не слабо...

qqqq ★★
() автор топика

Попробуй так (на винте скорее всего не дождёшься, пока оно отработает):

fio --name 1 --direct 1 --ioengine sg --readwrite randread --io_limit 1g --filename /dev/sdX

anonymous
()
Ответ на: комментарий от anonymous

Тут другое любопытно, что при сборке софтверного RAID1 из SSD скорость падает! Причем линейно... )

Один диск: ====================== 10611589120 bytes (11 GB) copied, 5.91338 s, 1.8 GB/s

Два диска RAID1 ====================== 10611589120 bytes (11 GB) copied, 6.38046 s, 1.7 GB/s

Три диска RAID1 ======================= 10611589120 bytes (11 GB) copied, 6.90457 s, 1.5 GB/s

Четыре диска RAID1 ======================== 10611589120 bytes (11 GB) copied, 7.79742 s, 1.4 GB/s

Пять дисков RAID1 ========================== 10611589120 bytes (11 GB) copied, 8.20161 s, 1.3 GB/s

qqqq ★★
() автор топика
Последнее исправление: qqqq (всего исправлений: 3)

Совсем упоролись все. Никто про fio не знает, никто не знает, что линейная скорость ещё не самый важный показатель ?

Deleted
()

Так надо с NTFS тестить, линуксячьи фс слишком тормозные. Еще и 12309 поди 😄

ritsufag ★★★★★
()
Ответ на: комментарий от qqqq

Конечно падает, накладные расходы. Может ты хотел RAID0 замутить? Скорость для SSD он поднимет разве что линейную.

Pyzia ★★★★★
()
Ответ на: комментарий от Pyzia

RAID 0 как раз действительно показал очень хорошие результаты, правда больше двух дисков иметь в этом рейде бессмыссленно а RAID 5 вообще упал до уровня обычного харда...

Два диска RAID0 ========================== 10611589120 bytes (11 GB) copied, 4.38174 s, 2.4 GB/s

Три диска RAID0 =========================== 10611589120 bytes (11 GB) copied, 4.89217 s, 2.2 GB/s

Четыре диска RAID0 ============================ 10611589120 bytes (11 GB) copied, 4.19917 s, 2.5 GB/s

Пять дисков RAID0 ============================ 10611589120 bytes (11 GB) copied, 4.29476 s, 2.5 GB/s

RAID 5

Три диска RAID5 =========================== 10611589120 bytes (11 GB) copied, 30.9535 s, 343 MB/s

Четыре диска RAID5 ============================ 10611589120 bytes (11 GB) copied, 25.9202 s, 409 MB/s

Пять дисков RAID5 ============================ 10611589120 bytes (11 GB) copied, 35.8727 s, 296 MB/s

Так что для SSD рейда максимум 2,3 диска в RAID 0. Прочие конфигурации производительности не помогают....

qqqq ★★
() автор топика
Ответ на: комментарий от Deleted

Спасибо.

Ну вот как раз по рекомендации автора мы пошли по dd - way ))

hdparam тоже пробовал, но результаты сложно инетерпретировать... Данные примерно одинаковые.

qqqq ★★
() автор топика
Ответ на: комментарий от qqqq

Добавьте туда в комменты результаты измерений, думаю всем будет интересно сравнить.

Deleted
()
Ответ на: комментарий от Deleted

А ну это все для разработчиков. Софт уже написан, и код его закрыт... в этом проблема.

qqqq ★★
() автор топика
Ответ на: комментарий от qqqq

Ну вот как раз по рекомендации автора мы пошли по dd - way ))

Есть же православный fio

imul ★★★★★
()

1. Как уже написали — dd только с oflag=direct на запись и iflag=direct на чтение

2. /dev/zero плохо подходит для SSD, так как они умеют жать данные. обойти это можно так:

dd if=/dev/urandom of=/другой_диск/файл bs=1M count=1024 (без oflag/iflag, чтобы файл закешировался в оперативке. Для верности его можно ещё раз считать в /dev/null)

dd of=/другой_диск/файл of=/тестовый_диск/файл bs=1M count=1024 oflag=direct

3. У SSD дисков (особенно SATA/SAS) очень прыгает время доступа к ячейкам, соответственно RAID'ы из нескольких дисков будут иметь скорость самого медленного диска в текущий момент времени. Чем больше дисков, тем больше вероятность, что в любой момент времени будет «медленный» диск. Вероятность увеличивается при записи на массив и при использовании массивов со «штрафом» на запись RAID5/6

4. В теории можно попробовать юзать DAX на NVME SSD дисках, но толку особого с этого не будет. Оперативка всё равно на порядок быстрее по скорости и на два-три порядка быстрее по времени отклика.

chaos_dremel ★★
()
Последнее исправление: chaos_dremel (всего исправлений: 1)
Ответ на: комментарий от FluffyPillow

Потому как 810МБ/с - это какой-то убер-SSD.

...

Ну так конечно, убер-диск. :)

Вылазь уже из криокамеры. Никакого «убера», обычная скорость NVMe.
И не диск это, дебилбл. Даже внешне не похож на винчестер.

anonymous
()
Ответ на: комментарий от anonymous

Для nvme наоборот маловато.

Да, не ахти. Скорее всего на TLC. Разбираться лень.

anonymous
()
Ответ на: комментарий от qqqq

Интересно, что за уберсистема, к которой можно подключить 5 Nvme? Каждый ведь pcie3.0x4. Это ж для честного подключения надо аж 20 полос pcie3.0.

На самом деле Nvme даёт жару при параллельной нагрузке. А dd создает чисто последовательную нагрузку. А если размер блока в dd меньше размера страйпа, то нагрузка не параллелится по членам массива.

Вобщем фуфло это, а не испытания. Даёшь fio с рандомным доступом и высокой параллельностью.

iliyap ★★★★★
()
Ответ на: комментарий от anonymous

Решил сумничать? Не получилось. Сам себя идиотом показал. NVMe для простого смертного явно является «убером». Диск = устройство хранения данных. NVMe позволяет хранить данные. NVMe ~ Диск. Если так нравятся точные определения, то ты зря сюда пришёл.

FluffyPillow
()
Ответ на: комментарий от FluffyPillow

NVMe для простого смертного явно является «убером».

Это для такого сисадмина-анскилыша как ты, они являются «убером».
Гнать таких сисадминов надо ссаными тряпками.

Диск = устройство хранения данных. NVMe позволяет хранить данные. NVMe ~ Диск.

Тупой идиот. Ты наверное не знаешь, что в оригинале последнее «D» это Drive, а не Disk.

anonymous
()
Ответ на: комментарий от FluffyPillow

NVMe для простого смертного явно является «убером».

Ты, отупень, похоже не понял, что находишься на LOR-е в разделе Admin(!). Домохозяйкам, вроде тебя, здесь не место.

anonymous
()
Ответ на: комментарий от chaos_dremel

Да вы абсолютно правы. Очень правильное замечание.

Такие SSD дело для меня новое, неисследованное. Конечно если что то интересное обнаружу поделюсь. )))

qqqq ★★
() автор топика
Ответ на: комментарий от chaos_dremel

dd if=/dev/urandom of=/другой_диск/файл bs=1M count=1024 (без oflag/iflag, чтобы файл закешировался в оперативке. Для верности его можно ещё раз считать в /dev/null)

/dev/urandom очень замедлил вывод. Вот что вышло с /dev/null и =/dev/urandom на рейде 0 из 5 NVMe

sync; dd oflag=direct if=/dev/zero of=/mnt/test bs=512K count=20240; sync 20240+0 records in 20240+0 records out 10611589120 bytes (11 GB) copied, 4.413 s, 2.4 GB/s

sync; dd oflag=direct if=/dev/urandom of=/mnt/test bs=512K count=20240; sync ^C3624+1 records in 3624+0 records out 1900019712 bytes (1.9 GB) copied, 225.056 s, 8.4 MB/s

qqqq ★★
() автор топика
Ответ на: комментарий от FluffyPillow

Так и память - устройство для хранения данных ) NVMe не диск, а именно что ПАМЯТЬ )))

Есть еще более офигенная вещь, назвается NVDIMM. Это очень быстрая энергонезависимая память (RAM)! По идее с такой памятью вообще диски не нужны.

qqqq ★★
() автор топика
Ответ на: комментарий от FluffyPillow

Nvme у простых смертных в ноутбуках стоят, болезный.

anonymous
()
Ответ на: комментарий от qqqq

C urandom в несколько этапов надо делать.

Сначала генерится файл. Это долгий процесс. Для исключения влияния на тестируемый диск он генерится на любом другом диске. Потом сгенерированный файл прогоняется в null без oflag/iflag=direct, чтобы он записался в кеше в оперативке. И затем файл копируется из другого диска в тестируемый (фактически файл лежит в оперативке, соответственно скорость максимально возможная), с oflag=direct

chaos_dremel ★★
()
Последнее исправление: chaos_dremel (всего исправлений: 1)
Ответ на: комментарий от qqqq

Подозреваю, что для nvme размер блока при последовательной записи не имеет значения, он всё равно стэкует данные и пишет большим блоком у себя.

chaos_dremel ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.