tl;dr - Мой массив ZFS RAIDZ2 читает со скоростью 7,5+ ГБ/с и записывает со скоростью 2,0+ ГБ/с, когда я указываю a bs=128Kили больше с dd. OS X предполагает 1 КБ (согласно stat -f %k .), а все мои - ~300 МБ/с; ddдает ту же производительность с bs=1k. Даже a bs=4kдает 1,1 ГБ/с с dd.
Что можно сделать, чтобы улучшить общую скорость ввода-вывода хотя бы до 1 ГБ/с?
--
Подробности:
Я использую 16-дисковый SATA3 RAIDZ2 OpenZFS на файловой системе OSX (v1.31r2) (v5000) через Thunderbolt 2 (два Areca 8050T2) на 12-ядерном Mac Pro 64 ГБ.
Файловая система ZFS была создана с использованием ashift=12(жестких дисков расширенного формата с блоками по 4096 байт) и файла recordsize=128k.
Я вижу скорость передачи данных около 300 МБ/с с массива в OS X и с терминала при использовании команд по умолчанию (обратите внимание, что копируемый файл представляет собой 10 ГБ случайных данных):
Обычная копия:
Titanic:lb-bu admin$ time cp big-test.data /dev/null
real 0m23.730s
user 0m0.005s
sys 0m12.123s
≈ 424 МБ/с
--
ddс bs=1k:
Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=1024
9841180+0 records in
9841180+0 records out
10077368320 bytes transferred in 32.572506 secs (309382653 bytes/sec)
real 0m32.575s
user 0m1.880s
sys 0m30.695s
≈ 309 МБ/с
--
ddсbs=4k
Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=4096
2460295+0 records in
2460295+0 records out
10077368320 bytes transferred in 8.686014 secs (1160183301 bytes/sec)
real 0m8.688s
user 0m0.460s
sys 0m8.228s
≈1,16 ГБ/с
--
ddс bs=2m:
Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=2m
4805+1 records in
4805+1 records out
10077368320 bytes transferred in 1.162891 secs (8665788130 bytes/sec)
real 0m1.165s
user 0m0.003s
sys 0m1.162s
≈8,67 ГБ/с
--
OS X's read of the boot drive optimal I/O block size (1TB SSD, HFS+):
Titanic:lb-bu admin$ stat -f %k /
4096
--
OS X's read of the array's optimal I/O block size (16-drives RAIDZ2, ZFS):
Titanic:lb-bu admin$ stat -f %k .
1024
--
Я также создал том ZFS на пуле рядом с файловой системой и отформатировал его как HFS+. Я получил ту же производительность, что и выше.
Я работаю примерно в 20-30 раз ниже оптимального! Что я упускаю? Есть идеи?
--
Обновление: высокие скорости кэширования ввода-вывода (спасибо @yoonix). Скорости ≈300 МБ/с все еще кажутся слишком медленными для этого оборудования.
@qasdfdsaq: Загрузка ЦП во время ввода-вывода незначительна (все ядра <5%).
zfs получает весь вывод:
NAME PROPERTY VALUE SOURCE
lb-bu type filesystem -
lb-bu creation Tue Sep 30 16:41 2014 -
lb-bu used 36.8T -
lb-bu available 10.0T -
lb-bu referenced 138M -
lb-bu compressratio 1.00x -
lb-bu mounted yes -
lb-bu quota none default
lb-bu reservation none default
lb-bu recordsize 128K default
lb-bu mountpoint /Volumes/lb-bu local
lb-bu sharenfs off default
lb-bu checksum on default
lb-bu compression lz4 local
lb-bu atime on default
lb-bu devices on default
lb-bu exec on default
lb-bu setuid on default
lb-bu readonly off default
lb-bu zoned off default
lb-bu snapdir hidden default
lb-bu aclmode discard default
lb-bu aclinherit restricted default
lb-bu canmount on default
lb-bu xattr on default
lb-bu copies 1 default
lb-bu version 5 -
lb-bu utf8only on -
lb-bu normalization formD -
lb-bu casesensitivity insensitive -
lb-bu vscan off default
lb-bu nbmand off default
lb-bu sharesmb off default
lb-bu refquota none default
lb-bu refreservation none default
lb-bu primarycache all default
lb-bu secondarycache all default
lb-bu usedbysnapshots 0 -
lb-bu usedbydataset 138M -
lb-bu usedbychildren 36.8T -
lb-bu usedbyrefreservation 0 -
lb-bu logbias latency default
lb-bu dedup off default
lb-bu mlslabel none default
lb-bu sync standard default
lb-bu refcompressratio 1.01x -
lb-bu written 138M -
lb-bu logicalused 36.8T -
lb-bu logicalreferenced 137M -
lb-bu snapdev hidden default
lb-bu com.apple.browse on default
lb-bu com.apple.ignoreowner off default
lb-bu com.apple.mimic_hfs off default
lb-bu redundant_metadata all default
lb-bu overlay off default
решение1
Вы не опубликовали zpool statusдля этого, но вы подразумеваете в посте, что все 16 дисков находятся в одном vdev в RAIDZ2. Хотя это хорошая, безопасная конфигурация, вы должны понимать, что RAIDZ не предназначен в первую очередь для скорости. Он разработан, чтобы быть почти пуленепробиваемым. RAIDZ2 аналогичен RAID6, но у этого варианта есть функции, которые делают его медленнее и безопаснее.
Видетьэто хорошее написаниедля получения полной информации, но эти две цитаты должны помочь вам увидеть проблему (выделено мной):
При записи в RAID-Z vdev каждый блок файловой системы разбивается на собственную полосу по (потенциально) всем устройствам RAID-Z vdev. Это означает, что каждый ввод-вывод записи должен будет ждать, пока все диски в RAID-Z vdev не закончат запись. Таким образом, с точки зрения одного приложения, ожидающего завершения своего ввода-вывода,вы получите производительность записи IOPS самого медленного диска в RAID-Z vdev.
При чтении с виртуальных устройств RAID-Z применяются те же правила, поскольку процесс по сути обратный (нет циклического перебора, как в случае зеркалирования): более высокая пропускная способность, если вам повезет (и чтение происходит так же, как и запись)и производительность чтения IOPS одного диска в большинстве случаев, которые имеют значение.
По сути, у вас есть 16 дисков средней скорости, и для каждого прохода записи вы ждете, пока все 16 дисков проверят контроллер и скажут «готово» перед началом следующей записи. С 16 дисками вы фактически всегда будете ждать почти полного вращения диска перед одной из записей, поэтому вас задерживают физика и то, как ZFS фиксирует данные.
Задание записи одного процесса/потока — не лучший вариант для ZFS в целом. Запуск нескольких небольших задач чтения/записи данных одновременно может показать лучшие показатели IOPS, но я думаю, что физика ZFS — ваша главная проблема.
Если вы готовы пожертвовать пространством, зеркалирование, скорее всего, будет быстрее. Вы также можете получить немного лучшую производительность от ZFS, создав 2 8-дисковых RAIDZ2 vdev в пуле вместо 1 16-дискового RAIDZ2 vdev. Это также будет стоить вам полезного дискового пространства, но может помочь ускорить выполнение коммитов.
К сожалению, у меня для вас нет хороших новостей.