Нет \\[
, просто \[
. У Вас также есть дополнительное \[
в запуске.
Я обычно использую 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 ++.
Если бы Вы не можете быть побеспокоены для чтения всего этого, что я просто рекомендовал бы инструменту IOPS. Это скажет Вам реальную скорость в зависимости от размера блока.
Иначе - при выполнении IO сравнивают, я посмотрел бы на следующие вещи:
Загрузка ЦП
Который blocksize будет Вы использовать: Если Вы захотите к чтению-записи 1 ГБ из/в диск, то это будет быстро, если Вы сделаете одну операцию ввода-вывода. Но если Ваше приложение должно записать в 512-байтовых блоках на всем протяжении жесткого диска в непоследовательных частях (названный случайным вводом-выводом, хотя это не случайно), это посмотрит по-другому. Теперь, базы данных сделают случайный ввод-вывод для объема данных и последовательный ввод-вывод для объема журнала из-за их характера. Так, сначала необходимо стать ясными, что Вы хотите измерить. Если Вы хотите скопировать большие видеофайлы, это отличается, чем если бы Вы хотите установить Linux.
Этот blocksize производит количество операций ввода-вывода, которые Вы делаете. Если Вы сделаете, например, 8 последовательных чтений (или запись, просто не смешанная) операции, то планировщик ввода-вывода ОС объединит их. Если это не сделает, то кэш контроллера сделает слияние. Нет практически никакого различия при чтении 8 последовательных блоков 512 байтов или одного 4 096-байтового блока. Одно исключение - если Вам удается сделать прямой синхронизирующий IO и ожидать 512 байтов перед запросом следующих 512 байтов. В этом случае увеличение размера блока похоже на добавляющий кэш.
Также необходимо знать, что существует синхронизирующий и асинхронный IO: С синхронизирующим IO Вы не выпустите следующий запрос IO перед текущими возвратами. С асинхронным IO можно запросить, например, 10 блоков данных и затем ожидать, когда они прибывают. Потоки базы данных Disctinct будут обычно использовать синхронизирующий IO для журнала и асинхронный IO для данных. Инструмент IOPS заботится об этом путем измерения всех соответствующих размеров блока, начинающих с 512 байтов.
Будете Вы читать или запись: Обычно чтение быстрее, чем запись. Но обратите внимание что, кэшируя работы совершенно другой путь к чтениям и записям:
Для записей данные будут переданы контроллеру и если это будет кэшироваться, то это подтвердит, прежде чем данные будут на диске, если кэш не полон. Используя озон инструмента можно потянуть красивые графики плато эффектов кэша (эффект кэша ЦП и эффект кэш-буфера). Кэши становятся менее эффективными, больше было записано.
Для чтений считанные данные сохранены в кэше после первого чтения. Первые чтения берут самый длинный, и кэширование становится все более эффективным в течение времени работы. Кэши Noteable являются кэшем ЦП, кэшем файловой системы ОС, кэшем контроллера IO и кэшем устройства хранения данных. Инструмент IOPS только измеряет чтения. Это позволяет этому "читать повсеместно", и Вы не хотите, чтобы это записало вместо чтения.
Сколько потоки будут Вы использовать: при использовании одного потока (использующий dd для дисковых сравнительных тестов), Вы, вероятно, получите намного худшую производительность, чем с несколькими потоками. Инструмент IOPS принимает это во внимание и читает на нескольких потоках.
Насколько важный задержка для Вас: Смотря на базы данных, задержка IO становится чрезвычайно важной. Любой вставляет/обновляет/удаляет команду SQL, будет записан в журнал базы данных ("журнал" в малопонятном жаргоне базы данных) на фиксации, прежде чем это будет подтверждено. Это означает, что полная база данных может ожидать этой операции IO, которая будет завершена. Я показываю здесь, как иметь размеры, среднее время ожидания (ждут) использования iostat инструмента.
Насколько важный загрузка ЦП для Вас: Ваш ЦП может легко стать узким местом для производительности Вашего приложения. В этом случае необходимо знать, насколько циклы ЦП записываются на побайтовое чтение / записанный, и оптимизируйте в то направление. Это может означать решать для/против флэш-памяти PCIe в зависимости от Ваших измерительных результатов. Снова iostat инструмент может дать Вам грубую оценку на загрузке ЦП Вашими операциями IO.
(Это очень популярный вопрос - с его вариациями можно ознакомиться на https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 и https://askubuntu.com/q/87035/740413 )
Существуют ли лучшие методы [чем dd] для [эталонных дисков]?
Да, но их выполнение займет больше времени и потребует знаний о том, как интерпретировать результаты - нет ни одного числа, которое бы рассказало вам все за один раз, потому что на тип теста, который вы должны выполнить, влияют следующие факторы:
И так далее.
Вот краткий список инструментов, которые легче всего запускать сверху и сложнее/глубже/глубже снизу:
Грег - достань код FIO Йенса. Он делает всё правильно, в том числе записывает фактическое псевдослучайное содержимое, которое показывает, выполняет ли диск некоторую "дедупликацию" (так же известную как "оптимизация под бенчмарки"):
.[ https://github.com/axboe/fio/ ]
Все остальное подозрительно - забудьте о Бонни или других традиционных инструментах.
Источник: комментарий, оставленный на Google Plus Грегу Кроа...Хартман Лайнуса Торвальдса.
.. Если вы установили PostgreSQL, вы можете использовать их превосходный тест pg_test_fsync . Он в основном проверяет вашу производительность синхронизации записи.
В Ubuntu вы найдете его здесь: /usr/lib/postgresql/9.5/bin/pg_test_fsync
Самое замечательное в этом то, что этот инструмент покажет вам, почему корпоративные SSD стоят дополнительных долларов.
Как указано здесь здесь , вы можете использовать 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
для получения образца файлов.)
Вы можете использовать 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, это {{ 1}} следует использовать только для первой проверки достоверности. Например, чтобы проверить, не распознается ли внешний накопитель USB 3 как устройство USB 2 (тогда вы увидите скорость ~ 100 МБ / с против ~ 30 МБ / с).
hdparm
также, для быстрых сравнительных тестов. Единственный недостаток, он только сравнивает пропускной способности чтения, и производительность многих типов блочных устройств (например, RAID, iSCSI) может быть очень асимметричной. Для сравнения 'прежде' и 'после' производительности на том же поле,dd
работы хорошо также. – Alexios 11.01.2014, 12:02hdparm
+dd
или простоbonnie++
или все 3. – slm♦ 11.01.2014, 16:14