Как я могу сравнить своего жесткого диска?

Нет \\[, просто \[. У Вас также есть дополнительное \[ в запуске.

55
24.04.2014, 22:09
7 ответов

Я обычно использую 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

Я также использовал 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 ++.

Ссылки

63
27.01.2020, 19:33
  • 1
    Мне нравится hdparm также, для быстрых сравнительных тестов. Единственный недостаток, он только сравнивает пропускной способности чтения, и производительность многих типов блочных устройств (например, RAID, iSCSI) может быть очень асимметричной. Для сравнения 'прежде' и 'после' производительности на том же поле, dd работы хорошо также. –  Alexios 11.01.2014, 12:02
  • 2
    @Alexios - да благодарит упомянуть это. Да обычно необходимо использовать, по крайней мере, hdparm + dd или просто bonnie++ или все 3. –  slm♦ 11.01.2014, 16:14
  • 3
    Вместо синхронизации, которая является сомнительным использованием iflag=direct oflag=direct, когда это предполагается (например, Linux с файловой системой, которая поддерживает прямой io). –   03.05.2015, 06:30

с инструментом IOPS

Если бы Вы не можете быть побеспокоены для чтения всего этого, что я просто рекомендовал бы инструменту IOPS. Это скажет Вам реальную скорость в зависимости от размера блока.


Иначе - при выполнении IO сравнивают, я посмотрел бы на следующие вещи:

  • blocksize/cache/IOPS/direct по сравнению с буферизированным/асинхронным по сравнению с синхронизацией
  • чтение-запись
  • потоки
  • задержка
  • Загрузка ЦП

  • Который 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.

11
27.01.2020, 19:33
  • 1
    iops сценарий хорош, я был действительно смущен, что это не было на способном или зернышке все же. Это действительно работает все же. –  ThorSummoner 23.01.2016, 07:53
  • 2
    От iops инструмента, кажется, отказываются. Кроме того, это просто измеряет чтения и не печатает статистических чисел (например, stddev/quantitative). –  maxschlepzig 08.04.2017, 13:42
  • 3
    iops инструмент прост и именно это необходимо выполнить сопоставимость. Это - в основном обертка к чтению syscall, сделанный случайным на файле (все - файл). Верьте этому или считайте источник - это закончено, и для кода не нужно обновление. Думайте об этом - Вы действительно хотите другой инструмент как IOMeter с 1000-ми строк кода, где каждый спорен? И что Вы делаете с новой версией? Необходимо ли будет восстановить все сравнительные тесты? –  Thorsten Staerk 10.04.2017, 21:55

(Это очень популярный вопрос - с его вариациями можно ознакомиться на https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 и https://askubuntu.com/q/87035/740413 )

Существуют ли лучшие методы [чем dd] для [эталонных дисков]?

Да, но их выполнение займет больше времени и потребует знаний о том, как интерпретировать результаты - нет ни одного числа, которое бы рассказало вам все за один раз, потому что на тип теста, который вы должны выполнить, влияют следующие факторы:

  • Вас интересует производительность ввода/вывода, которая является случайной, последовательной или некоторой комбинацией двух?
  • Вы читаете с диска или записываете на него (или некоторой комбинации двух)?
  • Вас беспокоит латентность, пропускная способность или оба?
  • Пытаетесь ли вы понять, как работают разные части одного и того же жесткого диска (как правило, они работают на скорости, которая ближе к центру вращающихся дисков)?
  • Вас интересует, как будет работать данная файловая система при использовании вашего диска, или вы хотите, чтобы результаты были ближе к исходной производительности диска, выполняя ввод/вывод непосредственно к блочному устройству?
  • Вас интересует, как выполняется ввод/вывод определенного размера?
  • Вы выполняете ввод/вывод синхронно или асинхронно?
  • Сколько входов/выходов вы отправляете (отправляете слишком мало данных неправильным способом, и все входы/выходы могут быть кэшированы, поэтому вы завершаете проверку скорости вашей оперативной памяти, а не скорости диска)?
  • Насколько сжимаемым является содержимое записываемых вами данных (например, только нулевые данные являются высоко сжимаемыми, а некоторые файловые системы/диски даже имеют специальный быстрый путь для нулевых данных, что приводит к цифрам, которые недоступны для другого содержимого)?

И так далее.

Вот краткий список инструментов, которые легче всего запускать сверху и сложнее/глубже/глубже снизу:

  1. dd (последовательное чтение или запись, только показывает пропускную способность, может быть настроено на использование файловой системы или блочного устройства, может быть настроено на обход блочного кэша/подождать, пока ввод/вывод будет действительно завершен)
  2. hdparm (только последовательное чтение, только показывает пропускную способность, никогда не использует файловую систему, может быть настроено на обход блочного кэша, тест кэша перечитывает только стартовые 2 МБайта)
  3. GNOME Disk Utility (легко запускается, никогда не использует файловую систему, графически, но требует полной установки GNOME, дает задержки и номера пропускной способности для различных типов ввода/вывода, но рабочая нагрузка записи на самом деле делает чтение/запись/синхронизацию на размер примера).
  4. fio (может делать практически всё, что угодно и даёт подробные результаты, но требует конфигурации и понимания того, как интерпретировать указанные результаты). Вот что говорит об этом Лайнус:

    Грег - достань код FIO Йенса. Он делает всё правильно, в том числе записывает фактическое псевдослучайное содержимое, которое показывает, выполняет ли диск некоторую "дедупликацию" (так же известную как "оптимизация под бенчмарки"):

    .

    [ https://github.com/axboe/fio/ ]

    Все остальное подозрительно - забудьте о Бонни или других традиционных инструментах.

Источник: комментарий, оставленный на Google Plus Грегу Кроа...Хартман Лайнуса Торвальдса.

.
23
27.01.2020, 19:33

. Если вы установили PostgreSQL, вы можете использовать их превосходный тест pg_test_fsync . Он в основном проверяет вашу производительность синхронизации записи.

В Ubuntu вы найдете его здесь: /usr/lib/postgresql/9.5/bin/pg_test_fsync

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

8
27.01.2020, 19:33

Как указано здесь здесь , вы можете использовать gnome-disks (если вы используете Gnome).

Щелкните диск, который вы хотите протестировать, и щелкните «Дополнительные параметры раздела» (колеса). Затем Benchmark Partition . Вы получите среднее значение чтения / записи в МБ / с и среднее время доступа в миллисекундах. Мне это показалось очень удобным.

1
27.01.2020, 19:33

Это немного грубо, но это работает в крайнем случае:

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 для получения образца файлов.)

1
27.01.2020, 19:33

Вы можете использовать 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 МБ / с).

7
27.01.2020, 19:33

Теги

Похожие вопросы