tl; dr - Мой массив ZFS RAIDZ2 читает со скоростью 7,5+ ГБ / с и записывает со скоростью 2,0+ ГБ / с, когда я указываю bs=128K или больше с dd. OS X предполагает 1 КБ (согласно stat -f %k .) и все мои это ~ 300 МБ / с; dd дает такую же производительность с bs=1k. Даже 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
Вы не разместили zpool status для этого, но вы подразумеваете в сообщении, что все 16 дисков находятся в одном vdev в RAIDZ2. Хотя это хорошая и безопасная конфигурация, вы должны понимать, что RAIDZ не предназначен в первую очередь для скорости. Он разработан, чтобы быть почти пуленепробиваемым. RAIDZ2 аналогичен RAID6, но у этого варианта есть функции, которые делают его медленнее и безопаснее.
Видеть это хорошо написать для получения полной информации, но эти две цитаты должны помочь вам разобраться в проблеме (выделено мной):
При записи в RAID-Z vdev каждый блок файловой системы разделяется на свою собственную полосу между (потенциально) всеми устройствами RAID-Z vdev. Это означает, что каждый ввод-вывод записи должен будет ждать, пока все диски в RAID-Z vdev закончат запись. Следовательно, с точки зрения отдельного приложения, ожидающего завершения ввода-вывода, вы получите производительность записи в IOPS самого медленного диска в RAID-Z vdev.
При чтении из RAID-Z vdev применяются те же правила, поскольку процесс по существу обратный (нет ярлыка циклического перебора, как в случае зеркалирования): лучшая пропускная способность, если вам повезет (и читайте так же, как вы написали) и производительность чтения с одного диска в секунду в большинстве важных случаев.
Фактически, у вас есть 16 среднескоростных дисков, и для каждого прохода записи вы ждете, пока все 16 дисков не проверятся контроллером, и говорите «готово» перед началом следующей записи. С 16 дисками вы фактически всегда будете ждать почти полного вращения диска перед одной из операций записи, так что вас задерживают физика и то, как ZFS фиксирует данные.
Задача записи одного процесса / потока - не лучший вариант для ZFS в целом. Одновременное выполнение нескольких задач чтения / записи небольших данных может показать вам более высокие показатели IOPS, но я думаю, что физика ZFS - ваша основная проблема.
Если вы готовы пожертвовать пространством, зеркальное отображение, вероятно, будет быстрее. Вы также можете немного повысить производительность ZFS, создав в пуле 2 8-дисковых RAIDZ2 vdev вместо 1 16-дискового RAIDZ2 vdev. Это тоже будет стоить вам полезного пространства для хранения, но может помочь совершить коммиты быстрее.
К сожалению, у меня для вас нет хороших новостей.