Сервер Ubuntu медленно заполняется

Использовать du чтобы отследить каталог, содержащий файл (ы), заполняющие диск.

cd /
du -h --max-depth 1

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

например

cd /
du -h --max-depth 1

показывает, что / usr использует 2,3 ГБ из 3,5 ГБ, используемых в системе.

cd /usr
du -h --max-depth 1

показывает, что / usr / lib использует 1,1 ГБ из 2,3 в / usr ...

Это также может быть вызвано удалением открытого файла.

Ты можешь использовать lsof найти файлы, которые открыты, но не связаны (удалены)

lsof +L1

должен сделать свое дело. Как указано на странице руководства:

Спецификация формы +L1 выберет открытые файлы, которые не были связаны. Спецификация формы +L1 <file_system> выберет несвязанные открытые файлы в указанной файловой системе.

(Это ответ, ориентированный на Linux. Другие варианты UNIX могут отличаться.)

Есть две части информации, относящиеся к вашей проблеме: (1) какие файлы заполняют вашу файловую систему и (2) какие процессы записывают в эти файлы.

Ноты

Ниже, когда я поставил $ символ в командах, вероятно, это место, где вам нужно подставить реальное значение. Надеюсь, очевидно, где это делать, а где нет.

Какие файлы?

Имейте в виду, что в большинстве типов файловых систем есть два ресурса, которые могут использоваться отдельными файлами: метаданные (например, inodes) и реальные данные. Вы можете увидеть количество inodes (поищите в Google определение, но они «указатели» на структуры, из которых состоят ваши файлы) с помощью такой команды:

df -i

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

df -h

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

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

sudo find $file_system -mount -ls | awk '{print $7, $11}' | sort -rn > $output

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

sudo find . -mount -print0 | xargs -0n 1 dirname | sort | uniq -c | sort -rn > $output

... имейте в виду, что выполнение этих команд может занять некоторое время и, в зависимости от этого, выполнять много операций ввода-вывода. После запуска вы можете прочитать $output чтобы найти файлы или каталоги, вызывающие нарушение. Имя и расположение каждого из них могут дать вам представление о том, откуда берутся данные, но для этого требуется некоторый опыт работы с Linux.

После того, как вы определили преступников, вы можете rm $file чтобы избавиться от проблемы.

Какие процессы?

Самый простой способ найти процессы, потенциально заполняющие вашу файловую систему, - это запустить такую ​​команду, как:

fuser -c $file_system 2>/dev/null

... который сообщит вам PID процессов, имеющих открытые файловые дескрипторы (файлы и сетевые сокеты) для данной файловой системы ( 2>/dev/null часть избавляется от некоторой информации, которая вам не нужна). Возможно, вы сможете определить только по этим идентификаторам PID, какой процесс заполняет вашу файловую систему. Найдите процессы с:

ps -ef | grep $pid

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

sudo lsof $file_system | grep $directory_filling_up

... и если вы определили подозрительный PID из fuser команду, вы можете сделать это:

sudo lsof -p $pid

Проблема с fuser и lsof заключается в том, что они дают вам только моментальный снимок системы во время выполнения команды. Если оскорбительный процесс не пишет, когда вы их запускаете, вам не повезло. Вы можете противостоять этому, многократно запуская их с течением времени и сохраняя вывод. Это потребует чтения вывода, чтобы найти шаблоны, или написания программы, которая сделает это за вас. Альтернативой является использование такого инструмента, как SystemTap. SystemTap позволяет захватывать все виды полезной информации и является «программируемым». Он даже поставляется с некоторыми примерами исходных файлов, которые позволят вам увидеть, какие процессы какие файлы записывают в течение некоторого промежутка времени. Это было бы идеально, но это продвинутый инструмент, требующий больших знаний Linux.

Как только вы определили нарушающий процесс (-ы), вы можете убить (и, возможно, перезапустить их). Если процесс связан с операционной системой или каким-либо хорошо упакованным программным обеспечением, вероятно, будет механизм для их перезапуска, но это будет зависеть от вашего дистрибутива Linux (я думаю, Ubuntu позволит вам запускать что-то вроде /etc/init.d/$init_script restart, но вам нужно будет проверить документацию вашего дистрибутива). В противном случае вы можете убить его kill $pid или kill -9 $pid если он не ведет себя. Обратите внимание на то, как выполнялся процесс (например, какие аргументы были показаны в ps -ef) на случай, если вам потребуется перезапустить его (возможно, вам потребуется обратиться к документации этого программного обеспечения).

Что-то заполняет раздел /. Это наверное что-то в /var/log , или в /home . Это зависит от ваших настроек. Также посмотрите места, к которым у ваших пользователей есть доступ.

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

cd /directory
du -cks -x * .* |sort -n

Эта идея заимствована из ducks сценарий (du -cks) из Взлом серверов Linux от О'Рейли. Я часто запускаю эту команду.

По моему опыту, это почти всегда из-за больших, растущих файлов журналов. В этом случае используйте Logrotate, и обязательно используйте сжатие. Используя сжатие gzip с коэффициентом сжатия по умолчанию, ваши файлы журналов будут уменьшены на 80-95% (1 ГБ / var / log / messages можно легко сжать до 200 МБ или меньше). Это создает умеренную нагрузку на ЦП, но я редко видел, чтобы это влияло на реальную производительность сервера. Некоторые люди предпочитают использовать сжатие Bzip2 или использовать gzip --best но, по моему опыту, это вызывает много накладных расходов процессора с небольшим дополнительным преимуществом. gzip с коэффициентом по умолчанию обычно достаточно хорошо.

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

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

Вероятно, виноваты журналы, но вот команда, которая сортирует недавно измененные (или созданные) файлы по размеру:

D=$(date --rfc-3339 date);
sudo sh -c 'find / -xdev -mtime -1 -type f -print0 |xargs -0 du -0sbc' \
  |tee ~/recent-files.$D |sort -zn |tee ~/recent-by-size.$D |xargs -0n1

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

(править) Чтобы отслеживать рост, используйте gt5

sudo aptitude install gt5
cd /
gt5

Один день спустя; ищите знаки ±

gt5

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

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

Оказывается, виновником был скрытый .recycler папка в каждом общем директоре, который был скрыт.

Если вы сделаете ls -a вы можете их увидеть.