Результат команды df:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 864000688 809338092 10773908 99% /
tmpfs 32965940 0 32965940 0% /dev/shm
/dev/sda1 198337 87394 100703 47% /boot
Результат команды df через несколько секунд:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 864000688 809400076 10711924 99% /
tmpfs 32965940 0 32965940 0% /dev/shm
/dev/sda1 198337 87394 100703 47% /boot
Я теряю дисковое пространство на своем сервере с невероятной скоростью. И каждый раз, когда доступное пространство достигает 0 октетов, происходит сбой службы Mysql.
у меня уже есть reboot сервер, чтобы очистить dmesg logs, я удалил все большие файлы журналов (журналы ошибок, журналы сообщений и журналы named.run) и запустил этот запрос: sudo /usr/sbin/lsof | grep deleted.
Однако освободившееся пространство было съедено днем.
Итак, я выполнял такие запросы, как:
du -hsx * | sort -rh | head -15
и это :
find . -type d -print0 | xargs -0 du | sort -n | tail -10 | cut -f2 | xargs -I{} du -sh {
Во всех каталогах из моего корневого каталога.
Но самый большой файл, который я смог найти, - это дамп из моей базы данных, и это файл размером всего 1 ГБ:
-rw-r--r-- 1 root root 1032237681 6 déc. 2013 dump_experta2.sql
-rw-r--r-- 1 root root 389789251 6 déc. 2013 dump_experta.sql
Можете ли вы объяснить мне, почему доступное пространство, кажется, используется некоторыми невидимыми файлами? И как я могу локализовать и остановить утечку дискового пространства?
Редактировать : Благодаря советам HBruijn я решил свою проблему, вот что я сделал шаг за шагом, если вы столкнулись с той же проблемой:
Я побежал find / -mindepth 1 -maxdepth 1 -print0 |xargs -0 du -s
И получил такой результат:
1216308 /usr
23356 /lib64
73176 /root
440 /tmp
4 /selinux
4 /command
5574820 /var
4 /media
16 /lost+found
352388 /lib
8 /opt
0 /.autorelabel
4 /service
0 /sys
36500 /www
0 /proc
81785 /boot
7760 /bin
160 /dev
742949400 /home
14572 /sbin
0 /currentsize
0 /.autofsck
2092 /package
4 /srv
4 /mnt
27676 /etc
72944 /test
Кажется, что домашний каталог самый большой, поэтому я повторил процесс, чтобы найти самый большой каталог внутри дома:
# find /home -mindepth 1 -maxdepth 1 -print0 |xargs -0 du -s
133952 /home/advisio
16 /home/dovecot
2210824 /home/vpopmail
186500 /home/admin
37152 /home/ginger
511121816 /home/user1
229278612 /home/user2
И я повторил процесс и увидел, что данные user1 выросли, поэтому я продолжил поиск в каталоге user1 и нашел эти два тяжелых каталога:
281766156 /home/user1/www/log
207269420 /home/user1/www/fichiers
Размер каталога "fichiers" не является необычным, поскольку он используется для хранения бесчисленных файлов pdf и изображений. Я посмотрел на папку журнала и нашел следующее:
# ls -l
-rwxrwxrwx 1 vroom users 288586156425 2 juil. 15:34 log-sql-error.txt
Я понял, что то, что вы сказали о моем методе поиска, было невероятно правильным. Мне удается пропустить файл журнала размером 288 ГБ из-за поиска журналов в неправильных каталогах.
В любом случае я остановил httpd и mysqld services, очистил журнал ошибок, и вот теперь мой df:
Filesystem 1G-blocks Used Available Use% Mounted on
/dev/sda2 824G 505G 278G 65% /
tmpfs 32G 0G 32G 0% /dev/shm
/dev/sda1 1G 1G 1G 47% /boot
А пока я воспользуюсь вашими советами, когда буду искать тяжелые файлы и папки. Спасибо!
Первое: последовательность find . -type d -print0 | xargs -0 du | sort -n невероятно рекурсивен и неэффективен.
Нахождение самые большие файлы, с участием find / -type f -print0 | xargs -0 du | sort -n уже намного лучше с find / -type f -printf "%s %p\n" |sort -n еще эффективнее.
Часто более показательным является где вы теряете место на диске и обнаруживаете крупнейшие каталоги быстро (du-s) вместо этого, потому что много маленьких файлов также складываются (например, очередь почты, очередь печати и т. д.)
Во-вторых: когда ты бежал find "во всех каталогах из моего корневого каталога" возможно, вы пропустили «скрытые» файлы / каталоги в корневом каталоге / т.е. простые, начинающиеся с точки /.<name> и менее очевидные, например, состоящие только из пробела / / или символ TAB.
Начать с:
find / -mindepth 1 -maxdepth 1 -print0 |xargs -0 du -s
и пройдите свой путь вниз от этого.
Вы уже просмотрели удаленные файлы, которые могут оставаться открытыми с помощью lsof но у вас могут быть процессы, записывающие большие (временные) файлы, и было бы интересно и полезно посмотреть sudo lsof -s | awk '$5 == "REG"' | sort -n -r -k 7,7 | head -n 50
В будущем используйте такой инструмент, как ncdu для отображения использования вашей файловой системы. Вы бы очень легко обнаружили проблему с файлом журнала.