Как очистить логи Linux?

Если вы используете графическую среду, вы можете использовать что-то вроде Анализатор использования диска (он же Baobab) который может создать красивую кольцевую диаграмму, как показано ниже:

_{(источник: marzocca.net)}

Командная строка по-прежнему остается вашим лучшим оружием, но я считаю ее очень удобной. Есть несколько альтернатив Вот.

Что-то вроде этого должно помочь вам:

find / -type f -size +20000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }' 

Это ищет любой файл в / (root) размером примерно более 20 Мбайт. Возможно, вам придется отрегулировать переменные $ 9 / $ 5, но в большинстве случаев это не обязательно. Также рекомендую сменить / к /var/log/ если вы просто хотите заглянуть в папку журнала по умолчанию.

Хорошая идея - использовать logrotate (8) для сжатия и удаления старых файлов журналов, чтобы какой-нибудь болтливый демон не заполнил весь диск.

РЕДАКТИРОВАТЬ: Кроме того, большинство журналов будет находиться в / var / log. Простая команда ls -lh покажет, какие из них становятся слишком большими.

В du команда в командной строке сообщит вам, какие каталоги / папки занимают больше всего места. Отсюда вы можете сделать вывод, где находятся самые большие файлы.

$ du -h /

Параметр -h указывает du указать размеры в "понятном человеку" языке: kb, Mb, Gb и так далее.

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

Если вы делаете это как root, сообщений об ошибках не должно быть.

# du -h /

пропустите выход через sort -n так что последние строки показывают самые большие каталоги (или обратная сортировка и использование заголовка).

# du -h | sort -n 

Другой подход - использовать find с параметрами, которые определяют «найти файлы больше определенного размера», но этот метод требует некоторой практики, чтобы сделать это правильно.

# find / -size +10M

отобразит файлы размером более 10 МБ

Если у вас есть разделы разумного размера, вам следует искать большие файлы за пределами каталога журналов. Журналы вряд ли будут вашей проблемой, они редко достигают более 200 МБ в средней системе.

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

Вы должны сэкономить, если удалите файлы в / var / log / *, которые заархивированы (например, имеют окончание .gz). Опять же, я сомневаюсь, что это действительно решает вашу основную проблему (например, жесткий диск переполнен)

25 самых популярных каталогов и / или файлов:

du -m / | sort -rn | head -25

Итак, я обманул и посмотрел на DBA .... :)

https://dba.stackexchange.com/questions/41050/is-it-safe-to-delete-mysql-bin-files

(Два верхних ответа от RolandoMySQLDBA и Derek Downey актуальны и проницательны.)

К сожалению, здесь есть два типа «файлов журналов». Один из них - журналы транзакций, применяемые к вашим базам данных MySQL. Эти файлы можно использовать для синхронизации подчиненного устройства MySQL с главным устройством MySQL или восстановления базы данных. Как показано в верхнем ответе, ссылка на который приведена на странице выше, вы должны использовать только команды MySQL (или мета-инструменты, такие как Percona Toolkit), чтобы «очистить» эти журналы.

Другой файл, jaioyou-slow.log, скорее всего, является просто журналом медленных запросов, в котором регистрируются запросы, выполнение которых занимает больше установленного времени. Это файл журнала, наиболее похожий на типичный файл журнала * NIX, и поэтому при необходимости его можно обрезать (хотя, очевидно, вы потеряете статистику производительности, доступную в этом файле).

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

$ echo "" > /var/log/jaioyou-slow.log

Некоторые наблюдения:

• Ваша конфигурация mysql должна помещать журнал медленных запросов MySQL в более подходящее место журнала * NIX, например / var / log / mysql /, а не дерево / var / lib, чтобы избежать путаницы и, возможно, повысить производительность, если они каталоги находятся на отдельных дисках.
• Вам понадобится какая-то автоматизация для очистки двоичных журналов из MySQL (или сторонних инструментов). Я не рекомендую просто удалять их с помощью команд операционной системы.

Ссылки:

• http://dev.mysql.com/doc/refman/5.7/en/binary-log.html
• http://dev.mysql.com/doc/refman/5.7/en/purge-binary-logs.html