У меня есть следующая конфигурация для тестирования: HP Microserver N36L (двухъядерный Athlon64 с низким энергопотреблением) 8 ГБ ОЗУ ECC 2 порта Intel Gigabit NIC 4x3 ТБ WD Green (5400 об / мин?) 1 диск sata для образа ОС (FreeBSD 10.1)
Коммутатор HP v1910-24G (управляемый коммутатор L2, 24 гигабитных порта)
Клиент: Core i5 2400 на материнской плате DH67BL 24 ГБ ОЗУ 1 гигабит Intel (на плате)
Машина FreeBSD предоставляет свои zvols через iSCSI, а инициатором является Windows. В Windows тома iSCSI отформатированы в NTFS, и VMWare Workstation использует его в качестве диска для других виртуальных машин (в данном случае также для виртуальной машины Windows 7).
Я пробовал несколько конфигураций для zvols, в основном размер блока с различными значениями, от 4k до 64k, а также размер кластера NTFS от 4 до 64k. Я пробовал сочетать размер блока = размер кластера и размер блока> размер кластера.
Во всех случаях я получаю в основном одно и то же:
Скорость последовательного чтения составляет 110–120 МБ / с (предел Gigabit Ethernet). Случайные чтения <5 МБ / с
Допускается копирование больших файлов за пределы или внутри виртуальных машин. Windows загружается очень медленно (> 3 минут при новой установке до экрана входа в систему. Еще 1 минута на рабочий стол)
Это ожидаемое поведение?
Эта конфигурация имеет множество компонентов и конструктивных решений, которые способствуют ее низкой производительности.
HP Microserver - элемент с низкой производительностью. ЦП низкого уровня с ограничением ОЗУ.
Диски Western Digital Green имеют низкую скорость вращения и требовать особое внимание за их форматирование в 4k секторов. Вероятно, это основная проблема.
Похоже, вы используете RAIDZ1 на трех дисках. Производительность произвольного чтения / записи при такой настройке также довольно низкая. Ожидайте увидеть производительность одного диска в обоих случаях.
Нет кеширования записи / устройства ЗИЛ.
1GbE iSCSI для программного инициатора Windows - не лучший вариант.
VMware Workstation определенно не помогает.
Некоторые атрибуты ZFS могут работать здесь против вас: дедупликация - это плохо. сжатие gzip плохое (lz4 в порядке). Слишком много оперативной памяти, выделенной для ARC, - это плохо.
Механические жесткие диски не могут получить произвольный доступ к вводу-выводу.
4x WD Green, обеспечивающие скорость произвольного чтения 5 МБ / с, даже лучше, чем я ожидал.
Немного математики: при 5400 об / мин для одного оборота требуется 11 мс, поэтому для полуоборота требуется ~ 5,5 мс. Это задержка вращения. Добавление еще ~ 8 мс время поиска (время, необходимое приводу для правильного позиционирования головок чтения / записи), доведите общее время до ~ 13 мс. Это означает, что IOPS на один диск составляет 1000 мс (1 сек) / 13 мс = ~ 76 IOPS. При произвольном чтении 4K это соответствует ~ 300 КБ / с.
Учитывая, что сами ZFS RAIDZ довольно плохи с точки зрения IOPS (это по замыслу: ZFS жертвует IOPS ради безопасности данных, прочтите Вот для более подробной информации) Я удивлен, что у вас скорость произвольного чтения составляет 5 МБ / с. Вы тестировали со случайными чтениями 4 КБ или более крупными (например, 64 КБ)?
Вернемся к исходной проблеме: я думаю, что это комбинация небольшого размера блока / записи iSCSI, томов RAIDZ и дисков 4K. В томах RAIDZ каждое чтение / запись разбивается на количество дисков с данными и затем перенаправляется на физические диски. Например, в вашей настройке одна запись размером 8 КБ будет прервана несколькими операциями записи размером ~ 3 КБ (3 записи по 3 КБ для данных и 1 запись по 3 КБ для проверки четности), и это вызовет чтение-изменение-запись на самих дисках (поскольку они имеют размер 4 КБ). на основе дисков). Поскольку при запуске Windows происходит много случайных записей, это может зависеть от поведения ваших дисков.
Попробуй это: если вы можете позволить себе уничтожить свой ZPOOL / ZDEV, уничтожьте его и воссоздайте с размером блока 16K или 32K (см. Вот). Затем переустановите компьютер с Windows и повторите свой сценарий.