Комментарии 48
5000 пользователей в сутки? Может 5 млн?
Какой резон подобной манипуляции?
Распаковывать сотни гигов продакшн логов на любом ПК — выглядит очень странно со многих сторон.
Например, безопасности.
zstd не самый лучший выбор, если интересует скорость компрессии, например
Возможно, для логов имеет смысл запилить свой собственный архиватор. Логи они как правило структурированы, и упаковать их можно эффективнее чем произвольный поток байтов.
Работал я в одной компании не очень давно. 200Gb в день — это только с Firebase Analytics приходило… В общем всё жило в BigQuery. Ничего (очень сложного) писать было не нужно. Дешевле использовать что предлагают по умолчанию, чем писать (а главное поддерживать) специализированные решения. Главные расходы — люди.
Согласен, что поддерживать специализированные решения не простая задача, но компьютер способен работать в 1000 раз эффективнее человека, надо только научить. Поэтому мы стараемся автоматизировать все к чему прикасаемся. :-)
Это позволяет нам постоянно развиваться, а также оставаться эффективными не увеличивая расходы на людей.
Ещё был случай, когда один посреди пустыни, а двое отравились обедом, и как всегда именно в этот момент…
Ситуации «Сервис упал по непонятной причине» мы стараемся не допускать, для этого внедряем всесторонний мониторинг, следим за показателями SLO/SLA, проводим нагрузочное, авто и регрессионное тестирование, выполняем канареечные деплои, а также автоматизируем ручные процессы администраторов. Ведь как известно самые частые действия приводящие к ошибке, это человеческий фактор.
"rar, 7z и zip"?
Многопоточный pigz должен их всех уделать.
Попробуйте и покажите результаты...
В 7-Zip поддерживается несколько алгоритмов сжатия (напр. PPMd), для логов имеет смысл попробовать и альтернативные алгоритмы.
по сжатию он показывает одни из наилучших результатов, особоенно для повторяющегося текстового контента типа логов.
Если там NTFS, можно поставить папке с логами атрибут сжатия. Бекапу это не поможет, но логов влезет больше и делается просто.
Я давно от этого отказался, так как есть существенное влияние на cpu, для файл сервера это применимо, но для сервера приложений нет.
Недостатки: согласно Microsoft, NTFS-сжатие сильно нагружает CPU, и не рекомендуется для использования в серверах, содержащих большие тома для чтения и записи. Есть запреты даже для домашнего использования. Сжатие стоит использовать для папок с относительно редкой записью и чтением. Что ещё более важно, не сжимайте системную папку Windows. Также, в теории, операции копирования должны происходить медленнее, потому как файловая система сначала распаковывает нужный файл, копирует или перемещает его и затем снова сжимает. Если послать такие файлы по сети, они тоже сначала распакуются и как следствие не сэкономят трафик.
Если эти логи архиважны то по моему скромному мнению ни о какой архивации бэкапов логов речь идти не может. Правильнее увеличить и задублировать в нужное кол-во раз место для этих бэкапов. Да — стоит денег, но не будет никаких проблем (возможность которых навскидку вижу аж несколько и случится они могут в самый неподходящий момент)
Я сторонник применять максимально простые, но в то же время эффективные решения для конкретной задачи. Наша задача эффективно хранить логи приложения в течении 30 дней при этом не создавать лишней нагрузки на сервера приложений и не требовать дополнительных вложений в инфраструктуру.
Максимально простое решение в этом случае. +2 ширпотребных накопителя по 8 тб. Ваши логи за 30 дней в несжатом виде занимают 4тб, в сжатом пусть 2 — все равно под них нужно выделить место. Да, это +$600, но никаких костылей с упаковкой-распаковкой, отличная скорость доступа и никакой нагрузки на процессор. Эксперименты с выбором правильного архиватора обошлись конторе немного дешевле ;)
Если вам действительно нужен рационально выверенный баланс между скоростью сжатия/разжатия и уровнем компрессии, то нужно использовать современные алгоритмы. Соответственно см 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 %".
Некий "шарообразный в вакууме" оптимум точно найден, осталось понять для чего он оптимален )
Их линейка кривовата относительно здравого смысла. Оптимум выбирается видимо "по-банковски", как лучшая сделка из совершенных по покупке сжатия за время. Но ошибка в том, что в "пропорцию" на равных попадают все варианты, включая самые долгие, хотя жмут лишь чуточку лучше. Соответственно, время обесценивается относительно степени сжатия.
Нельзя сказать что это как-то совсем не правильно, критерии могут быть разные.
Но один из вариантов (с точки зрения оптимизации) — нулевое время без сжатия, и он линейку ломает.
А если добавить еще несколько экстремально долгих вариантов, то перекос будет еще больше.
Сама задача, конечно, не имеет практической ценности, так как узкое место всех этих самопальных скриптовых бэкап-экзерсисов — контроль ошибок и мониторинг. Надо проверять дожалось ли все корректно в убер-режиме, не было ли сбоя питания, не заполнен ли диск, запущены ли службы и так далее. Т.е., изобретать все, что испокон веков есть в стандартных открытых системах типа Bacula/Bareos.
выбрать дефолтный 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 не поддерживает общий словарь.
Выбор архиватора для бэкапа логов