Comments 47
UFO just landed and posted this here
Это логи за день так разрастались или не было logrotate?
UFO just landed and posted this here
А нефиг логи хранить на том же сервере, где приложение есть. syslog, udp, лог-сервер.
UFO just landed and posted this here
Даже в пределах localhost, использование syslog'а предпочтительно. У journald есть все настройки для того, чтобы логи не сожрали всё место. А вот самодеятельных хаккеров, которые сами себе на уме, где лог файлы создавать и в каком формате писать, надо бить по рукам.
UFO just landed and posted this here
Если деплой в руках админов — запрет на запись куда-либо. Если деплой в руках девелоперов — ну, так сказать, спасение утопающих дело фабрики классов абстрактных трейтов спасения утопающих.
UFO just landed and posted this here
Можно небольшую статью на эту тему?
У journald есть все настройки для того, чтобы логи не сожрали всё место.Да они и без настроек не сожрут.
Была полностью идентичная ситуация. Я просто тогда логирование полностью отключил для этого сайта.
Полезная статья. К слову, нечто «крадет» место на диске и на Windows тоже. У меня в системной папке регулярно собирается пара десятков гигабайт логов, которые приходится удалять по расписанию…
Таки вы не поверите, но есть gnuwin32. Там есть и du и df.
я таки предпочитаю cygwin. Вообще диски сканирую WinDirStat, который, собственно, и выявил их наличие. Теперь остается только устранить причину их возникновения.
Пару раз выхватывал ситуацию, когда на win-машине стремительно пропадает место. Scaner проблему не нашел. Показывал свободное место на винтах.
только перезагрузка помогла :(
только перезагрузка помогла :(
du/df конечно замечательно, но вот для разбирания завалов на рабочей машинке не самое приятное решение. Есть какие-то утилиты, работающие в графическом режиме и позволяющие более наглядно и удобно все это проделывать?
Для Windows есть чудесная утилита SpaceSniffer.
А для линуксов?
К сожалению, не знаю альтернатив. Надеюсь, что кто-то подскажет.
ncdu
Ну во-первых, таки ncdu
Baobab, kdirstat (хотя теперь это k4dirstat), filelight. Тысячи их.
Baobab, kdirstat (хотя теперь это k4dirstat), filelight. Тысячи их.
Помимо ncdu, есть ещё замечательная gt5, которая делает или интерпретирует существующий du и показывает результат в виде дерева через браузер (обычно консольный)
В Ubuntu вроде даже по умолчанию Baobab установлен 
Первый выбор — это уже упомянутый ncdu.
Потом если хочется графики можно посмотреть ohmu:
скрин
Потом если хочется графики можно посмотреть ohmu:
гиф скринкаст
Krusader
Tools->Disk Usage
Tools->Disk Usage
SequoiaView под windows и gdmap под линукс использовал:
Скриншоты
Я тоже, но потом перешел на WinDirStat, т.к. SequoiaView некорректно отрабатывает ссылки и соединения NTFS. Для меня это важно, т.к. я предпочитаю хранить бэкапы iTunes не на системном относительно небольшом SSD, а на HDD.
Аналог для Linux — KDirStat.
Аналог для Linux — KDirStat.
Ещё под Windows есть удобная мелкая утилита SequoiaView. Занятое место показывает цветными прямоугольниками, соответственно занимаемому размеру, наглядно.
Двум из самых базовых команд посвящена большая статья? Надеялся хоть что-то новое расскажете, лайфхаки какие-нибудь.
Например, логи можно не чистить а gzip'ать — в ключе последних законов они вам могут понадобиться.
Насчет «частых мест» — еще стоит глянуть на кэш пакетного менеджера — он тоже бывает хорош.
Например, логи можно не чистить а gzip'ать — в ключе последних законов они вам могут понадобиться.
Насчет «частых мест» — еще стоит глянуть на кэш пакетного менеджера — он тоже бывает хорош.
Ситуация будет гораздо интереснее, когда закончится не место, а inode. Тут придется искать каталоги с наибольшим количеством файлов. В обычных случаях спасет:
В совсем плохих случаях, приходилось запускать du и смотреть на каких каталогах он виснет. После смело проверять размер дескриптора директории:
С таким размером директории бесполезно делать ls внутри нее. Дальнейшие действия вас приведут к посту seriyPS
find /var/www -type d | ( while read A; do B=`ls -l "$A" | wc -l`; if [ "$B" -gt 999 ] ; then echo $B $A; fi ; done)
В совсем плохих случаях, приходилось запускать du и смотреть на каких каталогах он виснет. После смело проверять размер дескриптора директории:
# ls /var/www/test/data/
drwxrwxrwx 2 test test 124M Nov 19 18:05 bin-tmp
С таким размером директории бесполезно делать ls внутри нее. Дальнейшие действия вас приведут к посту seriyPS
Ещё весело бывает в тех случаях, когда logrotate настроен, но неправильно (приложение не переоткрывает лог, в результате чего продолжает писать в открытый дескриптор при уже удалённом файле). df в таком случае показывает, что места нет, а du по директории — что всё замечательно.
Решается достаточно просто с помощью lsof.
Это покажет все открытые файлы в директории dir и поддиректориях (+d, если не нужно спускаться по дереву).
Около открытых, но удалённых файлов будет стоять (deleted). Далее смотрим PID и говорим процессу переоткрыть лог (ну или просто перезапускаем процесс, если можно).
Решается достаточно просто с помощью lsof.
lsof +D dir
Это покажет все открытые файлы в директории dir и поддиректориях (+d, если не нужно спускаться по дереву).
Около открытых, но удалённых файлов будет стоять (deleted). Далее смотрим PID и говорим процессу переоткрыть лог (ну или просто перезапускаем процесс, если можно).
lsof | grep deleted
deleted. Буду обновлять комментарии.
А кто знает, в чем может быть причина такого глюка?
Вкратце: на ext3 образовалась директория с необычно большим размером (не содержимого всего дерева файлов, а именно директории как файла).
В результате чтение (например, командой ls) занимает несколько десятков секунд.
Вкратце: на ext3 образовалась директория с необычно большим размером (не содержимого всего дерева файлов, а именно директории как файла).
# stat /home/art/
File: `/home/art/'
Size: 28336128 Blocks: 55408 IO Block: 4096 directory
В результате чтение (например, командой ls) занимает несколько десятков секунд.
У du есть еще полезный параметр --max-depth=1, которым можно указать количество уровней вложенности поддиректорий. Удобно сначала найти в корне проблемную папку и уже потом её разбирать.
Ничего не сказано об открытых файловых дескрипторах, которые жрут место даже после удаления большого файла (характерно только для Unix). Так будет до закрытия дескриптора или завершения процесса, который открыл дескриптор.
Ожидал прочитать детектив, прочитал man.
Ожидал прочитать детектив, прочитал man.
Sign up to leave a comment.
Нечто «крадет» место на диске?