если о федорокомьюнити можно судить по хрычу, то...
Зря. Там очень хорошее комьюнити
Михаил
Mark ☢️
Нет. Кончил сразу
Vladimir
@ctrlok привет, тут твой доклад с rootconf-2016 в https://t.me/metrics_ru обсуждают, можешь туда заглянуть, вдруг у кого вопросы будут?
Seva
ок, спасибо)
Dmitry
Там норм ребята. Всегда по делу
Dmitry
Они там канеш ебутся постоянно со свежим говном
Dmitry
Но хорошие
🏳️ Phil
Кому интересно. borg обгоняет rsync на локальном бэкапе при идентичных условиях на неформализуемых веб данных порядка сотни тысяч файлов. Первый бэкап. Делал десяток замеров разных. Вот так. Кстати обосновать не могу. При этом rsync заметно диск зажевывает, а borg нет
Alexey
я думаю strace -c ответит на вопрос почему
Alexander 🐕
А ежели ядро поновее, то, может, и BPF на что сгодится
Roman
Alexey
потому что PTRACE работает везде. будь у них FreeBSD я бы посоветовал dtruss.
🏳️ Phil
кроме того, надо ещё делать какие-то выводы из прочитанного
Oleksandr
Кому интересно. borg обгоняет rsync на локальном бэкапе при идентичных условиях на неформализуемых веб данных порядка сотни тысяч файлов. Первый бэкап. Делал десяток замеров разных. Вот так. Кстати обосновать не могу. При этом rsync заметно диск зажевывает, а borg нет
А какая схема бекапа? Борг локально, а потом рсинк репозитория?
🏳️ Phil
нет. просто локально
🏳️ Phil
Ну вот товарищ гражданин @knutov делал это вроде удаленно
Oleksandr
Ну вот товарищ гражданин @knutov делал это вроде удаленно
Ну как-то ненадежность бекапы локально держать. А вот удалённо - интересно. Надо бы с нфс попробовать )
Nick
Кому интересно. borg обгоняет rsync на локальном бэкапе при идентичных условиях на неформализуемых веб данных порядка сотни тысяч файлов. Первый бэкап. Делал десяток замеров разных. Вот так. Кстати обосновать не могу. При этом rsync заметно диск зажевывает, а borg нет
Обоснование простое - борг пишет большими кусками, рсинк кучей мелких файлов плюс журнал
Nick
Ну как-то ненадежность бекапы локально держать. А вот удалённо - интересно. Надо бы с нфс попробовать )
Не надо. Тру путь там иметь на той стороне тоже борг
Nick
То есть поверх ссх
🏳️ Phil
Обоснование простое - борг пишет большими кусками, рсинк кучей мелких файлов плюс журнал
1. Какой журнал? 2. большими кусками... по метров пять что ли... но что это даёт? почему это быстрее? почему диск не так тупит?
Oleksandr
Не надо. Тру путь там иметь на той стороне тоже борг
В смысле синкарь репо через рсинк? Я не совсем понял.
Nick
1. Какой журнал? 2. большими кусками... по метров пять что ли... но что это даёт? почему это быстрее? почему диск не так тупит?
Файловой системы. Ну подумай сам же, глупость спрашиваешь )
Nick
В смысле синкарь репо через рсинк? Я не совсем понял.
С той стороны тоже борг. Они меж собой общаются поверх ссх
🏳️ Phil
Ну как-то ненадежность бекапы локально держать. А вот удалённо - интересно. Надо бы с нфс попробовать )
Это полумиф. Всё должно делаться исходя из цены вопроса потери и цены восстановления. Что-то так делать нельзя, что-то можно. Можно и NFS. Но там в теории норм через ssh тот же borg
Nick
Oleksandr
Ок, спасибо. Попробую через ssh
Nick
Там в доке все подробно есть
Nick
Доки отличные вообще
Nick
И авторы отличные
Lex
а как у borg с конкурентностью?
Lex
в плане если Я в один реп буду делать сразу несколько бекапов?
🏳️ Phil
ее нет. и не будет в этом смысле
🏳️ Phil
оно и прнятно
🏳️ Phil
А главное, это бессмысленно практически
Nikolay Markov
посоны, а с чего может возникать такая ситуация, что дженкинс не отслеживает завершение запущенного в джобе процесса? там нету никаких форков
Nikolay Markov
просто внезапно, когда все джобы завершились, я захожу на сервер и вижу, что код еще работает
Vladimir
Может Jenkins помирает и перехапускается в какой то момент?
Nikolay Markov
у меня там используется publish-over-ssh plugin
Nikolay Markov
есть шанс, что когда коннекшн должен завершиться по таймауту - дженкинс не убивает удаленно запущенный процесс
Nikolay Markov
если так - то это нефиговый баг
Lex
А главное, это бессмысленно практически
Ну почему -- удаленный хост и заливка по ssh со многих тачек.
🏳️ Phil
Что ты хочешь выиграть заливкой в одну?
Lex
Дедупликация?
🏳️ Phil
С разных машин? :/ Ты выиграешь меньше, чем потеряешь на распределенной транзакционности
🏳️ Phil
Делай последовательно. Кстати.
Nick
С разных машин? :/ Ты выиграешь меньше, чем потеряешь на распределенной транзакционности
нот тру. Например, у нас выигрыш очень большой.
Nick
Дедупликация?
в общем, в борге так не получится, потому что там кеш, который будет перестраиваться при бекапе с нового места, эксклюзивный лок и бекап с одного клиента в одну репу. Да, было бы лучше, если бы было можно, но даже без этого это пока самый лучший вариант, видимо, из всех.
🏳️ Phil
нот тру. Например, у нас выигрыш очень большой.
Ты иногда сначала говоришь, потом думаешь. А у тебя есть конкурентная запись? Ты чудесным образом родил боргу рапсределенные транзакции кэша чанков? Вот вся стоимость родов, поддержки и родовые травмы - вот это будут минусы. Я именно это имел ввиду. И сразу посоветовал кстати сделать последовательно
Nick
1) можно пересчитывать кеш при начале бекапа со следующего сервера, а можно перенести кеш с первого сервера. На этом проблема закрыта.
2) да, конкретно у нас выигрыш по дедупликации очень очень большой. Я проверял.
3) то что последовательно, если в одиин репозиторий, то по-другому и не получится.
4) если надо чтобы сам бекап всего произошел быстрее, то тогда очевидно каждый сервер в свой репозиторий
Nick
упирается там все в скорость работы lz4 в один поток в текущей версии и в следующей 1.1, поэтому даже на гигабитном линке можно лить на бекапный сервер 2-3-4 потока с ссд и, наверное, дофига потоков с обычных дисков.
🏳️ Phil
1) можно пересчитывать кеш при начале бекапа со следующего сервера, а можно перенести кеш с первого сервера. На этом проблема закрыта.
2) да, конкретно у нас выигрыш по дедупликации очень очень большой. Я проверял.
3) то что последовательно, если в одиин репозиторий, то по-другому и не получится.
4) если надо чтобы сам бекап всего произошел быстрее, то тогда очевидно каждый сервер в свой репозиторий
2. Я уже вижу да. 3. Мы очевидно теоретизировали 4. Кстати надо статейку на эту тему зарубить пока помнишь. Кэш не кэш, мой ляп, быстрее не быстрее
Nick
ну я вроде все в жж уже написал, кроме готовых скриптов под наш случай )
Nick
пропущенное есть в доке и в тикетах в гитхабе
🏳️ Phil
упирается там все в скорость работы lz4 в один поток в текущей версии и в следующей 1.1, поэтому даже на гигабитном линке можно лить на бекапный сервер 2-3-4 потока с ссд и, наверное, дофига потоков с обычных дисков.
а может и хорошо что упирается. зато это позволяет не упираться в диск
Nick
в диск я не упираюсь ни с одной из сторон
Nick
причем, с одной стороны я не упираюсь в диск в 10 раз, а с другой раз в пять
Nick
но авторы довольно твердо уверены, что в 1.2 они научатся параллелить процессы и тогда все будет быстрее
🏳️ Phil
потому что у тебя ssd. не везде есть ssd
Nick
ну погоди, ты упираешься либо в диск с одной из сторон, либо в скорость одного потока
Nick
ты все равно всегда во что-то упираешься
🏳️ Phil
тип того
Nick
если у тебя медленный диск с одной из сторон, то ты таки уже упираешься в диск и ничего хорошего от того что все медленно - нет
🏳️ Phil
Тип того
Nick
причем упираешься ты всегда со стороны источника
Nick
ну и вот что тогда ты за глупость выше сказал? )
Nick
а может и хорошо что упирается. зато это позволяет не упираться в диск
вот разве что у тебя в комплекте еще и такой медленный проц, что он оказывается медленнее дисков
Nick
но это просто ССЗБ со всех сторон
🏳️ Phil
Хмм... кстати, если делать одну репу на всё, то borg как-то странно "туда" отправляет повторные архивы. Ручками-то в пустую репу всё быстро, а тут он как-то того-с
🏳️ Phil
@knutov смотри, он у тебя в ~/.cache/borg/блаблабла/chunks.archive.d что-нибудь оставляет, или там всегда пусто?
Nick
пусто
🏳️ Phil
Что-то я напрягся. Если всё лить в одну репу, он меньше чем 15 секунд вообще ничего не делает. Это в сумме у меня выливается в какашку. Я не совсем понимаю, выиграю ли я, если не буду по пользователям бить, а сразу всю колбасу заправлю?
🏳️ Phil
ну в смысле у меня каждый пользователь - архив