Intereting Posts
/sbin/ldconfig.real: / usr / local / lib не является известным типом библиотеки xterm ширина и высота относительно количества пикселей НЕ число символов Определите изменение скорости передачи данных в формате USB и журнал. Как получить последнюю папку (отсортированную по алфавиту в порядке убывания и сопоставление шаблона) с помощью ls / find / etc? Получить URL-адрес перенаправления с помощью завитка Не удается перезагрузить локальные файловые системы для чтения-записи (RAID1) Проблема создания группы в репо: «yum-groups-manager: ошибка: нет такой опции: –default» Gnome не может подключить удаленный пакет samba без запроса домена Объединить и передать как параметр, bash Как я могу просматривать gzipped-файлы менее, без необходимости вводить zless? Есть ли способ использовать inotify для удаленных файловых систем (в частности, WebDAV)? Почему этот скрипт дает синтаксическую ошибку «Неожиданный конец файла»? ftp: на удаленном компьютере изменения владельца файла с изменением имени пользователя, используемого для входа в удаленную машину Установленный диск исчезает и больше не является действительным устройством LUKS Получить MAC-адрес непосредственно подключенного устройства

Почему fio seq_writes намного быстрее, чем dd?

У меня есть сервер zfs, где я провёл пару тупых тестов просто для понимания, и это меня озадачивает.

Контекст: – FreeBSD 11.2, ZFS с включенным сжатием, жесткие диски SAS, RAIDz2, 768 ГБ памяти.

Обе команды были запущены непосредственно на сервере FreeBSD.

# time dd if=/dev/random of=./test_file bs=128k count=131072 131072+0 records in 131072+0 records out 17179869184 bytes transferred in 135.191596 secs (127077937 bytes/sec) 0.047u 134.700s 2:15.19 99.6% 30+172k 4+131072io 0pf+0w # #The result file size: # du -sh test_file 16G test_file 

Это показывает, что мне удалось получить файл 16 ГБ со случайными данными за 135 секунд с пропускной способностью прибл. 117 МиБ / с.

Теперь я пытаюсь использовать ФИО ,

 # fio --name=seqwrite --rw=write --bs=128k --numjobs=1 --size=16G --runtime=120 --iodepth=1 --group_reporting seqwrite: (g=0): rw=write, bs=(R) 128KiB-128KiB, (W) 128KiB-128KiB, (T) 128KiB-128KiB, ioengine=psync, iodepth=1 fio-3.6 Starting 1 process seqwrite: Laying out IO file (1 file / 16384MiB) Jobs: 1 (f=1): [W(1)][100.0%][r=0KiB/s,w=2482MiB/s][r=0,w=19.9k IOPS][eta 00m:00s] seqwrite: (groupid=0, jobs=1): err= 0: pid=58575: Wed Jul 25 09:38:06 2018 write: IOPS=19.8k, BW=2478MiB/s (2598MB/s)(16.0GiB/6612msec) clat (usec): min=28, max=2585, avg=48.03, stdev=24.04 lat (usec): min=29, max=2586, avg=49.75, stdev=25.19 bw ( MiB/s): min= 2295, max= 2708, per=99.45%, avg=2464.33, stdev=124.56, samples=13 iops : min=18367, max=21664, avg=19714.08, stdev=996.47, samples=13 ---------- Trimmed for brevity ------------- Run status group 0 (all jobs): WRITE: bw=2478MiB/s (2598MB/s), 2478MiB/s-2478MiB/s (2598MB/s-2598MB/s), io=16.0GiB (17.2GB), run=6612-6612msec 

Теперь я достиг 2478 МБ / с пропускной способности. при использовании того же файла 16 ГиБ со случайными данными.

Почему такая большая разница? Насколько я понимаю, команда dd должна была использовать команду create для создания файла, затем выполнить команду open и write вызовы для записи случайных данных в открытый файл. Наконец close файл. Я выбрал размер блока 128 К, чтобы соответствовать размеру записи ZFS по умолчанию.

Тест fio должен измерять только вызовы write , но все остальное, то же самое. Почему такая большая разница в пропускной способности?

Чтобы еще больше сбить меня с толку, если я попросил fio создать файл с сжимаемостью 50%, пропускная способность упадет до 847 МБ / с. Я понимаю, что работа ЦП, связанная со сжатием, приводит к падению пропускной способности, но я надеялся, что это влияние будет нейтрализовано наличием почти половины объема данных для записи. Есть идеи, почему влияние так высоко?

Команда, используемая для запуска fio со сжимаемостью 50%:

  fio --name=seqwrite --rw=write --bs=128k --numjobs=1 --size=16G --runtime=60 --iodepth=1 --buffer_compress_percentage=50 --buffer_pattern=0xdeadbeef --group_reporting 

Я собираюсь перефразировать ваш вопрос, чтобы выделить часть контекста:

Почему

 fio --name=seqwrite --rw=write --bs=128k --numjobs=1 --size=16G --runtime=120 --iodepth=1 --group_reporting 

быстрее, чем

 time dd if=/dev/random of=./test_file bs=128k count=131072 

в системе FreeBSD 11.2 с 768 ГБ ОЗУ, жесткими дисками SAS и ZFS, настроенными как RAIDZ2 с включенным сжатием?

Основное различие заключается в том, что fio предварительно создает файл, прежде чем выполнять временные тесты:

 seqwrite: Laying out IO file (1 file / 16384MiB) 

в то время как dd , вероятно, выполняет запись с расширением файла (что приведет к обновлению метаданных). Кроме того, у вас так много оперативной памяти (768G) и вы пишете так мало данных по сравнению с ней (16G), есть большой шанс, что ваши записи могут быть сохранены в оперативной памяти (и фактически не записаны на диск намного позже). Это вероятно в случае fio когда файл был предварительно создан, и очень мало метаданных файла необходимо изменить для ввода-вывода. Вы можете, по крайней мере, указать fio не говорить, что это сделано, пока все записанные данные не будут записаны обратно из ядра в конце работы, используя end_fsync=1 .

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

clat (usec): min = 28, max = 2585, avg = 48.03, stdev = 24.04

Может ли ваш вращающийся диск действительно выполнить ввод-вывод за 28 микросекунд? Если нет, то, вероятно, где-то буферизовался

Наконец, fio по умолчанию использует тот же шаблон в последующих блоках . Поскольку происходит сжатие, это может еще больше повысить вашу пропускную способность fio (но это будет зависеть от таких вещей, как размер записи ZFS). Чтобы проверить это, скажите fio сделать его буферы несжимаемыми (что, в свою очередь, включает refill_buffers ) и посмотрите, не падает ли пропускная способность (что и было в вашем случае).

TLDR; Команды fio и dd вы дали, не проверяют одно и то же. Вы должны знать о таких вещах, как, например, существуют ли ваши файлы правильного размера, насколько сжимаемыми являются данные, которые вы записываете, и учитываете ли вы такие вещи, как буферизация ядра, записывая слишком мало данных и не проверяя, все ли было записано обратно. на диск.