Как проверить производительность жесткого диска (через терминал или через графический интерфейс). Скорость записи. Скорость чтения. Размер кэша и скорость. Случайная скорость
Ответы:
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
gnome-disks
Есть ли что-то еще, что вы хотите?
/dev/urandomа также /dev/zeroвводить данные ddпри тестировании SSD, так как сжимаемость данных может сильно повлиять на скорость записи.
/tmpнаши дни файловая система часто использует виртуальный диск. Таким образом, запись в /tmp, кажется, проверяет вашу память, а не дисковую подсистему.
Суоминен прав, мы должны использовать какую-то синхронизацию; но есть более простой метод, 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
Я бы не рекомендовал использовать, /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 МБ / с ниже, чем при кешировании.
Счастливый бенчмаркинг,
Если вы хотите отслеживать скорость чтения и записи диска в режиме реального времени, вы можете использовать инструмент iotop .
Это полезно для получения точной информации о том, как диск работает для конкретного приложения или задачи. Вывод покажет вам скорость чтения / записи для каждого процесса и общую скорость чтения / записи для сервера, очень похожую на top.
Чтобы установить iotop:
sudo apt-get install iotop
Чтобы запустить это:
sudo iotop
Если вы хотите точности, вы должны использовать 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получить номера спецификаций, потому что внутренняя задержка этих устройства выше, но общая пропускная способность безумна.
max_sectors_kb. Я изменил приведенные выше примеры команд, чтобы использовать размер блока 1 МБ, потому что это похоже на работу с реальным оборудованием. И я также проверил, что fsyncне имеет значения для чтения.
iodepthчтобы 1для произвольного доступа именно потому , что в реальном мире программы часто запускать алгоритмы / логики , которая не работает с глубиной выше чем 1. В результате, если такая глубина «слишком низко» устройство ввода / вывода плохо. Это правда, что некоторые SSD-устройства получат выгоду от глубины выше 32. Однако можете ли вы указать на любую реальную рабочую нагрузку, которая требует доступа для чтения и способна поддерживать iodepth выше 32? TL; DR: если вы хотите воспроизвести какое-то безумно высокое число тестов чтения с устройством с высокой задержкой, используйте, iodepth=256 --numjobs=4но никогда не ожидайте увидеть такие числа по-настоящему.
bonnie ++ - лучшая утилита для тестирования производительности, которую я знаю для linux.
(В настоящее время я готовлю linux livecd для работы с bonnie ++, чтобы протестировать наш Windows-компьютер с ним!)
Он заботится о кэшировании, синхронизации, случайных данных, случайном расположении на диске, небольших размерах обновлений, больших обновлениях, чтениях, записи и т. Д. Сравнение usbkey, жесткого диска (поворотного), твердотельного накопителя и оперативной памяти Файловая система может быть очень информативной для новичка.
Я понятия не имею, включен ли он в Ubuntu, но вы можете легко скомпилировать его из исходного кода.
Скорость письма
$ 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
некоторые советы о том, как использовать Бонни ++
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 .
Проверьте целостность, обнаружите фальшивые флешки и протестируйте производительность - все три в одном кадре
Подробнее об этом ответе .