Комментарии 48
Пять миллионов в сутки для какого-то ООО «Хоум Кредит Энд Финанс Банк»?
Просто у всех разные представления о высокой нагрузке ;)
У нас приложение для сотрудников, это около 2500 одновременно работающих операторов за 5 мин
А с zstd не экспериментировали? Для 7-zip есть форк с его поддержкой или же плагин для официальной версии.
Нет я выбирал из масмаркета, чтобы бала возможность быстро разархивировать в случае необходимости на любом ПК.

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

На любой ПК — имеется ввиду ПК администраторов приложения, в сырых логах есть StackTrace ошибок которые мы не пишем в ElasticSearch чтобы экономить место.

zstd не самый лучший выбор, если интересует скорость компрессии, например

вы серьёзно? скорость компрессии как раз сильная сторона zstd (например, на дефолтном уровне коэффициент сжатия примерно как у deflate, но сжатие в разы быстрее)

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

Аномалии можно не упаковывать, это позволит их находить вовремя.

Думаю, что это довольно сильная работа… но хотелось бы написать несколько о другом. О структуре расходов в IT.
Работал я в одной компании не очень давно. 200Gb в день — это только с Firebase Analytics приходило… В общем всё жило в BigQuery. Ничего (очень сложного) писать было не нужно. Дешевле использовать что предлагают по умолчанию, чем писать (а главное поддерживать) специализированные решения. Главные расходы — люди.
Сегодня мы осуществляем поддержку приложения в троем, а 8 лет назад нас было 12 человек! При этом тогда это был только фрон-офис и 4 тестовые среды, а сейчас 2 фронт-офиса куча микросервисов и более 20 тестовых сред. Все это благодаря автоматизации нашей работы.
Согласен, что поддерживать специализированные решения не простая задача, но компьютер способен работать в 1000 раз эффективнее человека, надо только научить. Поэтому мы стараемся автоматизировать все к чему прикасаемся. :-)
Это позволяет нам постоянно развиваться, а также оставаться эффективными не увеличивая расходы на людей.
Один уехал в отпуск, второй заболел, третий спит. Сервис упал по непонятной причине. Ваши действия?
Ещё был случай, когда один посреди пустыни, а двое отравились обедом, и как всегда именно в этот момент…
Да, такие ситуации могут случиться, но я глубоко убежден, что самая устойчивая в мире фигура треугольник. Поэтому мы ориентируемся на минимальное необходимое число 3, это касается как людей в командах так и конфигурации серверов.
Ситуации «Сервис упал по непонятной причине» мы стараемся не допускать, для этого внедряем всесторонний мониторинг, следим за показателями SLO/SLA, проводим нагрузочное, авто и регрессионное тестирование, выполняем канареечные деплои, а также автоматизируем ручные процессы администраторов. Ведь как известно самые частые действия приводящие к ошибке, это человеческий фактор.

"rar, 7z и zip"?
Многопоточный pigz должен их всех уделать.
Попробуйте и покажите результаты...

Судя по статье, автор тестировал архиваторы/упаковщики под винду. С pigz надо использовать tar, а это для винды не совсем нативный сценарий. Ну и тогда уж сравнивать надо с zstd (zstdmt), а не pigz ибо последний в большинстве тестов проигрывает как по скорости, так и по степени сжатия

В 7-Zip поддерживается несколько алгоритмов сжатия (напр. PPMd), для логов имеет смысл попробовать и альтернативные алгоритмы.

я может выскажу непопулярную мысль, но бэкап должен быть таким, чтобы можно было восстановиться в случае любого форсмажора. Чтобы когда сисадмин был пьян, и в наличии только новенький слепой стажер; когда все сервера сгорели, и доступен только 386 из музея, когда ядерный взрыв сжег сжег к чертям сервер активации виндоус, чтобы даже тогда бэкап разворачивался без проблем.
Я за tgz короче. Потомки вам скажут спасибо.

Если я правильно понял пост, то в нем не идёт речи про бекап

Попробуйте Winzip и его формат zipx. У меня на логах получалось заметно лучше сжатие, чем 7z и rar. На моих данных логи ужимаются в 15-17 раз (размер данных в архиве 17-30 ГБ до сжатия), winrar и 7zip на максималках давали сжатие 10-11 раз. При этом 7zip на максималке сильно медленнее winzip.
А почему не попробовали xz?
по сжатию он показывает одни из наилучших результатов, особоенно для повторяющегося текстового контента типа логов.

Если там NTFS, можно поставить папке с логами атрибут сжатия. Бекапу это не поможет, но логов влезет больше и делается просто.

Я давно от этого отказался, так как есть существенное влияние на cpu, для файл сервера это применимо, но для сервера приложений нет.

Сейчас уже не воспроизведу, есть неплохая статья: www.thg.ru/storage/ntfs_osvobozhdaem_mesto_na_ssd/print.html.
Недостатки: согласно Microsoft, NTFS-сжатие сильно нагружает CPU, и не рекомендуется для использования в серверах, содержащих большие тома для чтения и записи. Есть запреты даже для домашнего использования. Сжатие стоит использовать для папок с относительно редкой записью и чтением. Что ещё более важно, не сжимайте системную папку Windows. Также, в теории, операции копирования должны происходить медленнее, потому как файловая система сначала распаковывает нужный файл, копирует или перемещает его и затем снова сжимает. Если послать такие файлы по сети, они тоже сначала распакуются и как следствие не сэкономят трафик.

Если эти логи архиважны то по моему скромному мнению ни о какой архивации бэкапов логов речь идти не может. Правильнее увеличить и задублировать в нужное кол-во раз место для этих бэкапов. Да — стоит денег, но не будет никаких проблем (возможность которых навскидку вижу аж несколько и случится они могут в самый неподходящий момент)

Сырые логи не так важны как обработанные, но хранить их надо потому, что в 5% случаев мы к ним обращаемся, в других случаях мы используем собственную систему обработки и хранения логов LV, а также ENG стек(быстрый поиск, аналитика, графики в Grafana)

НЛО прилетело и опубликовало эту надпись здесь

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

Максимально простое решение в этом случае. +2 ширпотребных накопителя по 8 тб. Ваши логи за 30 дней в несжатом виде занимают 4тб, в сжатом пусть 2 — все равно под них нужно выделить место. Да, это +$600, но никаких костылей с упаковкой-распаковкой, отличная скорость доступа и никакой нагрузки на процессор. Эксперименты с выбором правильного архиватора обошлись конторе немного дешевле ;)

Ваши логи за 30 дней в несжатом виде занимают 4тб, в сжатом пусть 2

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

НЛО прилетело и опубликовало эту надпись здесь
Дедупликация скорее всего мало что даст. Так как в логах как минимум постоянно вставляется дата и время события в каждую строку, и сами строки обычно меньше размера блока, который используется для дедупликации.
Странно что никто не спросил. Не пробовали дедупликацию? Под виндой очень даже хорошо работает и очень хорошо экономит место на диске. Особенно если для последующего анализа их надо распаковать, а тут просто задедуплицированны и можно спокойно смотреть. Или я не так понял посыл статьи для решения задач?
НЛО прилетело и опубликовало эту надпись здесь

Если вам действительно нужен рационально выверенный баланс между скоростью сжатия/разжатия и уровнем компрессии, то нужно использовать современные алгоритмы. Соответственно см https://github.com/mcmilk/7-Zip-zstd (там несколько алгоритмов, не только zstd).

Интересные тесты со странной интерпретацией. Вот нужное место:
ArchFileName5.7z -mx=5 7z 31239355 35169 118 943 825
ArchFileName4.rar -m4 rar 33514693 11426 126 306 180

Тут rar обеспечивает близкий результат компресии за время в 3 раза меньшее, чем 7z. И этот качественный скачок виден даже при беглом взгляде на график.
Предпочитая ему mx8, вы покупаете крохи в виде 26% относительного сжатия за умопомрачительные 1368% дополнительного времени.
Крохи — это не иносказательно. Хранение 130 ГБ — это грубо 250 рублей. Для верности представим, что вы так дорожите логами, что кладете их на RAID1. За 500 рублей. Месячный запас RAID1 для ваших ничем не жатых логов — 15000 руб.
То есть, ваша задача — не экономия пары банковских серебрянников, а возможность это добро передавать по сети. И для этого время важнее размера. Пока вы «кипятите», менее жатый архив уже можно было передать по сети на другое хранилище, в другой регион, облако и т.д.

Так, например, сливая файлы с vds, я сжимаю их «на лету» в gzip-2. Если поставить gzip-3 — архив будет немного меньше, но получу я файлы гораздо позже.

Хм, только сейчас обратил внимание на то, как вычисляется "Result %".
Некий "шарообразный в вакууме" оптимум точно найден, осталось понять для чего он оптимален )


Их линейка кривовата относительно здравого смысла. Оптимум выбирается видимо "по-банковски", как лучшая сделка из совершенных по покупке сжатия за время. Но ошибка в том, что в "пропорцию" на равных попадают все варианты, включая самые долгие, хотя жмут лишь чуточку лучше. Соответственно, время обесценивается относительно степени сжатия.


Нельзя сказать что это как-то совсем не правильно, критерии могут быть разные.
Но один из вариантов (с точки зрения оптимизации) — нулевое время без сжатия, и он линейку ломает.
А если добавить еще несколько экстремально долгих вариантов, то перекос будет еще больше.

Меня тоже сначала дизайн исследования привлек. Очень необычно, смело, без прелюдий. Относительное сравнение сразу бабашится в относительных величинах, без конвертации абсолютных значений. Такая жесткая военная логика: «Возьмем n танков. Нет, n мало. Возьмем k!».

Сама задача, конечно, не имеет практической ценности, так как узкое место всех этих самопальных скриптовых бэкап-экзерсисов — контроль ошибок и мониторинг. Надо проверять дожалось ли все корректно в убер-режиме, не было ли сбоя питания, не заполнен ли диск, запущены ли службы и так далее. Т.е., изобретать все, что испокон веков есть в стандартных открытых системах типа Bacula/Bareos.
Меня как будто откинуло на 20-30 лет назад. Arctest, fido ru.compress… Спасибо за ностальгию, конечно, но в 2020 реальность такова, что можно считать все архиваторы примерно одинаковыми, выбрать дефолтный zip и желаемую скорость.

UPD. Прикиньте, arctest ещё жив. Правда не обновлялся лет 20.
выбрать дефолтный zip и желаемую скорость

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

Без сжатия 3758 МБ
zip 618 МБ
rar 532 МБ
7z 426 МБ
zipx 345 МБ


При этом zipx сжимал 5 минут, а 7z — 25 минут, zip (с помощью 7-zip) — 20, rar — 12.

Т.е. простой выбор zipx вместо zip, получаем почти в 2 раза меньше платить бабла за хранилище, и в 4 раза меньше нагрузка на проц, вот и жмите теперь всё в zip. Причем когда логов за большее количество дней, то сжатие zipx еще лучше. В то время, как zip не поддерживает общий словарь.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Местоположение
Россия
Сайт
job.homecredit.ru
Численность
5 001–10 000 человек
Дата регистрации

Блог на Хабре