ZFS Storage pool Version: 5000 ZFS Filesystem Version: 5 FreeBSD 12.1-STABLE r361349 SUPPORT-12-1-0 18:18 up 23 days, 23:49, 5 users, load averages: 0,52 0,54 0,53

Вообще, в 8.1 по моему добавили ускорение синхронизации и скраба. Смысл в том, что при сильной фрагментации ресильвинг шел потранзакционно, создавая мощную нагрузку со случайным доступом. Но это дело пофиксили. Кроме того, это не должно зависить от включенности чексум. Если бы я столкнулся с подобным, я бы остановил ресильвинг и экспортировпл данные на новый пул через zfs send не отключая чексуммы.

А дедупликации не было включено?

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

дедупликация была влючена не на всех ZFS разделах

У меня какой-то клинч у системного пула.... https://pastebin.com/u03fpwmG не знаю, как из него выходить

вот история моей проблемы

По моему, вы столкнулись с тем, что метаданные не убрались в память, а устройство длительное время не было в пуле. Накопилось много транзакций и они синхронизировплись. А сильная нагрузка была вызвана поиском транзакций дедуплицированных данных. Я сталкивался со всевозможными тормозами при дедупликации и почти нигде её не использую, кроме пулов целиком из ssd в очень экзотических случаях. Остаётся неясным почему отключение сумм ускорило процесс. Логичного объяснения предложить не мону, кроме совпадения отключения сумм и окончания поиска метаданных.

как по мне, в случае сбойного устройства в рейде, нужно выключить проверку чексум, синхронихировать данные на новом устройстве, а потом включать проверку чексум и сделать проверку повторно

в мастер залили новую фичу rebuild, она сырые данные зеркалирует последовательно и максимально быстро, и запускает скраб только после того, как сырые данные засинкались А полностью проверку на чексуммы в это время, конечно, отключать не стоит)

вот история моей проблемы

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

Я не нашёл, как поблочно смотреть в читабельном виде.

насчет фрагментации - хз: # zpool list zroot NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT zroot 456G 130G 326G - - 58% 28% 1.14x ONLINE -

Да и пул не большой и занято немного совсем и коэффициент дедупликации тоже не большой. Тут и 4Г памяти на всё должно хватить. Странно.

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

Раньше оценка была 4ГБ + 1Г * (размер данных до дедупликации в ТБ) + 320 байт *(кол-во дедуплицированных блоков). Но тут всего-то 130Г - это ни о чем. Я не сталкивался с не стабильной работой начиная с zfs 8.1, даже если под arc отдано всего 4ГБ. А arc ещё и сжимается. Но как во freebsd не знаю.

я руководствуюсь чиселками от старого зфс, который в оракле был

Оттуда же. Но само, собой, если памяти мало, увеличивается io на диски. Но zfs не падает.

а, вижу. я про минималку на машину говорю. :)

Ну, все равно завышенная оценка. У меня 4ГБ ARC на ~4ТБ пул. Под ARC всего 4ГБ и ничего не упало, конечно это предельный случай. Просто памяти не хватает очень под другие задачи, а с iops проблем нет. Хотя я же не знаю, может быть у вас там oracle крутится 😊 По моему, если меньше 1ГБ для ARC может начать глючить., раньше на 7.x сталкивался с этим, но давно не пробовал меньше 4ГБ выдать. Ещё раньше гарантированно можно было поиметь проблем, если swap на zvol разместить. Как только туда начинало что-то выгружаться, система постепенно замелялась и в конце концов вставала колом.

Касательно памяти, у меня zol под ненагруженной торрентокачалкой с атомом 2500, 3 Гб ddr2 и древним 1тб wd green нормально жила года полтора, потом домашний сервак обновил.

какие вы везучие. :)

или это потому, что зол

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

какие вы везучие. :)

в общем то плюсую другим ораторам, гонял zol на 4гб ОЗУ на всю систему с жадными потребителями и huge pages, из которой на arc оставалось итого сколько повезёт (чаще он был до 300МБ), ему пофиг, главное минималку занять, iirc это около 100МБ чтоли. Ну а так конечно же, чем больше памяти для ARC, тем меньше чтения улетит на диски :)

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

ARC не дружит с нативным линёвым механизмом эвикта - это факт. Даже если не используется, ARC в 50% хостовой рамы по-умолчанию в дистре Proxmox VE означает "уй тебе, а не остальные 50% для VM, надо было раньше лимит ставить".

ARC не дружит с нативным линёвым механизмом эвикта - это факт. Даже если не используется, ARC в 50% хостовой рамы по-умолчанию в дистре Proxmox VE означает "уй тебе, а не остальные 50% для VM, надо было раньше лимит ставить".

ну тут стоит добавить, что это ещё и особенность qemu, который за 1 запрос памяти на огромный кусок ожидает её сразу получить (т.е. такое может происходить и не на zfs)

но проблемы там были, да, сейчас не мало фиксов было про arc за лето

в общем то плюсую другим ораторам, гонял zol на 4гб ОЗУ на всю систему с жадными потребителями и huge pages, из которой на arc оставалось итого сколько повезёт (чаще он был до 300МБ), ему пофиг, главное минималку занять, iirc это около 100МБ чтоли. Ну а так конечно же, чем больше памяти для ARC, тем меньше чтения улетит на диски :)

С лимитом в 4гб у меня спокойно работает пул 8тб и не жужжит

Там правда не поцгреса кластеры, но нагрузка есть

ARC не дружит с нативным линёвым механизмом эвикта - это факт. Даже если не используется, ARC в 50% хостовой рамы по-умолчанию в дистре Proxmox VE означает "уй тебе, а не остальные 50% для VM, надо было раньше лимит ставить".

Это так. Неудобство, но не критичное. Для серверов, обычно размер кэша планируется заранее, под нагрузку. По этому, ничего страшного. Меня этот диалог удивил тем, что похоже zol сейчас работает лучше чем старые нативные реализации и насколько! А сколько всего добавили! шифрование, vdev под таблицы дедупликации, vdev под метаданные - причем последнее мне очень сильно помогло, это гораздо полезнее ssd-кэша. А сколько улучшений в быстродействии. Я счастлив! 😊

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

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

В 0.8.3 есть же

Неужели? Не знал. Ура! (похоже рано)

Шифрованный zfs send точно был

Причём таргет не получает ничего в открытом виде, только шифрованный волюм

не не не, шифрованный отправляется, это я знаю. Другой кейс. Зашифровать прямо на лету типа zfs send —encrypt-on-the-fly —key-file /etc/...

Не удивлюсь, что и на этот случай есть какое-то заклинание из глубин манов.

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

Такого нету, сам мечтаю)

Не удивлюсь, что и на этот случай есть какое-то заклинание из глубин манов.

Не, на лету шифровать send не умеет сейчас

Собственно у меня root@nn-vm02:~# apt show zfsutils-linux Package: zfsutils-linux Version: 0.8.4-pve1 Прошерстил man, чуда не случилось.

Не, на лету шифровать send не умеет сейчас

Даже если пайпать?

Даже если пайпать?

Нативно шифровать)

Фишка именно в получении нативно зашифрованного потока в пул на той стороне и возможности делать scrub без ключа

Даже если пайпать?

а какая разница? И так уверен, send, навернове почти всегда через pipe используется.

Но радует ещё очень возможность возобновить прерванную передачу. Знаете почему btrfs не выстрелило? Оно не робастое. Мне очень нравится это слово, обозначающее возможность продолжать работу в условиях разного рода непредвиденных обстоятельств. Вот zfs робастый.

Добрый день где то читал что в 6 версии proxmox, сделали в ha возможность возврата vm на место, после того как узел возвращается в строй. Кто нибудь проверял?

Добрый день где то читал что в 6 версии proxmox, сделали в ha возможность возврата vm на место, после того как узел возвращается в строй. Кто нибудь проверял?

Такие вопросы надо в профильном чате задавать. Такой кросспостинг по множеству чатов не приветствуется.

#вопрос Доброго. Тут уже обсуждалось, но переспрошу. Под SLOG нормально будет такой диск, не самое же дно диск ? zfs на проксмоксе для виртуалок. https://www.dns-shop.ru/product/3ac84e30b9843330/240-gb-ssd-nakopitel-intel-d3-s4610-series-ssdsc2kg240g801/characteristics/

#вопрос Доброго. Тут уже обсуждалось, но переспрошу. Под SLOG нормально будет такой диск, не самое же дно диск ? zfs на проксмоксе для виртуалок. https://www.dns-shop.ru/product/3ac84e30b9843330/240-gb-ssd-nakopitel-intel-d3-s4610-series-ssdsc2kg240g801/characteristics/

На таких накопителях хостеры кластера виртуализации собирают. Линейки 4501, 4510, 4610.

На таких накопителях хостеры кластера виртуализации собирают. Линейки 4501, 4510, 4610.

Понял. Спасибо )

ну тут стоит добавить, что это ещё и особенность qemu, который за 1 запрос памяти на огромный кусок ожидает её сразу получить (т.е. такое может происходить и не на zfs)

кстати последние месяца 3 в проксе нет резкого захвата памяти виртуалками. старт новой вм кушает понемногу памяти.

Если пул имеет ashift=12 а потом я добавлю slog на ssd - на него ashift тоже распространится и его работа будет медленне чем с ashift=13 ? или для slog это не важно ?

Если пул имеет ashift=12 а потом я добавлю slog на ssd - на него ashift тоже распространится и его работа будет медленне чем с ashift=13 ? или для slog это не важно ?

для slog ашифт отдельно не указывается

#вопрос Доброго. Тут уже обсуждалось, но переспрошу. Под SLOG нормально будет такой диск, не самое же дно диск ? zfs на проксмоксе для виртуалок. https://www.dns-shop.ru/product/3ac84e30b9843330/240-gb-ssd-nakopitel-intel-d3-s4610-series-ssdsc2kg240g801/characteristics/

а сам пул из чего собран?

а сам пул из чего собран?

в плане raidz из 3 зеркал. Диски по 6Тб

в плане raidz из 3 зеркал. Диски по 6Тб

HDD?

да

4кб сектор

да

тогда любой ссд будет хорош для SLOG. Ну а данный - весьма неплох за свои деньги

#вопрос Доброго. Тут уже обсуждалось, но переспрошу. Под SLOG нормально будет такой диск, не самое же дно диск ? zfs на проксмоксе для виртуалок. https://www.dns-shop.ru/product/3ac84e30b9843330/240-gb-ssd-nakopitel-intel-d3-s4610-series-ssdsc2kg240g801/characteristics/

Но, вероятно, лучший прирост быстродействия вы получите, если разделите этот диск lvm-ом и часть выделите под special vdev (примерно 1% от размера данных в пуле), а осташееся под cach vdev. Slog вообще маленький требуется - 16Гб за глаза, он работает только для синхронной записи и держит данные только до записи в пул.

Само собой и slog и special должны быть в raid, а кеш - нет. Special vdev важнее кеша, в планн полезности в приросте быстродействия, по моему опыту.

зачем lvm в данном случае, когда можно партиции создать ?

Сложно точно расчитать размер special и кеша. Часто сталкивался с ситуацией когда специал забит, а кеш пустой это при аптайме в месяц. А с другой стороный special с большим запасом смысла не имеет. По этому, лучше выделить 1% от емкости данных в пуле на special, оставить 30% от ssd свободными, 16Гб под slog и по мере заполнения добавлять место куда не хватит. Очень удобно.

На таких накопителях хостеры кластера виртуализации собирают. Линейки 4501, 4510, 4610.

Самое главное, у них есть защита от потери данных - те самые конденсоторы. Остальные важные параметры: наработка на отказ (TBW) и скорость случайного чтения и записи при 100% покрытии. Тут сложно сказать. Скорее всего будет хорошо.

Но, вероятно, лучший прирост быстродействия вы получите, если разделите этот диск lvm-ом и часть выделите под special vdev (примерно 1% от размера данных в пуле), а осташееся под cach vdev. Slog вообще маленький требуется - 16Гб за глаза, он работает только для синхронной записи и держит данные только до записи в пул.

Спасибо за совет! Хотя я пока не сильно понимаю значения sprcial vdev. Кэш я думаю(и насколько знаю, предназначен для ускорения чтения), мне не нужен в данной ситуации.

Спасибо за совет! Хотя я пока не сильно понимаю значения sprcial vdev. Кэш я думаю(и насколько знаю, предназначен для ускорения чтения), мне не нужен в данной ситуации.

Вы ошибаетесь, фактически, он работает почти полностью на запись, и zfs редко читает с него данные, но если читает, то стразу много и это случайное чтение. На special vdev записываются метаданные и мелкие файлы, особенно метаданные для сильнофрагментированных участков, когда создано большое количество снимков. Польза в уменьшение случайной записи на относительно медленные диски. Диски начинают работать в основном линейно. Это очень сильно улучшает латентность. Приведу пример: файловый сервер, на сервере сетевые профили windows со всевозможными tmp-мапками, реестром и другими источниками случайного ввода-вывода. На сервере стояло 8 накопителей объемом 1ТБ, объединённые в 4 mirror vdev. Пул был занят на 75% Это работало удовлетворительно. Заменили дисковые устройства на 1 mirror vdev из 4TB Seagate Enterprice 7200RPM, занято 3ТБ и стало работать невыносимо медленно. Добавили ssd-кэш объемом 250ГБ, ситуация кардинально не улучшилась, кроме того, SSD-кэш требует "прогрева", т.к. данные после перезагрузки с него удаляются. Добавили один special vdev объемом 60ГБ, из его объема занято 30ГБ и работает всё превосходно! А вот и подробности про этот пул, усредненная нагрузка: root@bal-vm:~# zpool iostat -v capacity operations bandwidth pool alloc free read write read write --------------------- ----- ----- ----- ----- ----- ----- hdd-fast 3,00T 699G 10 55 150K 1,38M mirror 2,98T 665G 5 3 125K 485K dm-uuid-45840... - - 2 1 64,1K 242K dm-uuid-4dad5... - - 2 1 60,8K 242K special - - - - - - mirror 30,1G 33,4G 5 52 24,9K 930K dm-uuid-LVM-06... - - 2 26 12,5K 465K dm-uuid-LVM-Nk... - - 2 26 12,4K 465K logs - - - - - - mirror 0 15,5G 0 0 1 2 dm-uuid-LVM-06... - - 0 0 0 1 dm-uuid-LVM-Nk... - - 0 0 0 1 cache - - - - - - dm-uuid-LVM-06DD... 24,8G 231G 108 0 530K 52,2K

Обратите внимание, что на vdev падает столько-же iops сколько на обычные диски, причем это самые неудобные для механического диска iops.

Важный момент, создав special-vdev его нельзя уничтожить, но устройство удалить можно! Данные будут перенесены в пул и займут там место, нагрузка снова вернется на механические диски. С этого момента все обращения к vdev будут перенаправляться к перенесенному в пул устройству. Оно нигде, кроме статистики, не отображается.

Важный момент, создав special-vdev его нельзя уничтожить, но устройство удалить можно! Данные будут перенесены в пул и займут там место, нагрузка снова вернется на механические диски. С этого момента все обращения к vdev будут перенаправляться к перенесенному в пул устройству. Оно нигде, кроме статистики, не отображается.

vdev removal работает только в пулах БЕЗ raidz, очень важно этот не забыть)

пока

Сложно точно расчитать размер special и кеша. Часто сталкивался с ситуацией когда специал забит, а кеш пустой это при аптайме в месяц. А с другой стороный special с большим запасом смысла не имеет. По этому, лучше выделить 1% от емкости данных в пуле на special, оставить 30% от ssd свободными, 16Гб под slog и по мере заполнения добавлять место куда не хватит. Очень удобно.

имхо тут lvm не нужен, просто special сделайте первой партицией, а slog и l2arc далее. В случае "надо увеличить special" просто удаляете slog/l2arc, увеличиваете партицию special, а дальше zfs умеет занять новое место в партиции сам (иногда надо пнуть чтобы он это сделал с партициями) Потом возвращаете slog/l2arc в нужном размере

vdev removal работает только в пулах БЕЗ raidz, очень важно этот не забыть)

у меня зеркала в raidz 😒

имхо тут lvm не нужен, просто special сделайте первой партицией, а slog и l2arc далее. В случае "надо увеличить special" просто удаляете slog/l2arc, увеличиваете партицию special, а дальше zfs умеет занять новое место в партиции сам (иногда надо пнуть чтобы он это сделал с партициями) Потом возвращаете slog/l2arc в нужном размере

а смысл? вы разве спешл не в зеркале делаете?

vdev removal работает только в пулах БЕЗ raidz, очень важно этот не забыть)

не знал. Спасибо!

а смысл? вы разве спешл не в зеркале делаете?

ну это я про lvm отвечал) за скобками что nvme минимум 2 и тд

@Riv1329 надо время чтоб переварить вашу информацию ) Благодарю )

ну это я про lvm отвечал) за скобками что nvme минимум 2 и тд

Могу ошибаться, но мне кажется, что сата ссд повешенный на порт сата2 не будет толком нагружен

все упрется в процессоры

все упрется в процессоры

тем паче lvm надо выбросить, ещё один слой)