LINUX.ORG.RU

VirtualBox disk - zvol из ZFS - оптимизация

 , ,


0

3

Хост - Linux + VirtualBox5
Гость - Венда 8.1

Подскажите для венды с NTFS блоком (кластером?) = 4К

какой оптимальный volblocksize?

поставил volblocksize=4K при создании тома
скопировал раздел венды, загрузил венду, впечатление медленнее стало, чем было на ZFS с recordsize=128K
NTFS дефрагментирована
dstat показывает 90-100% утилизации дисков, на которых ZVol

zpool iostat -v 1
показывает в среднем около 300-500 IOPS на чтение, откуда столько на обычном винте SATA 5K оборотов?

наверно, это последовательные мелкие чтения по 4K?

как подобрать оптимальный volblocksize для NTFS без затрат времени на эксперименты?

или может лучше поставить побольше volblocksize и NTFS кластер?

ZVol проброшен с помощью: VBoxManage internalcommands createrawvmdk -filename $VMDKFile -rawdisk $Dev;

★★

volblocksize
zvol

смотря как организован пул. если в нем один диск или это единичное зеркало, то оптимально будет 128K, если это 10-рейд из 2-х зеркал, то 64K, а если из 4-х тогда 32K

vxzvxz ★★★ ()
Ответ на: комментарий от vxzvxz

т.е. оптимальный размер volblocksize=128K/кол_во_зеркал в пуле по типу RAID10?

получается размер по умолчанию = 8К рассчитан на 16 зеркал (всего от 32-х дисков и более в зависимости от кол-ва в каждом зеркале)? откуда эта инфа? есть тынц (URL)?

а как же:
1) насыщение канала большим кол-вом блоков при случайном чтении?
2) зависимость от соотношения больших файлов и малых внутри дочерней файловой системы, расположенной на ZVol и ее способности к дефрагментации?
3) наверно и еще многое другое?

sanyock ★★ ()

ИМХО нужно снять статистику ввода вывода тома и выбирать размер блока с самым большим показателем по статистике...


например, если основной размер обмена 4К-блоки, а том создан с 64к-блоками, то при рандомном чтении на каждый 4к блок будет реально читаться 64к (оверхед по чтению)

если том создан с 4к-блоками, а основной размер обмена 64К-блоки - то 64к блок может быть фрагментирован в zfs и в худшем случае чтение каждого блока 64к превратится в чтение 16 блоков по 4к разбросанных по диску...

Sigizmund ()
Ответ на: комментарий от vxzvxz

смотря как организован пул. если в нем один диск или это единичное зеркало, то оптимально будет 128K, если это 10-рейд из 2-х зеркал, то 64K, а если из 4-х тогда 32K

интересно, где ты такой ерунды начитался?

anonymous ()
Ответ на: комментарий от Sigizmund

кстати устраивал небольшое тестирование с NTFS блоками 4K на нескольких ZVol с блоками 4K, 8K, 16K, 128K
на ZVol 128K еще пробовал NTFS с другими размерами блоков

компик слабенький 5 летней давности

ZFS - NTFS write-read read operations/sec by zpool iostat

4-4 - 80 - 20 1-5K
8-8 - 80 - 30 0.5-3K
8-4 60 35 0.5-2К
16-16 20 - 40 0.5-2K сильно грузит проц
16-4 60 - 45 0.5-1.5К проц грузит обычно
128-64 75 - 120 0.5K
128-4 70 - 110 1K

похоже вендовый NTFS не любит блоки NTFS размером 16K в независимости от размера блока ZVol, проц жутко тормозит, мышка коекак ползает
в остальных режимах такого нет

тоже самое с табуляциями более лучше смотрится http://pastebin.com/raw.php?i=3GKKi3Jp

sanyock ★★ ()
Последнее исправление: sanyock (всего исправлений: 2)
Ответ на: комментарий от sanyock

в результате пришел к варианту ZVol блока=128К, NTFS=4K, для случае БЕЗ iSCSI когда напрямую к контроллеру

на компе поновее 2 летней давности:

Crystal Mark в т.ч. random: http://picpaste.com/pics/LbAzhxs6.1439299219.jpg

sanyock ★★ ()
Последнее исправление: sanyock (всего исправлений: 2)
Ответ на: комментарий от sanyock

это на одиночном HDD без ZIL и без L2ARC, только ARC и тот залочен на 512Мб

вендовой виртуалке было выделено 1гиг оперативы, чтобы не сильно кэшировала последовательные операции объем тестовых данных 4 гига

sanyock ★★ ()
Последнее исправление: sanyock (всего исправлений: 3)
Ответ на: комментарий от anonymous

все же не понимаю, к чему здесь этот комментарий

ведь производительность ZFS зависит от очень многих факторов, и есть такие инстоляции в которых, навряд ли другая FS сможет продемонстрировать лучшие показатели при сравнимом функционале

sanyock ★★ ()
Последнее исправление: sanyock (всего исправлений: 1)
Ответ на: комментарий от sanyock

функциональность и есть цена производительности, поэтому тезис о тормозной zfs остаётся в силе — arc, zil, disk space reservation — попытки компенсации тормозов за счёт ресурсов — ростет стоимость системы.

anonymous ()
Ответ на: комментарий от anonymous

функциональность - не цена, а профит,

ценой (- производной в том числе от функционала) могло бы быть падение производительности,

но при грамотно организованном пуле (L2ARC, ZIL на правильных enterprise SSD) происходит увеличение производительности

sanyock ★★ ()
Ответ на: комментарий от anonymous

демагогия

что значит демагогия?

я аналогично могу заявить, что квалификация моего комментария демагогией - есть демагогия,

можно ответить по существу вопроса?

sanyock ★★ ()
Ответ на: комментарий от sanyock

например, какая файловая система может обеспечить для СУБД в процессе реорганизации базы производительность на уровне 50-100 тысяч IOPs, если массив в основном представлен дисками HDD с IOPS около 100 единиц на диск?

ZFS при этом будет работать на несколько порядков быстрее (в 100 раз)

sanyock ★★ ()
Ответ на: комментарий от sanyock

подразумевается на контроллерах без батарейки или на контроллерах с батарейкой и отключенным кэшем записи, потому что кэш записи контроллера таит в себе определенный риск, как и использование проприетарных дисковых контроллеров вообще

sanyock ★★ ()