Алексей
дичь какая то
d
ОЗУ хватает? LA не растёт?
16гигов, раьше хватало нагрузка нулевая
Владимир
16гигов, раьше хватало нагрузка нулевая
ну ты посмотри метрики перед зависанием сколько свободно?
Владимир
Не могу поймать. виснет раз в неделю
поставь сбор метрик на другой сервер следи хотя бы за LA и ОЗУ
d
С которого я и пишу сейчас. Ещё из интересного - reset не помогает, какие-то ошибки насчёт дисков сыплются (сфоткать не догадался). Только выключение и включение помогает.
d
В какой-то хитрый режим контроллер встаёт, что ли. Раньше до обновления на 2.х такого не было.
George
В какой-то хитрый режим контроллер встаёт, что ли. Раньше до обновления на 2.х такого не было.
2.x пока имеет проблемы, судя по баг трекеру, либо репортьте (там уже была пара похожих issues про фризы), либо пока на 0.8 посидеть
George
свежак же)
George
Да мне не критично так то, просто неприятно
тогда по возможности артефакты в баг трекер постьте плиз
d
Виснет намертво, даже курсор в х11 виснет
George
если что увидите
d
вот что странно
d
tty, magic sysrq?
не, не работает
d
tty не проверял, а sysrq нет
Ivan
Виснет намертво, даже курсор в х11 виснет
какая ось ? я на 11 дебиане без проблем живу с zfs2.
George
кстати да, были ещё проблемы с 5.10 ядром или 5.11
Murmuring
Добрый день! Под бекап сервер Raidz2 здравая идея?)
Murmuring
или raid10 поставить. Интересна прежде всего надёжность ,скорость не так важна )
Ivan
Добрый день! Под бекап сервер Raidz2 здравая идея?)
кому как. у меня много бэкапов делается и на raidz2 оказалось совсем уныло. пришлось raid10 делать.
d
какая ось ? я на 11 дебиане без проблем живу с zfs2.
Linux *** 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux
George
если надежность нужна, то raidz3 будет норм )
надёжность выше только у draid будет) который пока не в стейбле
Ivan
Linux *** 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux
у меня до релиза 0.8.6 (кажется на ядре 5.9) были проблемы из-за наличия свапа. потом пришло новое ядро, zfs 0.8.6 и с тех пор вообще нет проблем. а до этого просто не юзал swap.
d
У меня были зависания тоже, их вылечили. Но теперь вот намертво, а раеньше висла как бы только дисковая подсистема а остальное продолжало работать
Алексей
однофамилец значит
George
однофамилец значит
не только😁
Алексей
😅😅
Ivan
Evgenii
Нужно экспертное мнение. В соседнем чате Proxmox разгорелся извечный спор про sync=disabled Мнение большинства: sync=disabled и отключение питания может привести к поломке базы (в те моменты, когда sync=enabled не привел бы к поломке базы) Мое мнение: для любой standalone базы данных нет никакой разницы включен sync или выключен. Если sync выключен - результат будет таким же, как если бы питание отключили на несколько секунд раньше. (мы потеряем эти пару секунд и только) Мои доказательства на рисунке: Если последняя успешная транзакция после восстановления питания точка 1: то база забудет про fsync если точка 2, то все данные, которые могли быть нужны на момент вызова fsync уже будут на диске
Evgenii
интересно мнение @gmelikov
Ivan
уж не раз спорили, каждый при своем останется.
Evgenii
Я прекрасно понимаю "откуда ноги растут". Если взять не Copy on Write файловую систему (NTFS, EXT), то там при изменении файлов, часть блоков где раньше была старая информация прямо в лоб перезаписывается. Там вообще много проблем может быть после отключения питания. Возможно большинство переносят опыт с других файловых систем.
George
Нужно экспертное мнение. В соседнем чате Proxmox разгорелся извечный спор про sync=disabled Мнение большинства: sync=disabled и отключение питания может привести к поломке базы (в те моменты, когда sync=enabled не привел бы к поломке базы) Мое мнение: для любой standalone базы данных нет никакой разницы включен sync или выключен. Если sync выключен - результат будет таким же, как если бы питание отключили на несколько секунд раньше. (мы потеряем эти пару секунд и только) Мои доказательства на рисунке: Если последняя успешная транзакция после восстановления питания точка 1: то база забудет про fsync если точка 2, то все данные, которые могли быть нужны на момент вызова fsync уже будут на диске
> для любой standalone базы данных нет никакой разницы включен sync или выключен. +1, БД не каждый блок синхронной записью пишет, т.е. sync=enabled и sync=always даже для БД в большинстве случаев дадут разницу в перформансе (теоретически). ну и у любой уважающей БД должен быть механизм восстановления при оборванной записи, wal, всё такое
George
если кто считает что влияет, то тесты в студию плиз
George
Нужно экспертное мнение. В соседнем чате Proxmox разгорелся извечный спор про sync=disabled Мнение большинства: sync=disabled и отключение питания может привести к поломке базы (в те моменты, когда sync=enabled не привел бы к поломке базы) Мое мнение: для любой standalone базы данных нет никакой разницы включен sync или выключен. Если sync выключен - результат будет таким же, как если бы питание отключили на несколько секунд раньше. (мы потеряем эти пару секунд и только) Мои доказательства на рисунке: Если последняя успешная транзакция после восстановления питания точка 1: то база забудет про fsync если точка 2, то все данные, которые могли быть нужны на момент вызова fsync уже будут на диске
тут основной вопрос в гарантии порядка записи, если она обеспечивается (а это так), то восстановление после сбоя питания это дело БД и для неё должно быть штатной ситуацией.
George
Нужно экспертное мнение. В соседнем чате Proxmox разгорелся извечный спор про sync=disabled Мнение большинства: sync=disabled и отключение питания может привести к поломке базы (в те моменты, когда sync=enabled не привел бы к поломке базы) Мое мнение: для любой standalone базы данных нет никакой разницы включен sync или выключен. Если sync выключен - результат будет таким же, как если бы питание отключили на несколько секунд раньше. (мы потеряем эти пару секунд и только) Мои доказательства на рисунке: Если последняя успешная транзакция после восстановления питания точка 1: то база забудет про fsync если точка 2, то все данные, которые могли быть нужны на момент вызова fsync уже будут на диске
ну и мысленный эксперимент: - (1)пишем что-то - f(data)sync - (2)пишем опять что в enabled что в disabled fsync не гарантирует откат при возврате питания, а только ожидает сброса всего dirty буфера на диск в нужном порядке. Т.к. порядок итак обеспечивается в txg, то разницы нет
George
и обычно БД не пишут синхронно поблочно, ибо слишком дорого
nagual
А что говорит статистика ?
Алексей
Эксперт)
d
Фильм жирен, интересное в нем только начало где видна ошибка ata4 и конец
Albert
600мб на 5 минуты? 😭 не уважение к собеседникам
d
600мб на 5 минуты? 😭 не уважение к собеседникам
Первый раз видос снимал на этот телефон, новый он
d
Щас обрежу значимые кадры покажу
d
Думал, телега пережимает видосы сама
d
на первом экране биоса не хватает SSD устройства /dev/sdd
Ivan
похоже пора один мертвый диск снять
Ivan
биосу очень не нравится присутствие дохлого диска, оттого так долго инициализирует
d
биосу очень не нравится присутствие дохлого диска, оттого так долго инициализирует
После перезагрузки через отключение питания всё взлетает нормально. Через нажатие reset вот как на скринах.
Ivan
странно видеть dracut на дебиане.
Vladislav
замените проблемное железо, похоже, на SSD
Ivan
Почему?
по дефолту его там нет
d
замените проблемное железо, похоже, на SSD
Проблема вылезла после переезда на 2.х, раньше всё было ок
Ivan
Не понимаю логики
глючит мать/ссд или бп. или в любой комбинации.
d
по дефолту его там нет
В нём есть какая-то фича, которая мне была нужна. Не помню уже какая.
Владимир
Он вроде как то с лвм связан?
Ivan
Проблема вылезла после переезда на 2.х, раньше всё было ок
после обновления до 2.х стал зависать биос ? )
d
Может даже какое-то ядро без dracut было сломано когда-то вот и прижился он у меня
d
после обновления до 2.х стал зависать биос ? )
Стала таким вот образом виснуть система
d
И при перезагрузке через reset появляться то что на скринах