Алексей
я, каюсь, не помню останавливал ли я его или нет
Сергей
можно попробовать это сделать. линукс это позволит сделать
Сергей
но на вменяемость он не проверит)
Алексей
но вообще это кластер, и в данный момент 121 контейнер запущен на другом хосте. нсколько мне известно в кластере не может быть двух контейнеров с одним ид
Алексей
Алексей
ну вернее я знаю как. просто удалить файлик из /etc/pve/lxc
Алексей
я собтвенно именно так и сделал
Алексей
короче ребут в любом случае
Алексей
не парьтеся, спасибо за помощь
Сергей
)))
Vikentsi
Вопрос знатокам zfs. Сколько рабочих дисков нужно чтобы собрать raidz3? 4 ? 1 и +3 на контрольные суммый? И сколько дисков может вылететь? 3?
Vikentsi
Я на формулу из man page смотрю
Vikentsi
Да. Спасибо. Я с точки зрения понимания. Как там страйпы эти раскладываются. Чуть позже пример заброшу.
Dmitry
Dmitry
И у меня как раз три вылетело
Ivan
речь не о принципиальной невозможности. только об эффективном использовании.
Ivan
Доброго вечера. ZFS пул перешёл в состояние DEGRADED причина простая, кабель отошёл и диска не было онлайн несколько дней, после возращения в онлайн сначала оно показывало норм потом деградировал из-за колличества ошибок. Вот у меня вопрос, как мне его обратно ввести в строй? достаточно просто очистить ошибки? или нужно проворачивать какие-то ещё действия?
#вопрос
Иван
Иван
И как это несколько дней, мониторинг есть? https://github.com/Cosium/zabbix_zfs-on-linux # шаблон Zabbix для мониторинга ZFS https://github.com/v-zhuravlev/zbx-smartctl SMART
Алексей
Имхо вообще не важно сколько он там дней отсутствовал. Очищаешь ошибки, скраб, очищаешь ошибки, скраб, очищаешь, ой запутался 😢
Владимир
Владимир
просто мы же не живём в датацентре))
Владимир
Владимир
я просто не нашёл внятной информации на эту тему
Алексей
Скраб запусти если он уже не в процессе
Владимир
что такое скраб?
Алексей
"починка"
Алексей
Посмотри zpool status poolname
George
zpool clear https://openzfs.github.io/openzfs-docs/man/8/zpool-clear.8.html?highlight=clear сбрасывает все старые ошибки
Александр🇷🇺
Hfu , @Ping0Pong привет
Александр🇷🇺
Боты?)
Алексей
Ребята, всем привет. Просто вопрос, если кто-то в курсе почему так происходит, или знает где об этом прочитать укажите пожалуйста.
вобщем делаю я zfs send инкрементальный датасета с одного сервера на другой через mbuffer (в норме скорость хорошая, 1гбит как раз сколько позволяет канал) промежуток между снапшотами (между первым который отправлен ранее и текущим который отправляется в данный момент) три дня. за это время набежало данных примерно столько:
zfs get used,referenced,written poold/subvol-204-disk-0@2
used 192M
referenced 4.22T
written 8.03G
так вот, большую часть времени инкрементальной отправки датасета почти ничего не происходит: чтение порядка 10-20 операций в секунду, половину времени вообще 0 или около того, с редкими всплесками до 200-300 продолжительностью пару секунд. (редкие - раз в несколько минут). по прошествии какого то времени на него снисходит возбуждение и передача начинается во весь опор (1гбит/сек) и завершается в течении минуты.
такое поведение я встречаю уже не первый раз, все инкременты у меня почему то отправляются именно с таким паттерном.
не могу взять в толк в чем дело, является ли это корректным поведением?
если что пул заполнен на 93% рекордсайз 1МБ, (насколько хватает моих знаний заполнненость пула не влияет на скорость чтения)
спасибо!
Сергей
@gmelikov, добрый день.
С точки зрения производительности случайного чтения/записи (75/25) вариант raid10 из 4x960 будет быстрее чем зеркало из 2x1.92? Насколько zfs может распаралелливать операции случайного чтения из разных vdev?
Алексей
Сергей, так у вас в обоих случаях количество vdev одинаковое? 😯
George
George
Алексей
а точно
George
Ребята, всем привет. Просто вопрос, если кто-то в курсе почему так происходит, или знает где об этом прочитать укажите пожалуйста.
вобщем делаю я zfs send инкрементальный датасета с одного сервера на другой через mbuffer (в норме скорость хорошая, 1гбит как раз сколько позволяет канал) промежуток между снапшотами (между первым который отправлен ранее и текущим который отправляется в данный момент) три дня. за это время набежало данных примерно столько:
zfs get used,referenced,written poold/subvol-204-disk-0@2
used 192M
referenced 4.22T
written 8.03G
так вот, большую часть времени инкрементальной отправки датасета почти ничего не происходит: чтение порядка 10-20 операций в секунду, половину времени вообще 0 или около того, с редкими всплесками до 200-300 продолжительностью пару секунд. (редкие - раз в несколько минут). по прошествии какого то времени на него снисходит возбуждение и передача начинается во весь опор (1гбит/сек) и завершается в течении минуты.
такое поведение я встречаю уже не первый раз, все инкременты у меня почему то отправляются именно с таким паттерном.
не могу взять в толк в чем дело, является ли это корректным поведением?
если что пул заполнен на 93% рекордсайз 1МБ, (насколько хватает моих знаний заполнненость пула не влияет на скорость чтения)
спасибо!
заполненность пуля влияет на фрагментацию = на hdd чтение может ухудшаться т.к. потребует больше иопсов. Я бы посмотрел а где же затыкается, мб по процу?
Сергей
George
George
Алексей
честно говоря, проц у меня конечно нагружен (майнит с помощью xmrig в это время), но я не замечал что нагрузка как то меняется когда запущен сенд и когда не запущен.
George
Сергей
понял)
George
Алексей
Алексей
версия та, с которой последний pve идёт
Алексей
не знаю как смотреть
Алексей
zfs-0.8.4-pve1
Алексей
zfs-kmod-0.8.4-pve1
Алексей
честно говоря не верю что на принимающей стороне проблемы, т.к. там новый диск пустой
Алексей
да и показатель mbuffer на отправляющей стороне на нулях, т.е. он пустой, всё передал
Сергей
@gmelikov - у меня есть ещё один вопрос. Возможно покажется нубским, но я так и не дошёл до полного просветеления))
logbias - latency или throughput. И в сочетании с пулами на ссд, в которых есть slog и просто из ssd без slog.
я исходил что мне нужна (в первую очередь для СУБД) - минимизация ответа ZFS о записи (особенно fsync). Поэтому ставил везде latency. А throughput предполагал что используется когда у нас есть постоянный поток записи (последовательная запись).
насколько я прав или нет?
Сергей
и я вседа создавал отдельный датасет для файлов самой БД и отдельный датасет для журналов (pg_wal в случае ПГ)
George
George
George
У меня правда руки не дошли в кишках logbias в итоге ещё покопаться
Сергей
Сергей
Сергей
и мне почему-то кажется что если latency, то он позволяет собрать txg чтобы они потом группой пошли на запись. А если throughput то он не будет собирать группу на запись, а сразу отправит. Что тоже может быть не всегда хорошо
George
George
George
Zil это журнал временный считай, при latency он используется (даже если нет slog, он просто на основные vdevs пишет), что позволяет отбросить надобность перед отдачей "ок" на fsync заниматься машинерией по подготовке txg
George
Сергей
тогда в любом случае получается что при латенси мы получим более быстрый fsync. а уже дальше пул соберёт txg и сделает окончательную запись. так?
George
Сергей
и использовать throughput на пуле из ссд опять таки есть смысл при потоковой записи больших блоков, когда нет смысла ждать когда соберётся txg и можно сразу писать
Сергей
Ага, потому latency:)
понял. ну значит чуйка как-то так и вела. А вот если ещё и в придачу у нас есть SLOG, то тогда в один vdev мы уже совсем не пишем дважды, а ZIL в свой, а txg в пул
George
Ага, когда throughput становится большеват на двойной записи)
George
Сергей
спасибо!)