Вопрос: Заполнение корневой файловой системы, отсутствие больших файлов


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

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda3             184G  140G   35G  81% /

tmpfs                 2.3G     0  2.3G   0% /lib/init/rw

udev                  2.3G  212K  2.3G   1% /dev

tmpfs                 2.3G     0  2.3G   0% /dev/shm

/dev/sda1             4.6G  156M  4.2G   4% /boot

/dev/sda4              33G  176M   31G   1% /tmp

/dev/sdb1             1.8T  1.8T     0 100% /media/backupInterne

/dev/sdd1             917G  470G  401G  54% /media/Data

Я пришел сюда всего несколько дней назад и сразу заметил полный диск, и я работал над устранением этой проблемы. Моя другая проблема здесь - sda3 сейчас на 81%. 4 дня назад это было на 79%.

Я запустил du -ah | sort -rh в каталоге / root, ничего не выделяется. Сделал это с помощью нескольких дней, так как раздел sda3 быстро заполняется, и никаких существенных различий, которые могли бы объяснить, почему они растут.

большое спасибо


8
2017-12-06 16:40


Источник


Мое предположение - рост журнала, потому что sdb1 полон, но мы увидим, как большой /var есть .. что вы получаете от du -sh /*? - Shane Madden♦
Если вы хотите посмотреть, какие файлы были выполнены, вы можете использовать find с -mtime n [smhdw]. Я подозреваю, что Шейн прав. Частью этого могут быть файлы журналов, жалующиеся на полный том sdb1. Команда может выглядеть так: find / -type f -mtime 1d -print  Если ваша находка поддерживает --exclude-dir= то вы mioght хотите исключить / dev и / proc. - Hennes
/ var равен 1.7G, и размер его едва двигался за последние несколько дней, это была моя первая идея проверить это. Я всегда запускаю команду du с помощью --exclude = 'media', поскольку в этом каталоге нет ничего, кроме установленных каталогов - littleadmin
Поскольку вы написали, что являетесь новым администратором, я бы указал на одну из наиболее распространенных причин роста использования диска. Лог-файлы. Если вы откроете файл (например, журнал с веб-сервера), а затем удалите этот файл, тогда файл по-прежнему будет использовать дисковое пространство до тех пор, пока программа не закроет дескриптор этого файла. Это последнее иногда решается путем отправки регистрации (kill -1 PID -> переписать конфигурационный файл и перезапустить для многих деамонов) или тупой тоном перезагрузки. - Hennes
В случае, если это логарифмический рост, он может заселиться через несколько дней, когда еженедельный поворот журнала начнется. - ptman


Ответы:


Вот что я использую, пытаясь разобраться в таких проблемах.

du -s `ls -a | egrep -v '\.\.'` | sort -nr | head

Он покажет вам использование каждого каталога / файла в текущем каталоге. Оттуда вы переходите в поддиректории, пока не найдете что-то очевидное.

Наличие всего в одном большом разделе может затруднить диагностику таких проблем. Другой подход к использованию - использование

lsof 

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


6
2017-12-06 17:20



+1 для упоминания lsof. Этот инструмент будет полезен для нового администратора (даже если он может касаться и идти по этой проблеме). - Hennes
использование в каталоге / файлах дает мне 5 результатов, ни один из них более 600 тыс. - littleadmin


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

Если мы говорим о системе Linux, запустите:

lsof + L1

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


3
2017-12-06 19:04



К сожалению, не было никаких файлов, которые могли бы объяснить потерю пространства, которое происходит каждый день. благодаря - littleadmin
Возможно ли, что что-то пишет в каталог, который затем монтируется с файловой системой? Однажды у меня были гигабайты необъяснимых волос. Хотя это никогда не было возможным, я смог доказать, что это может произойти. - Eirik Toft
Я тоже думаю об этом, но как это могло произойти? И как я могу проверить это, не задумываясь обо всем? - littleadmin


Наконец я понял, что происходит. Одна из смонтированных точек не была правильно установлена, и поэтому она делала резервное копирование непосредственно на sda3.

Спасибо всем за помощь


2
2017-12-09 19:35