Как проверить производительность жесткого диска

Я бы не рекомендовал использовать / dev / urandom , потому что он программный и медленный как свинья. Лучше взять кусок случайных данных на ramdisk. При тестировании жесткого диска случайный выбор не имеет значения, потому что каждый байт записывается как есть (также на ssd с dd). Но если мы протестируем удаленный пул zfs с чистыми нулевыми или случайными данными, будет огромная разница в производительности.

Другая точка зрения должна заключаться во включении времени синхронизации; все современные файловые системы используют кэширование для файловых операций.

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

time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync"

с помощью этого метода вы получите вывод:

sync ; time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k  && sync" ; rm testfile 
1024+0 records in
1024+0 records out
104857600 bytes (105 MB) copied, 0.270684 s, 387 MB/s

real    0m0.441s
user    0m0.004s
sys 0m0.124s

, поэтому данные на диске составляют всего 104857600 / 0,441 = 237772335 бит / с -> 237 МБ / с

Это более чем на 100 МБ / с ниже чем с кешированием.

Удачного тестирования,

Суоминен прав, нам следует использовать какую-то синхронизацию; но есть более простой метод, conv = fdatasync выполнит эту работу:

dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output
1024+0records in
1024+0 records out
402653184 bytes (403 MB) copied, 3.19232 s, 126 MB/s

f3 - Борьба с мошенничеством со вспышкой

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

Подробнее о этот AU ответ.

Скорость записи

$ dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 4.82364 s, 223 MB/s

Размер блока на самом деле довольно большой. Вы можете попробовать с меньшими размерами, например, 64 КБ или даже 4 КБ.

Скорость чтения

Выполните следующую команду, чтобы очистить кеш памяти

$ sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"

Теперь прочтите файл, созданный в тесте записи:

$ dd if=./largefile of=/dev/null bs=4k
165118+0 records in
165118+0 records out
676323328 bytes (676 MB) copied, 3.0114 s, 225 MB/s

Если вы хотите контролировать скорость чтения и записи на диск в режиме реального времени, вы можете воспользоваться утилитой iotop.

Это полезно для получения информации о том, как диск работает для конкретного приложения или рабочей нагрузки. На выходе будет показана скорость чтения/записи для каждого процесса и общая скорость чтения/записи для сервера, аналогично top.

Установите iotop:

sudo apt-get install iotop  

Запустите его:

sudo iotop

Этот инструмент полезен для понимания того, как диск работает для конкретной рабочей нагрузки, в сравнении с более общими и теоретическими тестами.

bonnie++ - это последняя известная мне утилита-тестмаркер для linux.

(В настоящее время я готовлю linux livecd на работе с Bonnie++ для тестирования нашей Windows-машины!)

Она заботится о кэшировании, синхронизации, случайных данных, случайном расположении на диске, обновлениях небольшого размера, больших обновлениях, чтении, записи и так далее. Сравнение usbkey, жесткого диска (ротационного), твердотельного накопителя и файловой системы на основе ram может быть очень информативным для новичка.

Понятия не имею, включена ли она в Ubuntu, но вы можете легко скомпилировать ее из исходников.

http://www.coker.com.au/bonnie++/

Если вам нужна точность,вам следует использовать fio . Для этого необходимо прочитать руководство ( man fio ), но оно даст вам точные результаты. Обратите внимание, что для любой точности вам нужно точно указать, что вы хотите измерить. Некоторые примеры:

Скорость последовательного ЧТЕНИЯ с большими блоками (это должно быть около числа, которое вы видите в спецификациях вашего привода):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=read --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Скорость последовательной ЗАПИСИ с большими блоками (это должно быть около число, которое вы видите в спецификациях вашего накопителя):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=write --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Случайное чтение 4K QD1 (это число, которое действительно имеет значение для реальной производительности, если вы не знаете наверняка лучше):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Смешанное случайное чтение и запись 4K QD1 с синхронизацией (это наихудшее число, которое вы когда-либо ожидали от вашего диска, обычно менее 1% от чисел, перечисленных в спецификации):

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting

Увеличьте аргумент - размер для увеличения размера файла. Использование файлов большего размера может уменьшить получаемые числа в зависимости от технологии накопителя и прошивки. Маленькие файлы дадут «слишком хорошие» результаты для вращающихся носителей, потому что считывающей головке не нужно так сильно перемещаться. Если ваше устройство почти пусто, использование файла, достаточно большого, чтобы почти заполнить диск, даст вам худшее поведение для каждого теста. В случае SSD размер файла не имеет большого значения.

Однако обратите внимание, что для некоторых носителей размер файла не так важен, как общее количество байтов, записанных за короткое время. период . Например, некоторые твердотельные накопители имеют значительно более высокую производительность с предварительно удаленными блоками или могут иметь небольшую область флэш-памяти SLC, которая используется в качестве кеша записи, и производительность изменяется после заполнения кеша SLC (например, серия Samsung EVO с кешем SLC 20-50 ГБ) . В качестве другого примера, жесткие диски Seagate SMR имеют около 20 ГБ кэш-памяти PMR, которая имеет довольно высокую производительность, но как только она заполняется, запись непосредственно в область SMR может снизить производительность до 10% от исходной. И единственный способ увидеть это снижение производительности - сначала записать 20+ ГБ как можно быстрее и сразу же после этого продолжить настоящий тест. Конечно, все это зависит от вашей рабочей нагрузки: если ваш доступ для записи прерывистый с долгими задержками, которые позволяют устройству очистить внутренний кеш, более короткие тестовые последовательности будут лучше отражать вашу реальную производительность. Если вам нужно выполнять много операций ввода-вывода, вам нужно увеличить оба параметра - io_size и - runtime . Обратите внимание, что некоторые носители (например, большинство дешевых флэш-устройств) пострадают от такого тестирования, потому что микросхемы флэш-памяти достаточно плохи, чтобы изнашиваться очень быстро. На мой взгляд, если какое-либо устройство недостаточно бедно, чтобы не проводить такого рода тестирование, его ни в коем случае не следует использовать для хранения каких-либо ценных данных. Тем не менее, не повторяйте большие тесты записи 1000 раз, потому что все флеш-ячейки будут иметь некоторый уровень износа при записи.

Кроме того, некоторые высококачественные SSD-устройства могут иметь даже более интеллектуальные алгоритмы выравнивания износа, когда внутренний кеш SLC имеет достаточно умных средств, чтобы заменить данные на месте, которые перезаписываются во время теста, если они попадают в то же адресное пространство (то есть, если тестовый файл меньше, чем общий кэш SLC, устройство всегда записывает только в кеш SLC). Для таких устройств размер файла снова начинает иметь значение. Если вам нужна реальная рабочая нагрузка, лучше всего протестировать с размерами файлов, которые вы действительно увидите в реальной жизни. В противном случае ваши числа могут выглядеть слишком хорошо.

Обратите внимание, что fio создаст требуемый временный файл при первом запуске. Он будет заполнен случайными данными, чтобы избежать получения слишком хороших чисел от устройств, которые пытаются обмануть результаты тестов путем сжатия данных перед их записью в постоянное хранилище. В приведенных выше примерах временный файл будет называться fio-tempfile.dat и храниться в текущем рабочем каталоге. Поэтому сначала вам следует перейти в каталог, который смонтирован на устройстве, которое вы хотите протестировать. fio также поддерживает использование прямого носителя в качестве тестовой цели, но я определенно рекомендую прочитать страницу руководства, прежде чем пытаться это сделать, потому что опечатка может перезаписать всю вашу операционную систему при использовании прямого доступа к носителю (например, запись на устройство ОС вместо тестового устройства).

Если у вас хороший SSD и вы хотите увидеть еще более высокие цифры, увеличьте - numjobs выше. Это определяет параллелизм для чтения и записи. Во всех приведенных выше примерах для numjobs установлено значение 1 , поэтому тест касается чтения и записи однопоточного процесса (возможно, с очередью, установленной с помощью iodepth ). Высококачественные твердотельные накопители (например, Intel Optane 905p) должны получать большие числа даже без значительного увеличения числовых значений (например, 4 должно быть достаточно, чтобы получить самые высокие значения спецификаций), но некоторые твердотельные накопители «Enterprise» требуется перейти в диапазон 32 - 128 , чтобы получить номера спецификаций, потому что внутренняя задержка этих устройств выше, но общая пропускная способность безумна.

некоторые подсказки по использованию bonnie++

bonnie++ -d [TEST_LOCATION] -s [TEST_SIZE] -n 0 -m [TEST_NAME] -f -b -u [TEST_USER] 
bonnie++ -d /tmp -s 4G -n 0 -m TEST -f -b -u james

Немного больше: SIMPLE BONNIE++ EXAMPLE.