zfs тормоза при копировании в виртуалках

Поставил оффтопики

Контроллер диска virtio -> драйвера virtio

рамы то на борту скока

Да, все так и есть везде virtio драйвера стоят

Рамы 64 гб, под arc 8 гб выделил, свопа нет

Попробуй локализовать проблему: попробуй копировать не внутри виртуалки, а просто на zfs, внутри ОС с proxmox.

Выравнивание разделов по границе блоков есть?

а можно как то убрать thin provision, что бы уже существующий диск занял должный размер?

preallocation даже на hdd почти ничего не даёт, а на ssd ничего не даст точно.

это как ? Я просто создал zfs pool

ну вот решил скопировать файл внутри виртуалки 20 гиговый, и все сразу зависло, что же за беда (

Команду создания в студию. Делал: ashift=12, при создании? Создавал по wiki proxmox?

Как хранятся виртуалки на zfs, в файлах или на zvol? Если на zvol, то нужно размер volblocksize делать больше значений по-умолчанию.
И, как выше уже сказали, надо понять какой ashift пригоден для твоих ssd, по-умолчанию ashift=9.

На форуме proxmox - я спрашивал. Собственно с каким размером создаётся zvol. Ответа не получил. Надо поглядеть это в свойствах zvol.

Посмотрел. Вот так эти засранцы создают zvol:

volblocksize 8K

Надо 128K?

На, погляди: https://github.com/zfsonlinux/zfs/issues/824

Говорят пофиксили одно, но есть другая проблема:

ARC space utilisation is still a problem with 8k zvols, but that is a separate matter.

«Thank you» to everyone who has contributed in the meantime for fixing this issue :)

да, по wiki proxmox, ashift 12

Надо 128K?

Я 128К делаю, при таком значении, по моим наблюдениям, iowait минимальный. Но от 32К уже нормально.

Ссучий proxmox, делает 8к. Блин, без пересоздания zvol это не фиксится же?

А какая ОС? Solaris / Linux / FreeBSD ?

Если соляра, то у нее нет поддержки virtio

linux debian 8

так что, пересоздавать ?

Цитата из доков:

VOLBLOCKSIZE указывает размер блока для томов. После записи
тома изменить размер блока невозможно, поэтому
его необходимо устанавливать при создании тома.
Стандартный размер блока для томов составляет 8
КБ. Допустимым является любой размер от 512 байт
до 128 КБ, соответствующий степени двойки.

ядро там какой версии?

4.2.8

zfs там модулем ядра?

proxmox же, это linux + zfsonlinux

да, модулем

рейд софтовый?

виртуалки в файлах/разделах/?

Да вот я понимаю это... Нужно править исходники proxmox. Или надеяться найти команды создания zfs в php скриптах.

да, рейд средствами zfs зеркальный, виртуалки на zvolume

так получается, делать бекап и переразбивать диски ?

P.S: компрессию есть смысл включать ?

На оба вопроса: да. :)

ой спасибо за помощь большое, в воскресенье забекаплюсь и сделаю, отпишу по результату.

А какой метод сжатия лучше будет для виртуалок ? Вот например нагугли л lzjb только статья старовата будет

нет, все зависит от того как организовано зеркало, для единичного диска или реда1 из двух дисков да блоксайз должен быть 128k

lz4

Допустимым является любой размер от 512 байт до 128 КБ

Вроде ж проскакивали откровения какого-то хостера видео, что у них 1Мб блоки работают.

для zvol ограничение в 128к

Кто объяснит?

Virtual machine images on ZFS should be stored using either zvols or raw files to avoid unnecessary overhead. The recordsize/volblocksize and guest filesystem should be configured to match to avoid overhead from partial record modification. This would typically be 4K. If raw files are used, a separate dataset should be used to make it easy to configure recordsize independently of other things stored on ZFS.

http://open-zfs.org/wiki/Performance_tuning

зависит от размера в/в от ОС, в случае экспорта zvol под вирт. диски оптимальным является 64к

в теории: если ты хочешь поиметь максимальный iops, то recordsize=FSClusterSize который обычно 4к,

в реале: т.к. драйвера ОС могут (и делают) группировать запросы в/в в большие блоки (винда например 64к-1м, фря 64к, линукс хз) то имеем компромисс в 64к.

вот для БД как правило теория совпадает с практикой

еще нюанс для zfs - чем меньше размер recordsize тем больше оверхед по метаданным (их изменять надо синхронно, места больше занимают в том же ARC)

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

Да точно, я старую солярисную доку процитировал. В ZoL с версии 0.6.5 запилили large_blocks up to 16Mb.

я про другую группировку

например, фс надо считать 16х4к блоков подряд, в контроллер идет запрос на чтение 1х64к блока. файлы обычно читаются последовательно.

про volblocksize здесь сказано

http://forum.ixbt.com/print/0011/045837.html

http://forum.ixbt.com/topic.cgi?id=11:45837:2409#2409

а сколько лучше делать для NTFS ? по размеру кластера - 4к или лучше размер кластера подогнать под размер volblocksize ? На самом деле это очень хороший вопрос И ответ на него будет зависеть от конфигурации vdev входящих в пул.

В качестве примера возьмём весьма распространённый vdev - raidz2 4+2. Механизм распределения Full Stripe (терминология традиционных RAID-систем) по дискам vdev всех типов raidz описан в заметке (http://uadmin.blogspot.ru/2006/07/raid-and-raidz-details.html) создателя zfs Джефа Бонвика. В ней же, попутно, раскрыт смысл термина динамический размер сегмента (https://blogs.oracle.com/bonwick/entry/raid_z_russian) zfs. В нашем примере запрос к vdev на запись 128КБ-го блока zfs вызовет запись 32КБ на 4 (четыре) data-диска + запись двух parity. Кстати, ИМХО во многом именно этим вызвана рекомендация о кратности степени 2 для data-дисков, преформат каждого диска vdev на блоки размером [128/кол-во data-дисков] КБ происходит при создании vdev. А вся «динамичность» размера сегмента (т.е. Full Stripe) в нашем случае будет заключаться в том, что без потери скорости и объёма на vdev будут записаны блоки объёмом 32, 64, 96 и 128КБ - и то хлеб в сравнении с записью только Full Stripe в традиционных RAID. Поэтому, очевидно, что наиболее релевантными размерами volblocksize для zvol и кластера NTFS в нашем случае будут 32 и 64КБ.

А для «raid10», в терминологии zfs? Какой размер кластера NTFS? 64/64?

Да понятно, не дурнее других. Но для мелкого рандома будет оверхед

мелкий рандом производят СУБД, а для них правило recordsize=pagesizeDB подходит хорошо, я же упоминал об этом

смотря какой юзкейс

если системный диск - 64к/4к

если БД - общее правило: volblocksize<=clustersize<=pagesizeDB

преформат каждого диска vdev на блоки размером [128/кол-во data-дисков] КБ происходит при создании vdev.

И где-же это ты такую ерунду вычитал?

А вся «динамичность» размера сегмента (т.е. Full Stripe) в нашем случае будет заключаться в том, что без потери скорости и объёма на vdev будут записаны блоки объёмом 32, 64, 96 и 128КБ - и то хлеб в сравнении с записью только Full Stripe в традиционных RAID

И ведь кто-то этот бред прочитает и примет за чистую монету.

отдохни мальчик, при выборе блоксайза нужно исходить из структуры массива, если это рейд10 на 4-х дисках то 64k, если на 8-и дисках (4-х зеркалах) то 32k

для 10-ки на 4-х дисках 64k