Ответы:
Я обычно использую hdparmдля сравнения моих жестких дисков. Вы можете сравнить как прямое чтение, так и кэшированное чтение. Вы захотите выполнить команды пару раз, чтобы установить среднее значение.
Вот прямое чтение.
$ sudo hdparm -t /dev/sda2
/dev/sda2:
Timing buffered disk reads: 302 MB in 3.00 seconds = 100.58 MB/sec
А вот и кешированное чтение.
$ sudo hdparm -T /dev/sda2
/dev/sda2:
Timing cached reads: 4636 MB in 2.00 seconds = 2318.89 MB/sec
-t Perform timings of device reads for benchmark and comparison
purposes. For meaningful results, this operation should be repeated
2-3 times on an otherwise inactive system (no other active processes)
with at least a couple of megabytes of free memory. This displays
the speed of reading through the buffer cache to the disk without
any prior caching of data. This measurement is an indication of how
fast the drive can sustain sequential data reads under Linux, without
any filesystem overhead. To ensure accurate measurements, the
buffer cache is flushed during the processing of -t using the
BLKFLSBUF ioctl.
-T Perform timings of cache reads for benchmark and comparison purposes.
For meaningful results, this operation should be repeated 2-3
times on an otherwise inactive system (no other active processes)
with at least a couple of megabytes of free memory. This displays
the speed of reading directly from the Linux buffer cache without
disk access. This measurement is essentially an indication of the
throughput of the processor, cache, and memory of the system under
test.
Я тоже использовал ddдля этого типа тестирования. Одна из модификаций, которую я бы сделал в приведенной выше команде, - добавить этот бит в конец вашей команды ; rm ddfile.
$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile
Это удалит ddfileпосле завершения команды. ПРИМЕЧАНИЕ: ddfile это временный файл, который вам не нужно хранить, это файл, который ddзаписывается в ( of=ddfile), когда он загружает ваш жесткий диск.
Если вам нужно более тщательное тестирование ваших жестких дисков, вы можете использовать Bonnie ++ .
hdparmбыстрый тест. Единственным недостатком является то, что он измеряет только пропускную способность чтения, а производительность многих типов блочных устройств (например, RAID, iSCSI) может быть очень асимметричной. Для сравнения производительности «до» и «после» на одной и той же коробке ddтакже хорошо работает.
hdparm+ ddили только bonnie++или все 3.
(Это очень популярный вопрос - его варианты можно увидеть на https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 и https://askubuntu.com/q / 87035/740413 )
Есть ли лучшие методы [чем dd] для [тестовых дисков]?
Да, но они потребуют больше времени для запуска и потребуют знаний о том, как интерпретировать результаты - нет единого числа, которое сообщит вам все за один раз, потому что следующие типы влияют на тип теста, который вы должны выполнить:
И так далее.
Вот краткий список инструментов, которые легче всего запускать вверху, а труднее / более тщательно / лучше - ближе внизу:
Грег - получи ФИО код Дженса. Он делает все правильно, в том числе записывает реальное псевдослучайное содержимое, которое показывает, выполняет ли диск некоторую «дедупликацию» (иначе говоря, оптимизирован для эталонных тестов):
[ https://github.com/axboe/fio/ ]
Все остальное подозрительно - забудьте о Бонни или других традиционных инструментах.
Источник: комментарий от Google Plus к Грегу Кроа-Хартману от Линуса Торвальдса .
Если вы не можете прочитать все это, я просто рекомендую инструмент IOPS . Он покажет вам реальную скорость в зависимости от размера блока.
В противном случае - при выполнении теста ввода-вывода я бы посмотрел на следующие вещи:
Загрузка процессора
Какой размер блока вы будете использовать : если вы хотите читать / записывать 1 ГБ с / на диск, это будет быстро, если вы выполните одну операцию ввода-вывода. Но если вашему приложению нужно записать по 512 байт по всему жесткому диску непоследовательными частями (называемыми случайным вводом-выводом, хотя это и не случайно), это будет выглядеть по-другому. Теперь базы данных будут выполнять случайный ввод / вывод для тома данных и последовательный ввод / вывод для тома журнала из-за их природы . Итак, сначала вам нужно выяснить, что вы хотите измерить. Если вы хотите скопировать большие видеофайлы, это отличается от того, если вы хотите установить Linux.
Этот размер блока влияет на количество операций ввода-вывода, которые вы делаете. Например, если вы выполняете 8 последовательных операций чтения (или записи, только не смешанных), планировщик ввода-вывода ОС объединит их. Если этого не произойдет, кэш контроллера выполнит слияние. Практически нет разницы, если вы читаете 8 последовательных блоков по 512 байт или один блок 4096 байт. Единственное исключение - если вам удается выполнить прямую синхронизацию ввода-вывода и ждать 512 байт, прежде чем запрашивать следующие 512 байт. В этом случае увеличение размера блока похоже на добавление кеша.
Также вы должны знать, что существует синхронный и асинхронный ввод-вывод: с синхронизирующим вводом-выводом вы не выполните следующий запрос ввода-вывода, пока не вернется текущий. С помощью асинхронного ввода-вывода вы можете запросить, например, 10 порций данных, а затем ждать их поступления. Потоки базы данных Disctinct обычно используют синхронизирующий ввод-вывод для журнала и асинхронный ввод-вывод для данных. Инструмент IOPS заботится об этом, измеряя все соответствующие размеры блока, начиная с 512 байтов.
Будете ли вы читать или писать : обычно чтение быстрее, чем запись. Но обратите внимание, что для операций чтения и записи кэширование работает совсем по-другому:
При записи данные будут переданы контроллеру, и если он кешируется, он подтвердит их перед тем, как данные будут записаны на диск, если кэш не заполнен. С помощью инструмента iozone вы можете рисовать красивые графики плато эффектов кеша (эффект кеша процессора и эффект кеша буфера). Кэши становятся менее эффективными, чем больше было написано.
Для чтения данные чтения хранятся в кэше после первого чтения. Первые чтения занимают больше всего времени, а кэширование становится все более эффективным во время работы. Примечательные кеши - это кеш процессора, кеш файловой системы ОС, кеш контроллера ввода-вывода и кеш хранилища. Инструмент IOPS измеряет только чтение. Это позволяет ему «читать везде», и вы не хотите, чтобы он писал вместо чтения.
Сколько потоков вы будете использовать : если вы используете один поток ( используя dd для тестов диска ), вы, вероятно, получите намного худшую производительность, чем с несколькими потоками. Инструмент IOPS учитывает это и читает о нескольких потоках.
Насколько важна для вас задержка : Глядя на базы данных, задержка ввода-вывода становится чрезвычайно важной. Любая команда SQL вставки / обновления / удаления будет записана в журнал базы данных («log» в базе данных lingo) при подтверждении до ее подтверждения. Это означает, что полная база данных может ожидать завершения этой операции ввода-вывода. Я показываю здесь , как измерить среднее время ожидания (ОЖИДАНИЕ) , используя IOSTAT инструмента .
Насколько важно использование процессора для вас : ваш процессор может легко стать узким местом для производительности вашего приложения. В этом случае вы должны знать, сколько циклов ЦП сгорает на чтение / запись байта, и оптимизировать в этом направлении. Это может означать выбор «за» или «против» флэш-памяти PCIe в зависимости от результатов измерений. Опять же, инструмент iostat может дать вам приблизительную оценку использования ЦП операциями ввода-вывода.
Если вы установили PostgreSQL, вы можете использовать их отличный тест pg_test_fsync . Это в основном проверяет вашу производительность синхронизации записи.
На Ubuntu вы найдете это здесь: /usr/lib/postgresql/9.5/bin/pg_test_fsync
Самое замечательное в этом то, что этот инструмент покажет вам, почему корпоративные SSD стоят лишних долларов.
postgresql-contribпакете.
Вы можете использовать fio- Многопоточный инструмент генерации ввода-вывода . Он упакован в несколько дистрибутивов, например, Fedora 25, Debian и OpenCSW.
Инструмент fio очень гибкий, его можно легко использовать для сравнения различных сценариев ввода-вывода, в том числе параллельных. Пакет поставляется с некоторыми примерами конфигурационных файлов (см., Например, /usr/share/doc/fio/examples). Он правильно измеряет вещи, то есть печатает стандартное отклонение и количественную статистику для некоторых цифр. Вещи некоторых других популярных инструментов бенчмаркинга не волнуют.
Простой пример (последовательность простых сценариев: последовательный / случайный X чтение / запись):
$ cat fio.cfg
[global]
size=1g
filename=/dev/sdz
[randwrite]
rw=randwrite
[randread]
wait_for=randwrite
rw=randread
size=256m
[seqread]
wait_for=randread
rw=read
[seqwrite]
wait_for=seqread
rw=write
Звонок:
# fio -o fio-seagate-usb-xyz.log fio.cfg
$ cat fio-seagate-usb-xyz.log
[..]
randwrite: (groupid=0, jobs=1): err= 0: pid=11858: Sun Apr 2 21:23:30 2017
write: io=1024.0MB, bw=16499KB/s, iops=4124, runt= 63552msec
clat (usec): min=1, max=148280, avg=240.21, stdev=2216.91
lat (usec): min=1, max=148280, avg=240.49, stdev=2216.91
clat percentiles (usec):
| 1.00th=[ 2], 5.00th=[ 2], 10.00th=[ 2], 20.00th=[ 7],
| 30.00th=[ 10], 40.00th=[ 11], 50.00th=[ 11], 60.00th=[ 12],
| 70.00th=[ 14], 80.00th=[ 16], 90.00th=[ 19], 95.00th=[ 25],
| 99.00th=[ 9408], 99.50th=[10432], 99.90th=[21888], 99.95th=[38144],
| 99.99th=[92672]
bw (KB /s): min= 7143, max=371874, per=45.77%, avg=15104.53, stdev=32105.17
lat (usec) : 2=0.20%, 4=15.36%, 10=6.58%, 20=69.35%, 50=6.07%
lat (usec) : 100=0.49%, 250=0.07%, 500=0.01%, 750=0.01%
lat (msec) : 4=0.01%, 10=1.20%, 20=0.54%, 50=0.08%, 100=0.03%
lat (msec) : 250=0.01%
cpu : usr=1.04%, sys=4.79%, ctx=4977, majf=0, minf=11
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=262144/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=1
randread: (groupid=0, jobs=1): err= 0: pid=11876: Sun Apr 2 21:23:30 2017
read : io=262144KB, bw=797863B/s, iops=194, runt=336443msec
[..]
bw (KB /s): min= 312, max= 4513, per=15.19%, avg=591.51, stdev=222.35
[..]
Обратите внимание, что [global]раздел имеет глобальные значения по умолчанию, которые могут быть переопределены другими разделами. Каждый раздел описывает задание, название раздела - это название задания и может быть свободно выбрано. По умолчанию разные задания запускаются параллельно, поэтому в приведенном выше примере явно сериализуется выполнение задания с
wait_forключом. Кроме того, fio использует размер блока 4 КиБ, который также можно изменить. В этом примере непосредственно используется необработанное устройство для заданий чтения и записи, поэтому убедитесь, что вы используете правильное устройство. Инструмент также поддерживает использование файла / каталога в существующих файловых системах.
hdparmУтилита предоставляет очень простой тест для чтения, например:
# hdparm -t -T /dev/sdz
Он не является заменой современного инструмента для тестирования производительности, такого как fio, он просто должен использоваться для первой проверки достоверности. Например, чтобы проверить, распознается ли внешний USB 3 накопитель как устройство USB 2 (тогда вы увидите ~ 100 МБ / с против ~ 30 МБ / с).
Как указано здесь , вы можете использовать gnome-disks(если вы используете Gnome).
Нажмите на диск, который вы хотите проверить, и нажмите «Дополнительные параметры раздела» (колеса). Тогда Benchmark Partition. Вы получите среднее чтение / запись в МБ / с и среднее время доступа в миллисекундах. Я нашел это очень удобно.
Это немного грубо, но это работает в крайнем случае:
find <path> -type f -print0 | cpio -0o >/dev/null
Вы можете сделать некоторые интересные вещи с этой техникой, включая кэширование всех /libи /usr/binфайлов. Вы также можете использовать это как часть сравнительного анализа:
find / -xdev -type f -print0 |
sort -R --from0-file=- |
timeout "5m" cpio -0o >/dev/null
Все имена файлов в корне найдены, отсортированы случайным образом и копируют их в кэш на срок до 1 минуты. Вывод cpio сообщает, сколько блоков было скопировано. Повторите 3 раза, чтобы получить среднее количество блоков в минуту. (Обратите внимание, что операция поиска / сортировки может занять много времени - намного дольше, чем копирование. Было бы лучше кэшировать поиск / сортировку и использовать splitдля получения образца файлов.)