Диск полон, дю рассказывает другое. Как продолжить расследование?

110

У меня есть SCSI диск на сервере (аппаратный Raid 1), 32G, ext3 файловый элемент. dfговорит мне, что диск заполнен на 100%. Если я удаляю 1G, это правильно показано.

Однако, если я запускаю a, du -h -x /то duговорит мне, что используются только 12G (я использую -xиз-за некоторых монтировок Samba).

Так что мой вопрос не о тонких различиях между командами du и df, а о том, как я могу выяснить, что вызывает эту огромную разницу?

Я перезагрузил машину для fsck, который прошел без ошибок. Должен ли я бежать badblocks? lsofпоказывает, что нет открытых удаленных файлов, lost+foundпусто, и в файле сообщений нет явного оператора warn / err / fail.

Не стесняйтесь спрашивать более подробную информацию о настройке.

initall
источник
3
Это очень близко к вопросу: разница между linux - du и df ( serverfault.com/questions/57098/du-vs-df-difference ). Решением были файлы в точке монтирования, как ответил OldTroll.
Крис Тинг

Ответы:

93

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

OldTroll
источник
3
Вы можете найти эти скрытые файлы без необходимости размонтировать каталоги. Посмотрите на ответ Марселя Дж ниже, который объясняет как.
Мхсехават
Вы должны показать команды CLI, чтобы сделать это в своем ответе
Jonathan
1
ПРОВЕРИТЬ, даже если вы думаете, что это не имеет смысла для вас!
Крис
1
Примечание. В этом ответе речь идет о файлах, расположенных под точками монтирования (то есть скрытыми в исходной файловой системе), а не в точках монтирования. (Не будь таким идиотом, как я.)
mwfearnley
92

Просто наткнулся на эту страницу при попытке отследить проблему на локальном сервере.

В моем случае df -hи не du -shсоответствует примерно 50% размера жесткого диска.

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

Это выследили, запустив lsof | grep "/var" | grep deletedгде /varбыл раздел мне нужно очистить.

Выходные данные показывали такие строки:
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

Ситуация была разрешена путем перезапуска apache ( service httpd restart) и очистки 2 ГБ дискового пространства, позволяя очистить блокировки удаленных файлов.

KHobbits
источник
Для меня блокировки там не снимаются даже после того, как я остановил программу (зомби?). Мне пришлось kill -9 'pid'освободить замки. Например: для вашего httpd это было бы kill -9 32617.
Мика
6
Небольшое примечание: возможно, вам придется работать, lsofкак sudoили не все открытые дескрипторы файлов будут отображаться
ChrisWue
Я столкнулся с этим с H2, который добавлял несколько концертов в файл журнала каждый день. Вместо перезапуска H2 (медленно) я использовал sudo truncate -s0 /proc/(h2 PID)/(descriptor number obtained from ls /proc/h2pid/fd).
Дести
В моем случае даже при перезагрузке httpdпространство не освобождается. Когда я побежал, /etc/init.d/rsyslog restartэто сработало: D
Тхань Нгуен Ван
2
Вы можете пропустить greps и просто сделать lsof -a +L1 /var, где -aозначает И все условия (по умолчанию ИЛИ), +L1означает, что список только файлы с количеством ссылок меньше 1 (то есть, удаленные файлы с открытыми файловыми дескрипторами), и /varограничивает файлы в этой точке монтирования
Кболино
51

Я согласен с ответом OldTroll как наиболее вероятной причиной вашего "пропущенного" места.

В Linux вы можете легко перемонтировать весь корневой раздел (или любой другой раздел) в другое место в вашей файловой системе, например, / mnt, просто выполните команду

mount -o bind / /mnt

тогда вы можете сделать

du -h /mnt

и посмотрите, что занимает ваше пространство.

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

Марсель Дж
источник
3
Большое спасибо за этот совет. Позволил мне находить и удалять мои большие «скрытые» файлы без простоев!
Чов
Спасибо - это показало, что докер заполнял мой жесткий диск /var/lib/docker/aufs/diff/
ссылками
25

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

eirescot
источник
1
Размер файла и объем пространства, которое он занимает в файловой системе, - это две разные вещи. Чем меньше размер файлов, тем больше расхождение между ними. Если вы напишите скрипт, который суммирует размеры файлов и сравнивает его с du -sодним и тем же поддеревом, вы получите хорошую идею, если это так.
Марцин
24

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

Наконец, я решил проблему с помощью программы lsof | grep deleted, которая показала мне, в какой программе хранятся два очень больших файла журнала (всего 5 ГБ моего доступного корневого раздела 8 ГБ).

Адриан
источник
1
Этот ответ заставляет меня задуматься, почему вы храните файлы журналов в корневом разделе, особенно в небольшом ... но, наверное, для каждого из них ...
CVn
У меня была похожая проблема, я перезапустил все приложения, которые использовали удаленный файл, я думаю, что процесс зомби все еще держался за большой удаленный файл
user1965449
Это было для нас, приложение linux для обработки журналов, известное как filebeat, оставляющее файлы открытыми.
Пиклер
@Pykler Для нас это тоже был битник. Спасибо за чаевые!
Мартейн Химельс
7

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

Пол Томблин
источник
ОП сказал, что перезагрузил систему, и проблема осталась.
OldTroll
У меня были зомби, которые не снимали блокировки файлов, я kill -9 'pid'их снимала блокировки и возвращала место на диске.
Мика
5

Попробуйте это, чтобы увидеть, заблокирован ли мертвый / зависший процесс во время записи на диск: lsof | grep "/ mnt"

Затем попробуйте убить все застрявшие PID (особенно ищите строки, оканчивающиеся на "(удалено"))

Phirsk
источник
Спасибо! Мне удалось обнаружить, что процесс SFTP-сервера удерживал удаленный файл
lyomi
4

Это самый простой метод, который я нашел на сегодняшний день, чтобы найти большие файлы!

Вот пример, если ваше корневое монтирование заполнено / (mount / root) Пример:

CD / (так что вы в корне)

ls | xargs du -hs

Пример вывода:

 9,4 М бен
 63M boot
 4.0K cgroup
 680 тыс. Устройств
 31 м и т. Д.
 6.3G домой
 313M lib
 32M lib64
 16K потеряно + найдено
 61G медиа
 4,0 тыс. Т
 113M опт
 du: не может получить доступ к `proc / 6102 / task / 6102 / fd / 4 ': такого файла или каталога нет
 0 проц
 19M корень
 Пробег 840К
 19М сбин
 4.0K selinux
 4.0K срв
 25G магазин
 26 миллионов тонн

тогда вы заметите, что магазин большой, сделайте CD / магазин

и беги снова

ls | xargs du -hs

Пример вывода: 
 Резервное копирование 109M
 358 млн фнб
 4.0G iso
 8.0 Кс
 16K потеряно + найдено
 47M корень
 11M скриптов
 79 млн тонн
 21G VMS

в этом случае директория vms является пробелом.

Riaan
источник
1
Почему бы не использовать более простые инструменты, как baobab? (см. marzocca.net/linux/baobab/baobab-getting-started.html )
Иван
2
Hm ls+ xargsкажется излишним, du -sh /*само по себе прекрасно работает
ChrisWue
1
если вы не знаете о ncdu ... вы поблагодарите меня позже: dev.yorhel.nl/ncdu
Трой Фолгер
3

Для меня мне нужно было запустить, так sudo duкак было много файлов докеров, под /var/lib/dockerкоторыми пользователь не-sudo не имеет разрешения на чтение.

jobevers
источник
Это была моя проблема. Я забыл, что переключил системы хранения в докере, а старые тома все еще зависали.
Ричард Нинабер
1

Еще одна возможность для рассмотрения - вы почти гарантированно увидите большое расхождение, если вы используете docker, и вы запускаете df / du внутри контейнера, который использует том-монтирования. В случае каталога, подключенного к тому на хосте докера, df сообщит итоги df HOST. Это очевидно, если вы подумаете об этом, но когда вы получите отчет о «убегающем контейнере, заполняющем диск!», Убедитесь, что вы проверили потребление файлового пространства контейнера чем-то вроде du -hs <dir>.

Трой Фолджер
источник
1

Так что у меня была эта проблема и в Centos 7, и я нашел решение после того, как попробовал кучу таких вещей, как bleachbit и cleaning / usr и / var, хотя они показывали только около 7G каждый. По-прежнему показывал 50G из 50G, используемых в корневом разделе, но показывал только 9G использования файла. Запустил работающий Ubuntu CD и размонтировал поврежденный раздел 50G, открыл терминал и запустил xfs_check и xfs_repair на этом разделе. Затем я перемонтировал раздел, и мой каталог lost + found расширился до 40G. Сортировал потерянный + найденный по размеру и нашел 38G текстовый лог-файл для steam, который в итоге просто повторил ошибку mp3. Удалил большой файл, теперь у него есть место, и использование моих дисков соответствует размеру моего корневого раздела. Я все еще хотел бы знать, как заставить паровой журнал не расти снова таким большим.

Джастин Чедвик
источник
Это случилось с вами на работе? serverfault.com/help/on-topic
птенцы
Нет только на моем домашнем компьютере.
Джастин Чедвик,
3
xfs_fsrисправил эту проблему для нас
Друска
0

если подключенный диск является общей папкой на компьютере с Windows, то кажется, что df покажет размер и использование диска всего диска Windows, но du покажет только ту часть диска, к которой у вас есть доступ. (и смонтирован). поэтому в этом случае проблема должна быть исправлена ​​на машине с Windows.

Сверре
источник
0

Аналогичная вещь произошла с нами на производстве, использование диска возросло до 98%. Провел следующее расследование:

а) df -iдля проверки использования инода, использование инода составило 6%, поэтому файлы не намного меньше

б) Монтирование rootи проверка скрытых файлов. Не удалось подать дополнительные файлы. duрезультаты были такими же, как и до монтирования.

в) Наконец, проверил nginxлоги. Он был настроен на запись на диск, но разработчик удалил файл журнала напрямую, в результате чего nginxвсе журналы были сохранены в памяти. Поскольку файл /var/log/nginx/access.logбыл удален с диска с помощью, rmон не был виден с помощью, duно доступ к файлу осуществлялся nginxи, следовательно, он все еще оставался открытым

darxtrix
источник
0

У меня была та же проблема, которая упоминается в этой теме, но в одном VPS. Поэтому я проверил все, что описано в этой теме, но безуспешно. Решением стало обращение в службу поддержки нашего провайдера VPS, который выполнил пересчет квот и исправил разницу в размерах df -hи du-sh /.

ldxd
источник
0

Я столкнулся с этой проблемой сегодня на коробке FreeBSD. Проблема заключалась в том, что это был артефакт vi(нет vim, не уверен, vimчто создаст эту проблему). Файл занимал место, но не был полностью записан на диск.

Вы можете проверить это с помощью:

$ fstat -f /path/to/mount/point |sort -nk8 |tail

Он просматривает все открытые файлы и сортирует (численно через -n) по 8-му столбцу (ключ, -k8), показывая последние десять элементов.

В моем случае последняя (самая большая) запись выглядела так:

bob      vi         12345    4 /var      97267 -rwx------  1569454080 rw

Это означало, что процесс (PID) 12345 потреблял 1,46 ГБ (восьмой столбец, разделенный на 1024 ³) диска, несмотря на его отсутствие du. viужасно при просмотре очень больших файлов; даже 100 МБ это большое для него. 1,5 ГБ (или как бы велик этот файл на самом деле) нелепо.

Решение было в sudo kill -HUP 12345том, что (если это не сработает, я буду, sudo kill 12345и если это тоже не kill -9получится , то страшные войдут в игру).

Избегайте текстовых редакторов на больших файлах. Примеры обходных путей для быстрого скимминга:

Предполагая разумную длину строки:

  • { head -n1000 big.log; tail -n1000 big.log } |vim -R -
  • wc -l big.log |awk -v n=2000 'NR==FNR{L=$1;next}FNR%int(L/n)==1' - big.log |vim -R -

Предполагая неоправданно большие строки:

  • { head -c8000 big.log; tail -c8000 big.log } |vim -R -

Они используют vim -Rвместо, viewпотому что vimпочти всегда лучше ... когда он установлен. Не стесняйтесь трубить их viewили vi -Rвместо.

Если вы открываете такой большой файл на самом деле изменить его, рассмотреть sedили awkили какой -либо другой программный подход.

Адам Кац
источник
0

проверьте, установлен ли на вашем сервере агент ossec. Или какой-то процесс использует удаленные файлы журнала. По моему некоторое время назад был агентом осек.

Ричард Мерида
источник
1
ОП упомянул, что машина была перезагружена, поэтому не должно быть удаленных файлов.
Ральф Фридл
-3

проверьте / lost + found, у меня была система (centos 7) и часть файла в / lost + found исчерпала все пространство.

Джуд Чжу
источник
Как бы это объясняло разницу в использовании дискового пространства, как описано в вопросе ?
Ройма