На днях у нас был заполнен общий ресурс сервера Samba (Ubuntu 8.04 LTR), но когда я зашел посмотреть, то не увидел, что на каких-либо ресурсах слишком много места.
у нас есть 5 групповых акций, а также у каждого пользователя есть индивидуальная акция
У одного пользователя 22 гигабайта данных, у нескольких других 10-20 мб данных, а у всех остальных пусто.
так что может быть около 26 гигабайт в общей сложности
Вчера я удалил несколько файлов и освободил около 250 МБ места, сегодня, когда я проверил его, он снова был полностью заполнен, и я удалил несколько старых файлов и освободил около 170 МБ, но я могу наблюдать, как свободное место медленно уменьшается.
Я продолжаю бегатьdf -h
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 241690180 229340500 169200 100% /
varrun 257632 260 257372 1% /var/run
varlock 257632 0 257632 0% /var/lock
udev 257632 72 257560 1% /dev
devshm 257632 52 257580 1% /dev/shm
lrm 257632 40000 217632 16% /lib/modules/2.6.24-28-generic
/летучий
что я могу сделать, чтобы попытаться выяснить, что занимает так много места на моем жестком диске? (я довольно новичок в Unix в целом, поэтому прошу прощения, если это не совсем понятно)
решение1
(Этот ответ ориентирован на Linux. Другие варианты UNIX могут отличаться.)
Для решения вашей проблемы важны два вида информации: (1) какие файлы заполняют вашу файловую систему и (2) какие процессы выполняют запись в эти файлы.
Примечания
Ниже, когда я вставляю $символ в команды, это, вероятно, заглушка, где нужно подставить реальное значение. Надеюсь, очевидно, где это делать, а где нет.
Какие файлы?
Имейте в виду, что в большинстве типов файловых систем есть два ресурса, которые могут быть использованы отдельными файлами: метаданные (например, иноды) и реальные данные. Вы можете увидеть количество инодов (поищите определение в 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заключается в том, что они дают вам только снимок системы на момент запуска команды. Если процесс-нарушитель не пишет, когда вы их запускаете, вам не повезло. Вы можете противостоять этому, многократно запуская их с течением времени и сохраняя вывод. Для этого потребуется прочитать вывод, чтобы найти закономерности, или написать программу, которая сделает это за вас. Альтернативой является использование инструмента вродеСистемаTap. SystemTap позволяет вам перехватывать все виды полезной информации и является "программируемым". Он даже поставляется с некоторыми примерами исходных файлов, которые позволят вам увидеть, какие процессы записывают в какие файлы в течение некоторого промежутка времени. Это было бы идеально, но это продвинутый инструмент и требует больших знаний Linux.
После того, как вы определили проблемный процесс(ы), вы можете завершить его (и, возможно, перезапустить). Если процесс связан с операционной системой или каким-то хорошо упакованным программным обеспечением, вероятно, будет механизм для его перезапуска, но это будет зависеть от вашего дистрибутива Linux (я думаю, Ubuntu позволит вам запустить что-то вроде /etc/init.d/$init_script restart, но вам придется проверить документацию вашего дистрибутива). В противном случае вы можете завершить его с помощью kill $pidили kill -9 $pid, если он ведет себя не так. Будьте внимательны и запишите, как работал процесс (например, какие аргументы показаны в ps -ef), на случай, если вам понадобится перезапустить его (вам может потребоваться обратиться к документации этого программного обеспечения).
решение2
Используйте duдля отслеживания каталога, содержащего файл(ы), заполняющие диск.
cd /
du -h --max-depth 1
покажет вам, какой каталог в / использует больше всего места. Пройдитесь по файловой системе, выполнив команду du, чтобы найти виновника.
например
cd /
du -h --max-depth 1
показывает, что /usr использует 2.3G из 3.5G, используемых в системе.
cd /usr
du -h --max-depth 1
показывает, что /usr/lib использует 1,1 ГБ из 2,3 в /usr ...
Это также может быть вызвано удалением открытого файла.
Вы можете использоватьlsofдля поиска файлов, которые открыты, но не связаны (удалены)
lsof +L1
Должно сработать. Как указано на странице руководства:
Спецификация формы
+L1выберет открытые файлы, которые были отвязаны. Спецификация формы+L1 <file_system>выберет отвязанные открытые файлы в указанной файловой системе.
решение3
Что-то заполняет раздел /. Вероятно, это что-то в /var/log, или в /home. Это зависит от вашей настройки. Также посмотрите в местах, к которым ваши пользователи имеют доступ.
Выполните следующую команду в каждом из интересующих вас каталогов. Это покажет вам подкаталоги, которые являются крупнейшими потребителями пространства.
cd /directory
du -cks -x * .* |sort -n
Эта идея заимствована из ducksсценария ( du -cks) изВзлом Linux-сервераот O'Reilly. Я часто запускаю эту команду.
По моему опыту, это почти всегда связано с большими, растущими файлами журнала. В этом случае используйтеЛогротат, иобязательно используйте сжатие. Используя сжатие gzip с коэффициентом сжатия по умолчанию, ваши файлы журналов будут уменьшены на 80-95% (1 ГБ /var/log/messages можно легко сжать до 200 МБ или меньше). Это создает умеренную нагрузку на ЦП, но я редко видел, как это влияет на реальную производительность сервера. Некоторые люди предпочитают использовать сжатие Bzip2 или использовать , gzip --bestно по моему опыту это вызывает большую нагрузку на ЦП с небольшим дополнительным преимуществом. gzipс коэффициентом по умолчанию обычно достаточно.
И очевидно, что эта проблема иногда возникает из-за того, что пользователь делает плохие вещи. Используйте duкоманду выше, чтобы найти виновника.
решение4
Вероятным виновником являются журналы, но вот команда, которая отсортирует недавно измененные (или созданные) файлы по размеру:
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, чтобы отсортировать эти файлы по ежедневному росту.
(редактировать) Для мониторинга роста используйтегт5
sudo aptitude install gt5
cd /
gt5
Через день ищите знаки ±
gt5