Как проверить производительность записи на уровне файлов?

Question 1

В очень похожий вопрос , принятый ответ предлагает сделать:

dd if=/dev/zero of=/tmp/output bs=8k count=10k;

для измерения скорости записи на жесткий диск.

Мои тесты были безрезультатными. У меня есть программный RAID 1 на базе LVM с двумя обычными жесткими дисками. При запуске вышеупомянутой команды она дает следующий результат:

10240 + 0 записей в
10240 + 0 записывает
83886080 байт (84 МБ) скопированных , 0,0784284 с, 1,1 ГБ / с

Не то чтобы я недоволен массивом RAID, который может хранить 1 ГБ в секунду, но мне все равно хотелось бы знать:

Почему я получаю неправильные результаты? Это как-то связано с кешем? RAID? LVM?
Как получить фактическую производительность записи на уровне файлов?

Question 2

Без видимой причины Ваш тестовый размер файла является действительно небольшим, только 80 МБ. Маленький файл как этот сделает результат менее точным, но также и будет означать, чем вся операция может быть удовлетворена кэшем и не проверить истинную производительность файловой системы.

Для фиксации я сделал бы размер файла намного больше, сказал бы несколько ГБ.

, вероятно, необходимо сделать sync впоследствии и измерить целый результат. Как в time 'dd if=/dev/zero of=/tmp/output bs=1M count=2k && sync' или что-то.
Удостоверяются, что/tmp не является на самом деле tmpfs, в этом случае, он хранится в памяти, не на диске. Удостоверьтесь, что целевой раздел является разделом диска.
Копирование с/dev/zero может в некоторых случаях привести к искусственно высокой производительности, когда дисковый носитель выполняет ее собственное сжатие данных, потому что строка обнуляет сжатия вниз к фактически ничему. Это будет специфическим вопросом о SSD. Удостоверьтесь, что Ваши данные тестирования достаточно случайны для не сжатия, такие как файлы JPEG или видео MP4 (а не тот же файл много раз, потому что это все еще сожмется хорошо). Случайные данные будут работать лучше всего, если они будут предварительно сгенерированы, не генерируйте их на лету, потому что это будет искусственно замедляться передача.

thomasrutter · Accepted Answer · 13 April 2017 в 15:24

Без видимой причины Ваш тестовый размер файла является действительно небольшим, только 80 МБ. Маленький файл как этот сделает результат менее точным, но также и будет означать, чем вся операция может быть удовлетворена кэшем и не проверить истинную производительность файловой системы.

Для фиксации я сделал бы размер файла намного больше, сказал бы несколько ГБ.

, вероятно, необходимо сделать sync впоследствии и измерить целый результат. Как в time 'dd if=/dev/zero of=/tmp/output bs=1M count=2k && sync' или что-то.
Удостоверяются, что/tmp не является на самом деле tmpfs, в этом случае, он хранится в памяти, не на диске. Удостоверьтесь, что целевой раздел является разделом диска.
Копирование с/dev/zero может в некоторых случаях привести к искусственно высокой производительности, когда дисковый носитель выполняет ее собственное сжатие данных, потому что строка обнуляет сжатия вниз к фактически ничему. Это будет специфическим вопросом о SSD. Удостоверьтесь, что Ваши данные тестирования достаточно случайны для не сжатия, такие как файлы JPEG или видео MP4 (а не тот же файл много раз, потому что это все еще сожмется хорошо). Случайные данные будут работать лучше всего, если они будут предварительно сгенерированы, не генерируйте их на лету, потому что это будет искусственно замедляться передача.

Как проверить производительность записи на уровне файлов?

1 ответ

Другие вопросы по тегам:

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