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

337

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

Луис Альварадо
источник

Ответы:

425

Терминальный метод

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

sudo hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads:   12540 MB in  2.00 seconds = 6277.67 MB/sec
Timing 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/output

10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 1.08009 s, 77.7 MB/s

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

  1. Перейдите в Система -> Администрирование -> Дисковая утилита.
    • Или запустите утилиту диска Gnome из командной строки, запустив gnome-disks
  2. Выберите ваш жесткий диск на левой панели.
  3. Теперь нажмите кнопку «Benchmark - Measure Drive Performance» на правой панели.
  4. Откроется новое окно с графиками. Вы найдете и две кнопки. Один предназначен для «Начать тестирование только для чтения», а другой - «Начать тестирование для чтения / записи». Когда вы нажимаете на любую кнопку, начинается тестирование жесткого диска.

контрольная работа

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

Статья

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

пантера
источник
10
Я бы рекомендовал тестировать, /dev/urandomа также /dev/zeroвводить данные ddпри тестировании SSD, так как сжимаемость данных может сильно повлиять на скорость записи.
Ян Маккиннон
3
На моем Ubuntu 12.04 Unity такого "System ->" нет. Или, по крайней мере, я не нашел его. И я не вижу этот дисковый инструмент ни в Системных настройках ... O_o Но мне наконец удалось его запустить: / usr / bin / palimpsest
Fran Marzoa
6
Обратите внимание, что с 12.10 он называется просто Диски и может быть найден через Unity.
Пол Ламмерцма
1
В Gnome это переместилось в Приложения -> Системные инструменты -> Настройки -> Дисковая утилита. Для тех, кто пользуется ненавистью к Unity.
Кен Шарп
2
В /tmpнаши дни файловая система часто использует виртуальный диск. Таким образом, запись в /tmp, кажется, проверяет вашу память, а не дисковую подсистему.
Zoredache
99

Суоминен прав, мы должны использовать какую-то синхронизацию; но есть более простой метод, 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
телевизионный
источник
28
Это ответ с использованием другой команды / опции, чем другие. Я вижу, что это ответ, достойный своего поста.
Алаа Али
2
Почему вы использовали 384 КБ в качестве размера блока?
Диего Ф. Дуран
1
@ Диего Нет причин. Это был просто пример. Вы можете использовать что-нибудь еще. (между 4k ... 1M) Конечно, больший размер блока даст лучшую производительность. И, конечно, уменьшите число, когда вы используете большие bs, иначе потребуется год, чтобы закончить.
Тел
это ненадежно с помощью таких инструментов, как iozone и sysbench, цифры намного ниже
MSS
1
Будьте осторожны с использованием нулей для ваших данных записи - некоторые файловые системы и диски будут иметь специальный путь для них (и другие сжимаемые данные), что приведет к искусственно высоким числам эталонных тестов ...
Anon
50

Я бы не рекомендовал использовать, /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 B / s -> 237MB / s

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

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

Паси Суоминен
источник
3
Будьте осторожны с использованием нулей для ваших данных записи - для некоторых дисков (например, SSD) и некоторых файловых систем для них будет указан специальный регистр. Это приводит к искусственно высоким показателям при использовании нулевых буферов. Другие шаблоны данных с высокой степенью сжатия могут также искажать результаты ...
Anon
36

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

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

Чтобы установить iotop:

sudo apt-get install iotop  

Чтобы запустить это:

sudo iotop
Lars
источник
28

Если вы хотите точности, вы должны использовать 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аргумент, чтобы увеличить размер файла. Использование больших файлов может уменьшить количество получаемых вами данных в зависимости от технологии привода и прошивки. Небольшие файлы дадут «слишком хорошие» результаты для ротационных носителей, потому что считывающей головке не нужно слишком много двигаться. Если ваше устройство почти пусто, использование файла, достаточно большого, чтобы заполнить диск, приведет к худшему поведению в каждом тесте. В случае SSD размер файла не имеет большого значения.

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

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

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

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

Микко Ранталайнен
источник
1
Я только что проверил некоторые устройства. Используя вышеописанный тест последовательного чтения (размер блока 2 МБ), я получил 280 МБ / с от Samsung SSD 850 EVO и 1070 МБ / с от Intel 910 SSD. С размером блока 64 КБ и в остальном идентичной командной строке я получил 268 МБ / с от 850 EVO и 1055 МБ / с от 910 SSD. По крайней мере, для такого рода устройств использование размера блока 2 МБ улучшает результаты примерно на 1-5%, даже если ядро ​​разделяет запросы к оборудованию. Я предполагаю, что даже при оптимизации ядра издержки отправки большего количества системных вызовов хуже, чем разбиение внутри ядра.
Микко Ранталайнен
1
После дальнейшего тестирования кажется, что я получаю самую высокую последовательную пропускную способность, используя значение мощности 2, которое меньше, чем max_sectors_kb. Я изменил приведенные выше примеры команд, чтобы использовать размер блока 1 МБ, потому что это похоже на работу с реальным оборудованием. И я также проверил, что fsyncне имеет значения для чтения.
Микко Ранталайнен
1
В зависимости от того, как подключен диск, вы можете обнаружить, что ваш iodepth был слишком низким. Вы должны были бы посмотреть, что Linux на самом деле отправляет на устройство и на какой глубине он это делает ...
Anon
1
Я установил , iodepthчтобы 1для произвольного доступа именно потому , что в реальном мире программы часто запускать алгоритмы / логики , которая не работает с глубиной выше чем 1. В результате, если такая глубина «слишком низко» устройство ввода / вывода плохо. Это правда, что некоторые SSD-устройства получат выгоду от глубины выше 32. Однако можете ли вы указать на любую реальную рабочую нагрузку, которая требует доступа для чтения и способна поддерживать iodepth выше 32? TL; DR: если вы хотите воспроизвести какое-то безумно высокое число тестов чтения с устройством с высокой задержкой, используйте, iodepth=256 --numjobs=4но никогда не ожидайте увидеть такие числа по-настоящему.
Микко Ранталайнен
1
Большинство «реальных» программ на самом деле не отправляют ввод / вывод (o_) напрямую, не говоря уже об асинхронности, поэтому все наши примеры находятся в необычных рабочих нагрузках, чтобы расширить границы эталонных тестов (как говорится, лучший эталонный тест - это ваша реальная рабочая нагрузка). Сказав, что такие вещи, как запуск нескольких занятых виртуальных машин, легко могут генерировать рабочие нагрузки с невероятно большой глубиной, но там, где ввод-вывод часто выглядит случайным с точки зрения диска, и это простой пример того, как вы можете увидеть огромное ускорение от таких вещей, как NVMe. PS: слишком высокие значения уменьшат пропускную способность, так что есть приятное место ...
Anon
25

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

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

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

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

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

Корто
источник
Бонни имеет недостатки в бенчмаркинге дисков и может легко генерировать числа, которые на самом деле отражают не дисковые аспекты вашей системы, поэтому требуется высокая степень осторожности, если вы решите ее использовать. См. Брендана Грегга «Активный бенчмаркинг: Бонни ++» для подробностей.
Анон
22

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

$ 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
Лимон Монте
источник
Будьте осторожны с использованием нулей для ваших данных записи - некоторые файловые системы и диски будут иметь специальный путь к нему (и другие сжимаемые данные), что приведет к искусственно высоким числам эталонных тестов ...
Anon
14

некоторые советы о том, как использовать Бонни ++

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 .

nyxee
источник