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

Как проверить производительность жесткого диска (либо через терминал, либо через графический интерфейс). Скорость записи. Скорость чтения. Размер и скорость кэша. Случайная скорость.

Терминальный способ

hdparm это хорошее место для начала.

sudo hdparm -Tt /dev/sda/dev/sda:Timing cached reads:   12540 MB in  2.00 seconds = 6277.67 MB/secTiming buffered disk reads: 234 MB in  3.00 seconds =  77.98 MB/sec

sudo hdparm -v /dev/sda также будет предоставлена информация.

dd даст вам информацию о скорости записи.

Если на диске нет файловой системы (и только тогда), использовать of=/dev/sda.

В противном случае смонтируйте его в /tmp и запишите, а затем удалите выходной файл теста.

dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output10240+0 records in10240+0 records out83886080 bytes (84 MB) copied, 1.08009 s, 77.7 MB/s

Графический метод

  1. >>Перейдите в раздел "Система - Администрирование - Дисковая утилита".
    • В качестве альтернативы запустите дисковую утилиту Gnome из командной строки, выполнив gnome-disks
  2. Выберите свой жесткий диск на левой панели.
  3. Теперь нажмите кнопку “Бенчмарк – Измерение производительности диска” на правой панели.
  4. Откроется новое окно с графиками.Вы найдете и две кнопки. Один предназначен для “Запуска теста только для чтения”, а другой - для “Запуска теста чтения / записи”. Когда вы нажимаете на любую кнопку, она запускает сравнительный анализ жесткого диска.

test

Как протестировать дисковый ввод-вывод

Статья

Есть ли что-то еще, чего ты хочешь?

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

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

Если вы хотите точности, вы должны использовать 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

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

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

Кроме того, некоторые высококачественные твердотельные накопители могут иметь еще более интеллектуальные алгоритмы выравнивания износа, в которых внутренний кэш SLC обладает достаточными возможностями для замены данных на месте, если они перезаписываются, пока данные все еще находятся в кэше SLC. Для таких устройств, если тестовый файл меньше, чем общий кэш SLC устройства, полный тест всегда записывает только в кэш SLC, и вы получаете более высокие показатели производительности, чем устройство может поддерживать при больших объемах записи. Таким образом, для таких устройств размер файла снова начинает иметь значение. Если вы знаете свою фактическую рабочую нагрузку, лучше всего протестировать с теми размерами файлов, которые вы действительно увидите в реальной жизни. Если вы не знаете ожидаемую рабочую нагрузку, использование тестового размера файла, который заполняет около 50% устройства хранения, должно привести к хорошему среднему результату для всех реализаций хранилища. Конечно, для настройки RAID объемом 50 ТБ выполнение теста на запись с тестовым файлом объемом 25 ТБ займет довольно много времени!

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

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

Я бы не рекомендовал использовать /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 in1024+0 records out104857600 bytes (105 MB) copied, 0.270684 s, 387 MB/sreal    0m0.441suser    0m0.004ssys 0m0.124s

>таким образом, скорость передачи данных на диске составляет всего 104857600 / 0,441 = 237772335 Бит/с - 237 МБ/с.

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

Счастливый бенчмаркинг,

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

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

Устанавливать iotop:

sudo apt-get install iotop  

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

sudo iotop

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

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

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

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


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

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

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

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

$ dd if=./largefile of=/dev/null bs=4k165118+0 records in165118+0 records out676323328 bytes (676 MB) copied, 3.0114 s, 225 MB/s

bonnie++ - это лучшая тестовая утилита, которую я знаю для Linux.

(В настоящее время я готовлю linux livecd на работе с bonnie++, чтобы протестировать на нем нашу машину под управлением Windows!)

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

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

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

несколько советов о том, как использовать 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

Немного больше в: ПРОСТОЙ ПРИМЕР БОННИ++.

Similar question has been asked over on linux - How can I benchmark my HDD? - Unix & Linux Stack Exchange , file io - Testing IO performance in Linux - Stack Overflow and io - I/O Performance Benchmarking Linux - Server Fault .