zfs kvm windows тормоза при записи

На том же zpool сделай еще один zvol и погоняй запись из линукса, смотри статистику и делай выводы, если поведение такое же, то неправильно создан zpool, если все в порядке то ищи проблему в винде.

~1.5 KIOPS на запись это тормоза по-твоему?

Размер zfs recordsize и кластера ntfs?

Если бы эти иопсы не были бы заняты чем-то своим...

ntfs 4 kb, zfs recordsize=128K

винду
Чего он там читает??

Не, ну вы реально смешной, всех много лет интересует вопрос: «чего это там винда хардом не по делу шуршит». Я серьезно. Вот прямо сейчас занимаюсь попыткой слить данные с виндового харда, при попытке подключить к уже существующей она чего-то начинает там шуршать и фиг вам а не доступ к харду, какого фига она там шуршит не понятно. В итоге сливаю с линукса.

Ну так и уменьши recordsize, чтобы его данные не надо было читать каждый раз при записи.

А это можно делать прямо на горячую на существующем пуле? И нужно тоже 4 кб поставить?

Судя по https://blogs.oracle.com/roch/entry/tuning_zfs_recordsize
можно всё.
«With ZFS, tuning this parameter only affects the tuned Filesystem instance; it will apply to newly created files.»
Но я бы делал это для новой ФС.

Да, размер recordsize надо БЫ ставить величиной с блок данных, которыми идёт обмен с диском, но на ZOL 4k говорят тормозит...

Да, размер recordsize надо БЫ ставить величиной с блок данных, которыми идёт обмен с диском, но на ZOL 4k говорят тормозит...

Можно сделать его ближе к 4K; сейчас при блоке 128K имеет место быть тридцатидвухкратное раздувание объема при чтениях. Если сделать размер блока 16K, то раздувание будет только четырехкратное, что в восемь раз лучше. А если венда читает за раз больше, чем 1 блок, то в среднем оно может быть еще меньше.

но ZVOL для венды придется таки создать новый с volblocksize поменьше, и скопировать в него содержимое старого, а потом старый удалить.

хотя если венда уже в ZVOL'е и ты при создании не указывал нестандартный размер блока, то он уже должен быть 8K. В самом деле:

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
rpool        216G   340G  2.26K  1.76K  18.1M  14.1M

2.26 * 8 - это приблизительно 18.1

крутить volblocksize, рамы скока, отложенная запись - добавочный тормоз

В QEMU кеширование writeback (при умолчательном nocache тормозило сильнее, но статы не смотрел)

Если у тебя винда на zvol, то попробуй использовать: nocache. Зачем тебе двойное кеширование? Оно ни к чему.

Небольшой оффтоп... а ZFS умеет live migration всей системы с одного винта на другой, чтобы не приходилось отрываться от работы и выключать комп? Вот pvmove умеет.

Кстати

threads или native

?

native

ZFS умеет live migration всей системы с одного винта на другой, чтобы не приходилось отрываться от работы и выключать комп? Вот pvmove умеет.

пулы зфс это как правило зеркала, замена диска в них не проблема, да и страйп можно превратить в зеркало на ходу

Создал раздел с recordsize 8k, новую ntfs тоже 8к. Ничего не изменилось :(

Интересно, что на свежесозданный раздел первый раз запись прошла нормально (30 гигов). Удаляю файл, перезагружаю виртуалку, начинаю писать другой файл - и на тебе, начинается это странное чтение. ARC 10 гигов., свободной памяти - 15.

А вот с nocache заглавной проблемы не возникает. Возникает другая - виртуалка просто замирает на 3-5 секунд переодически. При большой записи. Даже часы останавливаются, а потом нагоняют упущенное. И в итоге один и тот же файл получается пишется примерно одно и тоже время, что writeback, что nocache. Только WB виртуалку не вешает.

recordsize

На всякий случай - volblocksize надо менять для zvol.

Ты вопрос вообще понял?

В общем, я предполагаю, что имеет смысл уменьшить blocksize до 64к, посмотреть чего по оперативной памяти на сервере (посмотреть сколько ARC) - не менее 2-4 гб. для zfs должно быть в общем случае, и использовать nocache

Ты вопрос вообще понял?

Ответил он, конечно, немножко в сторону, но в принципе правильно. zpool replace можно сделать и для диска с загрузочным пулом без остановки системы. Не далее как пару дней назад проделывал это.

В общем, я предполагаю, что имеет смысл уменьшить blocksize до 64к

У него уже volblocksize для ZVOL'а равен 8K - он по умолчанию такой.

Интересно. Накатил свежую 7, гоняю - пока работает. Не исключено, что проблема и в видавшем виды win2008, который пережил P2V на hyper-v, а потом v2v на KVM. Пока тестирую дальше. Спасибо всем за советы!

Эээм, это какбэ очевидно, что рэйд умеет такое делать, иначе какой смысл, но pvmove это не о замене диска.

Одна бабка говорит, что Win - пишет по 64к страницам. А следовательно zvol, имеет смысл делать 64к.

Твоя бабка слышала звон, да не знает где он. Это mssql группирует запись.

А без «как правило» можно? Вон как один человек пишет:

http://keinkeinkein.livejournal.com/83541.html

Чтобы с 1 винта на 1 винт, целиком.

Ну так добавить диск и сделать зеркало, после завершения синхронизации отцепить первый диск, в чём проблема?

Ясно, спасибо.

То есть, никаких преимуществ связка LVM + ext4 перед ZFS не дает вообще?

Скорее нет, но zfs на линуксах само по себе не подарок, так что по ситуации надо смотреть.

нет у lvm козырей против zfs, все совсем наоборот

да уж больший подарок чем md+ext4. с ними гемора больше.

Ну так добавить диск и сделать зеркало, после завершения синхронизации отцепить первый диск, в чём проблема?

Слишком много ненужных действий. Можно тупо сделать 'zpool replace <poolname> <olddisk> <newdisk>' - одна команда и всего делов!

А для ZFS есть какое-нибудь приложение, которое на юниксовый mailbox пришлет письмо о том, что чек-суммы где-то перестали совпадать и винт пора перепроверять и менять?

это лучше к нашему эстонскому вымогателю денег, я лично пользуюсь заббиксом, качество проверки оценить сложно.

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

В общем то да. Есть какие-либо точные сведения о том, какими блоками оперирует ОС Windows, при записи или чтении? На файловом уровне?

dmesg в студию. Кажется столкнулся с аналогичной фиговиной.

https://github.com/zfsonlinux/zfs/issues/3835 погляди. Не похоже?

Обнаружил отключенный кеш на SAS дисках, что вносило ощутимую лепту в тормоза. Кеш включил. Теперь в виртуалке с кешем в режиме nocache уже можно жить. Хотя все равно рывки ощущаются, когда на сервер по rdp сидишь и тестируешь массированную запись. Заглавной проблемы в режиме Nocache не наблюдается. Результат CrystalDiskMark тут https://yadi.sk/i/BNP1PnLSqgCbh (диски 2 SAS 10K, RAID1)

По поводу writeback. Похожую проблему нашел тут https://github.com/zfsonlinux/zfs/issues/824

Реально создаем новый zvol, цепляем к винде, заполняем его почти полностью - все ровно. Стираем и начинаем писать заново - жопа с левым чтением в полный рост. Почему это происходит, пока не понял. Изменение volblocksize на это в моем случае не влияет. Чуть лучше становится с volblocksize=4K, но все равно читает. Меньше не пробовал, больше - все плохо.

и начинаем писать заново - жопа с левым чтением в полный рост

COW — говно! Тебе надо скопироват-при-записи 4к — читаем volblockszie, меняем 4к и записываем в новое место volblockszie

нет у lvm козырей против zfs

Простой, проверенный, работает не требуя никаких ресурсов.

Молоток vs бульдозер --- фанаты бульдозера им даже гвозди забивают и другим советуют

анонимус прав.

Почему же оно тогда при nocache не проявляется? Я же кроме кеширования ничего не меняю, а чтение уходит.

Поменял на тестируемом zvol logbias на throughput - практически полностью ушли заедания интерфейса на nocache. В тесте тоже стало все повеселее на записи: https://yadi.sk/i/n4Lt_80NqgJvY (класно все-таки кеш в zfs работает...).

Пожалуй данный результат для данного сервера меня уже устраивает, но если сообщество еще чего посоветует - с радостью опробую.

Я люблю zfs, но столкнувшись с проблемой, о которой я писал выше, я решил попробовать связку:

md1 - ssd (Intel) md2 - hdd (7200rpm) lvm cache: writeback + smq.

Затем, я тупо отформатировал всё это хозяйство в ext4, и положил туда raw образы. Плюс включил cache=none.

Затем, в Windows, результат таков: https://db.tt/14PQYzW0

Да, без zfs я не могу иметь сжатие. Но никто мне не запрещает включать сжатие внутри вирт. машин. Но зато, я думаю, что, lvm + mdadm + dm-cache, стабильный стек. Кеширование заработало сразу, без всяких костылей.

Да, без zfs я не могу иметь сжатие.

я так понимаю, аналога zfs send -i в LVM тоже нет.

Твой результат с SSD кешем? Собственно я был мотивирован в сторону ZFS твоей же темой :) (ovirt localstorage zfs). До этого я строгал mdadm/lvm сервера и в ус не дул, но там меня производительность почти не волновала. Правда пока до 1С у меня дело пока не дошло, но из-за нее и начал zfs крутить.

До этого я строгал mdadm/lvm сервера и в ус не дул, но там меня производительность почти не волновала.

Я был очень приятно удивлён, но: mdadm+lvm+lvmcache (writeback+smq)+банальный ext4+raw(qcow2 - пока не пробовал, но разницы думаю не будет), дали ОЧЕНЬ приятный результат. Попадание в кеш SSD - 100% (ну вестимо пока он не переполнится).

Win2008R2+MSSQL2008+1c 8.2+Гилёв - дали мне 31-37 попугаев. Вирт машине отдавал: 3ядра (3,4 ГГц), 2ГБ ОЗУ. По количеству пользователей, Гилёв мне давал разные оценки в зависимости от изменения настроек. Максимально что выдавал: 77пользователей.

В dmesg - никаких намёков на ошибки и нету, в отличии от zfs. Zfs on linux - очень, очень крутая штука. Но, я не могу просто позволить себе допустить фейлы - с остановкой вирт. машины в продакшене...

Чем заменить сжатие: ну можно использовать сжатие NTFS в видне. Или на линукс вирт. машинах, внутри машины - ставить zfs, и монтировать её как файловую систему (т.е. без zvol).

zfs send -i в LVM

Есть! С костылями, но есть. :) Мне на форуме в своё время тут её рекомендовал эту штуку с github (блин, не сохранил ссылку). Там в общем есть набор скриптов, которые это умеют делать. Сейчас погляжу.

Из плюсов mdadm+lvm+cache+ext4, над zfs:

• Нативно
• Не нужно выделять памяти для ARC
• ext4 не фрагментируется - и есть средство для дефграментации онлайн. Скажем, zfs, через пол годика работы со снепшотами - фрагментируется процентов так на 80... Против 4-6% - у ext. Но у zfs, кроме как пересоздавать том - нету особых средств для лечения.
• Работает очень быстро и предсказуемо (пока не нашёл проблем, во всяком случае)
• Можно уменьшать

Из минусов:

• Не умеет сжатие (лечится файловыми системами, с оным внутри виртуалок)
• Реализация снепшотов - плохая. (Зато нету фрагментации! Лечится тем, что можно положить на ext4 - qcow2 образы виртуалок и там снепшотить)
• zfs send -i отсутствует... Как класс. (лечится скриптами, с github. Пока не проверял.)
• mdadm в имплементации raid1/10 - не умеет делать scrub. Точнее делать то его умеет, но будет выдавать тучу ошибок, о якобы битых блоках. И это нормально - такая вот реализация. (лечится дисками с TLER, и регулярным скраббингом, чтобы выбивать из массива диски которые не успели отозваться за 7сек)

В общем то, всё остальное в zfs on linux - все фичи, вроде прав доступа, nfs и т.д. - в лучшем случае в Linux работают на половину, а в остальном - часть фич или не работает вовсе, или работает хреново (например, планировщик чтения, с массива, работает только в round robin и т.д.).

Это не значит, что я теперь хейтер zfs, но надо всё же взвесить все за и против... Скажем так... - Я с zfs (без zvol), в продакшене, живу больше года. На zvol вот увидел проблему. Фатальную проблему. Так что надо всё ещё раз взвесить. Ибо в случае факапа, я буду писать сюда из горящего танка и срать кирпичами...