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

Я видел команды для тестирования своего жесткого диска, например, с помощью dd :

 $ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync" 

Есть ли лучшие способы сделать это, чем это?

  • как проверить существование переменных и сравнить со строкой в ​​busybox?
  • Сплошное поведение сравнения со стороны Solaris
  • 7 Solutions collect form web for “Как я могу проверить свой жесткий диск?”

    Обычно я использую 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 ; rm ddfile .

     $ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile 

    Это приведет к удалению ddfile после завершения команды. ПРИМЕЧАНИЕ. ddfile – это временный файл, который вам не нужно хранить, это файл, который dd пишет ( of=ddfile ), когда он загружает ваш жесткий диск.

    Выход за пределы

    Если вам нужно более тщательное тестирование ваших жестких дисков, вы можете использовать Bonnie ++ .

    Рекомендации

    • Как использовать 'dd' для тестирования вашего диска или процессора?
    • Контрольный диск IO с DD и Bonnie ++

    Это очень популярный вопрос (вы можете увидеть его варианты на https://stackoverflow.com/q/1198691 и https://serverfault.com/q/219739/203726 ).

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

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

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

    И так далее.

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

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

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

      http://freecode.com/projects/fio

      Все остальное подозревается – забудьте о bonnie или других традиционных инструментах.

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

    с помощью инструмента IOPS

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


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

    • blockize / cache / IOPS / direct vs buffered / async vs sync
    • читай пиши
    • потоки
    • задержка
    • Использование ЦП

    • Какой размер блока вы будете использовать : если вы хотите читать / записывать 1 ГБ с / на диск, это будет быстро, если вы выполните одну операцию ввода-вывода. Но если вашему приложению необходимо записать в 512 байтовых фрагментах по всему жесткому диску в несекретных частях (так называемый случайный ввод-вывод, хотя это не случайность), это будет выглядеть по-другому. Теперь базы данных будут делать случайный ввод-вывод для тома данных и последовательного ввода-вывода для объема журнала из-за их характера . Итак, сначала вам нужно понять, что вы хотите измерить. Если вы хотите скопировать большие видеофайлы, которые отличаются от того, если вы хотите установить Linux.

      Этот размер блокирует количество операций ввода-вывода, которые вы выполняете. Если вы выполняете, например, 8 последовательных операций чтения (или записи, просто не смешанных), планировщик ввода-вывода ОС будет объединять их. Если этого не произойдет, кеш контроллера будет выполнять слияние. Практически нет разницы, если вы читаете 8 последовательных блоков по 512 байт или один 4096 байт. Одно из исключений – если вам удастся выполнить прямую синхронизацию IO и дождаться 512 байтов, прежде чем запрашивать следующие 512 байт. В этом случае увеличение размера блока подобно добавлению кеша.

      Также вы должны знать, что есть синхронизация и асинхронный ввод-вывод: при синхронизации IO вы не выдадите следующий запрос ввода-вывода до того, как будет возвращен текущий. С асинхронным IO вы можете запросить, например, 10 фрагментов данных, а затем ждать, когда они прибудут. В потоках базы данных Disctinct обычно используется синхронизация IO для журнала и асинхронного ввода-вывода для данных. Инструмент IOPS позаботится об этом, измеряя все соответствующие размеры блоков, начиная с 512 байт.

    • Будете ли вы читать или писать : Обычно чтение происходит быстрее, чем писать. Но обратите внимание, что кеширование работает совсем по-другому для чтения и записи:

      • Для записи данные передаются контроллеру, и если он кэшируется, он будет подтверждать, прежде чем данные будут на диске, если кеш не будет заполнен. Используя инструмент iozone, вы можете рисовать красивые графики плато эффектов кеша (эффект кэша процессора и эффект буферного кеша). Кэши становятся менее эффективными, чем больше написано.

      • Для чтения прочитанные данные хранятся в кеше после первого чтения. Первое чтение занимает больше времени, и кеширование становится все более эффективным во время безотказной работы. Заметными кэшами являются кеш процессора, кэш файловой системы ОС, кеш IO-контроллера и кэш-память хранилища. Инструмент IOPS измеряет только показатели. Это позволяет ему «читать повсюду», и вы не хотите, чтобы он писал вместо чтения.

    • Сколько потоков вы будете использовать : если вы используете один поток ( используя dd для тестов на диске ), вы, вероятно, получите гораздо худшую производительность, чем с несколькими потоками. Инструмент IOPS учитывает это и читает несколько потоков.

    • Насколько важна латентность для вас : глядя на базы данных, задержка ввода-вывода становится чрезвычайно важной. Любая команда вставки / обновления / удаления SQL будет записана в журнал базы данных («журнал» в лингвинге базы данных) при фиксации до ее подтверждения. Это означает, что полная база данных может ждать завершения этой операции ввода-вывода. Здесь я покажу, как измерить среднее время ожидания (ожидание) с помощью инструмента iostat .

    • Насколько важно использование ЦП для вас : ваш процессор может легко стать узким местом для производительности вашего приложения. В этом случае вы должны знать, сколько циклов процессора сжигается на каждый байт, читать / записывать и оптимизировать в этом направлении. Это может означать решение для / против флеш-памяти PCIe в зависимости от результатов измерений. Снова инструмент iostat может дать вам приблизительную оценку использования ЦП вашими операциями ввода-вывода.

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

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

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

    Вы можете использовать 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 KiB, который также можно изменить. В примере напрямую используется необработанное устройство для чтения и записи, поэтому убедитесь, что вы используете правильное устройство. Этот инструмент также поддерживает использование файла / каталога в существующих файловых системах.

    Другие инструменты

    Утилита hdparm обеспечивает очень простой тест чтения, например:

     # hdparm -t -T /dev/sdz 

    Это не замена современного инструмента сравнения, например fio, его просто следует использовать для первой проверки правдоподобия. Например, чтобы проверить, неправильно ли распознан внешний USB-накопитель USB как устройство USB 2 (тогда вы увидите ~ 100 Мбайт / с против 30 Мбайт / с).

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

    Нажмите на диск, который вы хотите протестировать, и нажмите «Дополнительные параметры раздела» (колеса). Затем Benchmark Partition . Вы получите среднее чтение / запись в MB / s и среднее время доступа в миллисекундах. Я нашел это очень удобным.

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

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

    Interesting Posts

    Сценарий оболочки для преобразования PDF в изображения и сохранения в подпапке

    Как уменьшить количество fsync, которое выполняет mysql?

    Вставка текста в начале файла с помощью sed через терминал в Linux

    Установить гостевые дополнения на Kali Linux на VirtualBox 5 на Mac OSX?

    SSH ключ для HTTP

    Nagios / SNMP – уведомления об устройствах, когда цикл ppp / tun подключается

    Отклонено разрешение на изменение права собственности

    Какие утилит нужны для начала разработки Android на Ubuntu?

    Использование памяти бесконечно циклического сценария оболочки

    как я могу построить более старую версию gcc?

    Какое «семейство процессоров» выбрать в разделе «Тип и функции процессора»?

    передавая stdin для обработки A и обработки B (вызывается A)

    Могут ли быть неканонизированные формы путей файловой системы значительными? (например, «foo // bar», «foo /./ bar» и «foo /../ bar»)

    gnuplot 'с линиями' создает нежелательные "ящики"

    Как переключиться с рабочего стола Ubuntu на сервер Ubuntu?

    Linux и Unix - лучшая ОС в мире.