Сейчас уже не воспроизведу, есть неплохая статья: www.thg.ru/storage/ntfs_osvobozhdaem_mesto_na_ssd/print.html.
Недостатки: согласно Microsoft, NTFS-сжатие сильно нагружает CPU, и не рекомендуется для использования в серверах, содержащих большие тома для чтения и записи. Есть запреты даже для домашнего использования. Сжатие стоит использовать для папок с относительно редкой записью и чтением. Что ещё более важно, не сжимайте системную папку Windows. Также, в теории, операции копирования должны происходить медленнее, потому как файловая система сначала распаковывает нужный файл, копирует или перемещает его и затем снова сжимает. Если послать такие файлы по сети, они тоже сначала распакуются и как следствие не сэкономят трафик.
Сырые логи не так важны как обработанные, но хранить их надо потому, что в 5% случаев мы к ним обращаемся, в других случаях мы используем собственную систему обработки и хранения логов LV, а также ENG стек(быстрый поиск, аналитика, графики в Grafana)
Я сторонник применять максимально простые, но в то же время эффективные решения для конкретной задачи. Наша задача эффективно хранить логи приложения в течении 30 дней при этом не создавать лишней нагрузки на сервера приложений и не требовать дополнительных вложений в инфраструктуру.
Да, такие ситуации могут случиться, но я глубоко убежден, что самая устойчивая в мире фигура треугольник. Поэтому мы ориентируемся на минимальное необходимое число 3, это касается как людей в командах так и конфигурации серверов.
Ситуации «Сервис упал по непонятной причине» мы стараемся не допускать, для этого внедряем всесторонний мониторинг, следим за показателями SLO/SLA, проводим нагрузочное, авто и регрессионное тестирование, выполняем канареечные деплои, а также автоматизируем ручные процессы администраторов. Ведь как известно самые частые действия приводящие к ошибке, это человеческий фактор.
На любой ПК — имеется ввиду ПК администраторов приложения, в сырых логах есть StackTrace ошибок которые мы не пишем в ElasticSearch чтобы экономить место.
Сегодня мы осуществляем поддержку приложения в троем, а 8 лет назад нас было 12 человек! При этом тогда это был только фрон-офис и 4 тестовые среды, а сейчас 2 фронт-офиса куча микросервисов и более 20 тестовых сред. Все это благодаря автоматизации нашей работы.
Согласен, что поддерживать специализированные решения не простая задача, но компьютер способен работать в 1000 раз эффективнее человека, надо только научить. Поэтому мы стараемся автоматизировать все к чему прикасаемся. :-)
Это позволяет нам постоянно развиваться, а также оставаться эффективными не увеличивая расходы на людей.
Спасибо попробую zipx
Недостатки: согласно Microsoft, NTFS-сжатие сильно нагружает CPU, и не рекомендуется для использования в серверах, содержащих большие тома для чтения и записи. Есть запреты даже для домашнего использования. Сжатие стоит использовать для папок с относительно редкой записью и чтением. Что ещё более важно, не сжимайте системную папку Windows. Также, в теории, операции копирования должны происходить медленнее, потому как файловая система сначала распаковывает нужный файл, копирует или перемещает его и затем снова сжимает. Если послать такие файлы по сети, они тоже сначала распакуются и как следствие не сэкономят трафик.
Сырые логи не так важны как обработанные, но хранить их надо потому, что в 5% случаев мы к ним обращаемся, в других случаях мы используем собственную систему обработки и хранения логов LV, а также ENG стек(быстрый поиск, аналитика, графики в Grafana)
Я сторонник применять максимально простые, но в то же время эффективные решения для конкретной задачи. Наша задача эффективно хранить логи приложения в течении 30 дней при этом не создавать лишней нагрузки на сервера приложений и не требовать дополнительных вложений в инфраструктуру.
Я давно от этого отказался, так как есть существенное влияние на cpu, для файл сервера это применимо, но для сервера приложений нет.
Ситуации «Сервис упал по непонятной причине» мы стараемся не допускать, для этого внедряем всесторонний мониторинг, следим за показателями SLO/SLA, проводим нагрузочное, авто и регрессионное тестирование, выполняем канареечные деплои, а также автоматизируем ручные процессы администраторов. Ведь как известно самые частые действия приводящие к ошибке, это человеческий фактор.
Согласен, что поддерживать специализированные решения не простая задача, но компьютер способен работать в 1000 раз эффективнее человека, надо только научить. Поэтому мы стараемся автоматизировать все к чему прикасаемся. :-)
Это позволяет нам постоянно развиваться, а также оставаться эффективными не увеличивая расходы на людей.