Ваш файл журнала слишком большой

Обновлено: 04.07.2024

Как обычно, я выполнил команды, в строке sudo apt-get clean которых сценарий немного улучшился. Затем я удалил повернутые файлы журнала, что опять же дало очень небольшое улучшение.

При осмотре я обнаружил, что некоторые файлы журналов /var/log выросли до очень больших. Чтобы быть конкретным, ls -lSh /var/log дает,

Как мы видим, первые два являются оскорбительными. Я слегка удивлен, почему такие большие файлы не были повернуты.

Так что я должен делать? Просто удалите эти файлы и затем перезагрузите компьютер? Или пойти на несколько более разумных шагов?

Я использую Ubuntu 14.04.

ОБНОВЛЕНИЕ 1

Начнем с того, что системе всего несколько месяцев. Мне пришлось установить систему с нуля пару месяцев назад после сбоя жесткого диска.

Теперь, как советовали в этом ответе , я сначала проверил файлы журнала, использующие ошибки tail , что неудивительно. Затем для более глубокой проверки я выполнил этот сценарий из того же ответа .

Процесс занял несколько часов. Выход был в строке,

( /dev/sda3 это мой домашний каталог. Как мы можем найти,

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

Затем из этого ответа (вы можете проверить это для более глубокого понимания), я выполнил,

Теперь эти файлы имеют нулевой размер. Система работает нормально до и после перезагрузки.

Я буду смотреть эти файлы (вместе с другими) в течение следующих нескольких дней и сообщать о том, будут ли
они вести себя не по назначению.

И последнее замечание: оба поврежденных файла ( kern.log и syslog ) настроены для поворота, как показывает проверка файлов ( grep помогла) внутри /etc/logrotate.d/ .

ОБНОВЛЕНИЕ 2

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

Есть ли что-нибудь в этих файлах журналов, что дает представление о том, почему они такие большие? Удалите и перезагрузите, а затем следите за ними, чтобы увидеть, если они растут по экспоненте. @ Douggro Действительно, есть. Пожалуйста, смотрите мое обновление на вопрос.

Просто удалите эти файлы и затем перезагрузите компьютер?

Нет. Очистите их, но не используйте, rm потому что это может привести к сбою чего-либо, пока вы набираете touch команду для ее воссоздания.

Если не рут это потребует sudo . Взято из другого ответа на AU.

ДО ТОГО, ЧТО ВЫ ДЕЛАЕТЕ ЭТО. Сделайте tail и проверьте, есть ли причина для них быть такими большими. Если этой системе уже несколько лет, не должно быть никаких причин для этого, и решение проблемы лучше, чем позволить этому продолжаться.

И kern.log, и syslog обычно не должны быть такими большими. Но, как я уже сказал: если эта система запущена и работает годами и годами, это может быть нормально, и файлы просто необходимо очистить.

И чтобы это не стало таким большим в будущем: настройка logrotate . Это довольно просто и сжимает файл журнала, когда он становится больше, чем размер, установленный вами.

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

мой файл журнала в SQL Server использовал все пространство на моем диске. Я запускаю полные резервные копии каждую ночь, но файл журнала продолжает расти. Что я могу сделать?

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

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

причиной этой проблемы является открытая проводка в предыдущей части журнала. SQL не будет усекать журнал после этой транзакции, потенциально вызывая большой, постоянно увеличивающийся журнал. Вам нужно выяснить, какие транзакции остаются открытыми и почему?. Вы можете отслеживать пространство журнала с помощью:

информацию о длительных транзакциях можно найти с помощью:

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

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

стратегии резервного копирования для полного восстановления состоит из:

Я предлагаю вам обратиться к следующей ссылке Microsoft.

вы можете использовать какое-то вращение журнала и хранить только журнал фиксированного количества времени, скажем, за последние 7 дней. Этого должно быть более чем достаточно. Или вы можете сбрасывать журнал каждую ночь, потому что он должен быть в вашей резервной копии.

вы должны создать резервную копию журналов, а также основной базы данных

лучше добавить резервные копии журналов транзакций в расписание.

BACKUP LOG database TO DISK = 'D:/database_log.bak'

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

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

Это должно уменьшить его:

а затем сжать файл журнала, установив параметр autoshrink в настройках sql server или by.

Я думаю, вы можете использовать dbcc, чтобы сжать его тоже, но я не помню синтаксис.

удалить файл журнала?

Edit: по-видимому, удаление файла журнала плохо, это просто просто журнал в SQL server. Я оставляю это, чтобы повторить, чего не делать.

Как обычно, я выполнил команды в строке sudo apt-get clean , которая немного улучшила сценарий. Затем я удалили файлы с повернутым журналом, которые снова обеспечили очень небольшое улучшение.

После проверки я обнаружил, что некоторые файлы журналов в /var/log выросли до очень больших. Чтобы быть конкретным, ls -lSh /var/log дает,

Итак, что мне делать? Просто удалите эти файлы и перезагрузите компьютер? Или пойти на некоторые более разумные шаги?

Я использую Ubuntu 14.04.

ОБНОВЛЕНИЕ 1

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

Теперь, как указано в этом ответе , Я сначала проверил нарушающие файлы журнала, используя tail , не удивительно. Затем, для более глубокого контроля, я выполнил этот скрипт из того же ответа .

Процесс занял несколько часов. Выход был в строке,

( /dev/sda3 - мой домашний каталог. Как мы можем найти,

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

Затем из этого ответа (вы можете проверить this для более глубокого понимания), я выполнен,

Теперь эти файлы имеют нулевые размеры. Система работает нормально до и после перезагрузки.

Я буду смотреть эти файлы (вместе с другими) в течение следующих нескольких дней и отчитываться назад, чтобы они ведут себя вне очереди.

Как последнее замечание, оба файла-нарушителя ( kern.log и syslog ), настроены на поворот, так как проверка файлов ( grep помогла) внутри /etc/logrotate.d/ .

ОБНОВЛЕНИЕ 2

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

4 ответа

Просто удалите эти файлы и перезагрузите компьютер?

Нет. Удалите их, но не используйте rm , потому что это может закончиться сбойным, когда вы печатаете touch , чтобы воссоздать его.

Самый короткий метод:

Если не root, для этого потребуется sudo . Взято из другого ответа на AU.

ПЕРЕД ТЫ ДЕЛАЙТЕ ЭТО. Сделайте tail и проверьте, есть ли у них причина быть настолько большой. Если этой системе не исполнилось несколько лет, не должно быть никаких оснований для этого, и устранение проблемы лучше, чем позволить этому продолжить.

Оба kern.log и syslog обычно не должны быть такими большими. Но, как я сказал: если эта система работает и работает годами и годами, это может быть нормально, и файлы просто нужно очистить.

И чтобы это не стало таким большим в будущем: setup logrotate . Это довольно просто и сжимает файл журнала, когда он становится больше, чем размер, который вы ему установили.

1 другое: если вы не хотите удалять содержимое, вы можете сжать файлы, выполнив tarring или gzipping. Это приведет к тому, что вы в конечном итоге получите файлы, вероятно, 10% от того, что они сейчас представляют. То есть, если на диске все еще есть место.

Вероятно, стоит попытаться установить, что заполняет журнал (ы), - просто изучив их визуально, используя less или ---- +: = 1 =: + ----

, или если оскорбительные строки слишком глубоко погребены, чтобы легко увидеть, что происходит, что-то вроде

Мой метод для файлов системных журналов - это. Шаги 1 и 2 являются необязательными, но иногда вам нужно проверить старые журналы, и иногда полезно резервное копирование. ; -)

Дополнительно: Копировать файл журнала

Дополнительно: используйте Gzip для копирования журнала

Использовать /dev /null для чистого файла

И мы используем для этих журналов (только на нескольких серверах) logrotate и еженедельно выполняем cron-скрипт, который все файлы с * .1 (или следующим вращением) сжимают gzip.

Я установил Ubuntu 16.04 сегодня, и я заметил ту же проблему. Однако я исправил это с помощью busybox-syslogd. Ага! Я только что установил этот пакет и проблема была решена. :)

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

Мониторинг используемого пространства журнала

Для мониторинга используемого пространства журнала используйте sys.dm_db_log_space_usage. Это динамическое административное представление возвращает сведения об используемом сейчас журналом объеме пространства и сообщает, когда журнал транзакций требует усечения.

Для получения сведений о текущем размере файла журнала, его максимальном размере и параметре автоматического увеличения файла вы можете также использовать столбцы size, max_size и growth для данного файла журнала в представлении sys.database_files.

Избегайте переполнения содержащего журналы диска. Хранилище журналов должно отвечать требованиям к числу операций ввода-вывода в секунду и низкой задержке для транзакционной нагрузки.

Уменьшение размера файла журнала

Для уменьшения реального размера физического файла журнала необходимо выполнить его сжатие. Это полезно, если файл журнала транзакций содержит неиспользованное пространство. Вы можете сжать файл журнала, только если база данных активна и хотя бы один виртуальный файл журнала (VLF) свободен. В ряде случаев сжатие невозможно до тех пор, пока не выполнена следующая операция усечения журнала.

Такие факторы, как долго выполняемые транзакции, из-за которых виртуальные файлы журналов длительное время остаются в активном состоянии, могут ограничить или вовсе не допустить возможность сжатия журнала. Дополнительные сведения см. в разделе Факторы, которые могут вызвать задержку усечения журнала.

Сжатие файла журнала удаляет виртуальные файлы журнала, которые не содержат частей логического журнала (то есть, неактивные виртуальные файлы журнала). При сжатии файла журнала транзакций неактивные виртуальные файлы журнала в конце удаляются, чтобы журнал уменьшился приблизительно до целевого размера.

Перед сжатием следует учесть факторы, которые могут вызвать задержку усечения журнала. Если после сжатия журнала снова потребуется дисковое пространство, размер журнала транзакций снова будет увеличиваться, что повлияет на производительность во время операций увеличения. Дополнительные сведения см. в разделе Рекомендации этой статьи.

Сжатие файла журнала (без сжатия файлов базы данных)

Мониторинг событий сжатия файла журнала

Мониторинг пространства журнала

sys.database_files (Transact-SQL) (См. столбцы size, max_size и growth файла или файлов журнала.)

Добавление или увеличение размера файла журнала

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

Чтобы добавить файл журнала в базу данных, используйте предложение ADD LOG FILE инструкции ALTER DATABASE . Это позволяет увеличить размер файла.
Чтобы увеличить размер файла журнала, используйте предложение MODIFY FILE инструкции ALTER DATABASE с указанием синтаксиса SIZE и MAXSIZE . Дополнительные сведения см. в разделе Параметры инструкции ALTER DATABASE (Transact-SQL) для файлов и файловых групп.

Дополнительные сведения см. в разделе Рекомендации этой статьи.

Оптимизация размера журнала транзакций tempdb

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

Этого можно избежать с помощью увеличения размера журнала транзакций базы данных tempdb после запуска или перезапуска экземпляра сервера. Дополнительные сведения см. в статье tempdb Database.

Управление увеличением размера файла журнала транзакций

Для управления увеличением файла журнала транзакций используйте инструкцию ALTER DATABASE (Transact-SQL) с параметрами для файлов и файловых групп. Следует отметить следующее.

Чтобы изменить текущий размер файла в КБ, МБ, ГБ и ТБ, используйте параметр SIZE .
Чтобы изменить шаг приращения размера, используйте параметр FILEGROWTH . Значение 0 указывает, что автоматическое приращение выключено и дополнительное пространство для файла не разрешено.
Чтобы установить максимальный размер файла журнала в КБ, МБ, ГБ и ТБ или задать неограниченный размер (UNLIMITED), используйте параметр MAXSIZE .

Дополнительные сведения см. в разделе Рекомендации этой статьи.

3 ответа

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

Как и предполагалось, использование logrotate является обычным способом работы с лог-файлами. Но вместо добавления контента в /etc/logrotate.conf Вы должны добавить свою собственную работу в /etc/logrotate.d/ в противном случае вам придется смотреть больше различий в файлах конфигурации во время обновления релиза.

Вот пример, который я создал для сценария php:

Взгляните на man-страницу logrotate для получения дополнительных опций.

Если ваши журналы растут очень быстро, вы не можете дождаться, когда cron будет запускать logrotate один раз в день, как это делается по умолчанию после установки ограничения размера, как упоминалось в предыдущем ответе, вы можете сделать символическую ссылку в /etc/cron.hourly на logrotate задание cron в /etc/cron.daily с помощью этой команды:

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

Читайте также: