Назад | Перейти на главную страницу

Как объяснить эти результаты с пропускной способностью fio?

Пробежал пару fio тесты на новом сервере со следующей настройкой:

Диски оценены до 3200 МБ / с последовательные чтения. С теоретической точки зрения максимальная пропускная способность должна составлять 19,2 ГБ / с.

Бег fio с участием numjobs=1 на ZFS RAID я получаю результаты в диапазоне ~ 2000 - 3000 МБ / с (диски способны работать со скоростью 3200 МБ / с при тестировании без ZFS или каких-либо других накладных расходов, например, при запуске Crystal Disk Mark в Windows устанавливается прямо на один из дисков):

fio --name=Test --size=100G --bs=1M --iodepth=8 --numjobs=1 --rw=read --filename=fio.test
=>
Run status group 0 (all jobs):
   READ: bw=2939MiB/s (3082MB/s), 2939MiB/s-2939MiB/s (3082MB/s-3082MB/s), io=100GiB (107GB), run=34840-34840msec

Кажется разумным все обдуманное. Также может быть ограничен ЦП, поскольку одно из ядер будет загружено на 100% (при этом часть этой нагрузки будет затрачена на процессы ZFS).

Когда я увеличиваю numjobs до 8-10 все становится немного странно:

fio --name=Test --size=100G --bs=1M --iodepth=8 --numjobs=10 --rw=read --filename=fio.test
=>
Run status group 0 (all jobs):
   READ: bw=35.5GiB/s (38.1GB/s), 3631MiB/s-3631MiB/s (3808MB/s-3808MB/s), io=1000GiB (1074GB), run=28198-28199msec

38,1 ГБ / с - значительно выше теоретической максимальной пропускной способности.

Какое именно здесь объяснение?

Дополнения для комментариев:

Конфигурация ВМ:

iotop во время теста:

Первый fio (тот, у кого --numjobs=1) последовательно выполняет любую операцию чтения, не имея никакой выгоды от конфигурации полосы, за исключением быстрого упреждающего чтения / предварительной выборки: iodepth применяется только к асинхронному чтению, выполненному через libaio двигатель, который, в свою очередь, требует истинной поддержки O_DIRECT (чего нет в ZFS). Вы можете попробовать увеличить окно предварительной выборки с 8M по умолчанию до 64M (echo ‭67108864‬ > /sys/module/zfs/parameters/zfetch_max_distance). Конечно, ваш опыт может отличаться, поэтому убедитесь, что это не влияет на другие рабочие нагрузки.

Второй fio (тот, у кого --numjobs=8) вероятно искажено кэшированием ARC. Чтобы быть уверенным, просто откройте другой терминал, dstat -d -f: вы увидите истинную скорость передачи каждого диска, и она наверняка будет соответствовать их теоретической максимальной скорости передачи. Вы также можете повторить попытку fio протестируйте на недавно загруженной машине (то есть с пустым ARC), чтобы увидеть, изменится ли что-то.