Linux 100 disk usage

(Note: I use hibernation. After the hibernation, the usage stays the same, and after reboot, it resets to 80%.) How do I track what eats the space? I've read this question. I'm still in the dark. How do I find out which program is responsible for this behavior? After edit: found it. The space is claimed by the kernel log, which is seen by dmesg . It fills up because my machine generates errors at the rate 5 a second. (It's related to this bug.) Let the future readers with a similar problem - slowly-filling disk space unseen by du - not forget to try dmesg in searching for the cause.

Источник

Диск занят на 100% и не понятно чем, df и du показывают разные значения

Столкнулся сегодня с нестандартной ситуацией, когда на сервере исчезало место на диске, а я не мог понять кто его занимает. Хотя ситуация не такая уж нестандартная, но из-за ряда случайностей, она получилась в какой-то мере курьезной. Я по сути на ерундовую ошибку потратил много времени.

Если у вас есть желание научиться администрировать системы на базе Linux, рекомендую познакомиться с онлайн-курсом «Linux для начинающих» в OTUS. Курс для новичков, для тех, кто с Linux не знаком. Подробная информация.

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

В данном случае сервер это виртуальная машина, у нее один диск и один корневой раздел, на котором все расположено. На диске ext4 поверх lvm. Задача увеличить свободное место в корневом разделе без перезагрузки сервера. С lvm все очень просто. Добавляем к виртуальной машине диск нужного размера и выполняем в консоли:

# vgextend vg00 /dev/sdb # lvextend -r -l +100%FREE /dev/vg00/root

Иногда конструкция -l +100%FREE не срабатывает при увеличении раздела, хотя при создании все в порядке. Тогда можно указать добавляемый размер явно:

# lvextend -r -L+10G /dev/vg00/root

В моем примере есть системный диск sda, на котором расположен том vg00, а на нем логический раздел root. Мы расширяем том vg00 с помощью нового диска sdb, а затем расширяем логический раздел root до 100% свободного места тома.

После этого системный раздел будет увеличен сразу, перезагрузка не требуется. Можно не добавлять отдельный диск, а увеличить существующий через свойства диска в панели гипервизора. Тогда вам нужно будет на новом свободном месте на диске sda сделать новый раздел, например, sda2 и расширить том с его помощью. Как делать лучше, увеличивать диск или добавлять новый - не знаю, я и так, и так делаю. Тем не менее, считаю это плохой практикой, лучше сразу спланировать раздел диска и потом уже его не трогать. Данный способ это крайний случай, когда по-другому уже никак.

Проблема вроде как решена. Через пару дней ко мне обращается этот же разработчик и говорит, что места опять нет и он не понимает, кто его занимает. Тут я уже внимательно посмотрел на сервер. Посмотрел размер всех папок с помощью нехитрой конструкции, запущенной в консоли с корня диска:

# du -s *|sort -nr|cut -f 2-|while read a;do du -hs $a;done

Получим сразу в консоли размер всех директорий. У меня получилось так, что если сложить объем всех директорий, то получится занятыми где-то 6 Гб диска. А если выполнить команду

То видно, что корень занят на 100%, а его размер равен 20-ти Гб. Кто занял остальные 14 гигабайт места было не понятно.

Стал рассуждать, как такое может быть. Ситуация не такая уж и редкая, раньше встречался с этим. Суть в том, что удален какой-то большой файл, который до сих пор открыт приложением. Но смысл в том, что на этом сервере такого файла никогда не было. Разработчик сказал, что ничего особенного последнее время на сервере не делал.

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

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

Предпоследний столбец это размер файла. На самом деле, эту команду я сразу же выполнил на сервере, но невнимательно посмотрел. В выводе команды была всякая мелочь и пару логов nginx в самом начале. Я не посмотрел внимательно на размер этих логов, так как никак не думал, что они могут быть огромными.

А причина проблем со свободным место была вот в чем. Пару недель назад разработчик зашел на сервер и просто удалил лог ошибок nginx. И не перезапустил его. Он где-то неделю так проработал, а потом резко увеличил интенсивность записи в этот файл. Он постоянно рос, пока не занял все пространство раздела. После этого я увеличил раздел, и он снова плавно все занял.

Смысл в том, что nginx несколько дней писал в удаленный файл, который занимал место на диске. Если бы разработчик не трогал этот лог, то он бы ротировался раз в сутки и проблемы бы не было. А так он из системы был удален, но реально постоянно рос, его не было видно и он не обрабатывался с помощью logrotate.

В итоге через пару часов, когда я уже готовил подменный сервер, еще раз внимательно все проверил и обратил внимание на удаленные логи и место, которое они занимают. Вопрос решился простым перезапуском службы nginx. Он тут же отцепил свой лог файл и начал писать в новый. А старый реально удалился из системы и освободил место.

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

Можно оценить примерно, сколько стоит аккуратная работа. Если бы я просто перезагрузил сервер, то решил бы вопрос за 5 минут. Но пришлось действовать наверняка и тратить время. Когда-то это оправданно, когда-то нет. Лично я всегда перестраховываюсь и действую наверняка.

Онлайн курс по Linux

• Умение строить отказоустойчивые кластера виртуализации для запуска современных сервисов, рассчитанных под высокую нагрузку.
• Будете разбираться в современных технологиях кластеризации, оркестрации и виртуализации.
• Научитесь выбирать технологии для построения отказоустойчивых систем под высокую нагрузку.
• Практические навыки внедрения виртуализации KVM, oVirt, Xen.
• Кластеризация сервисов на базе pacemaker,k8s, nomad и построение дисковых кластеров на базе ceph, glaster, linstore.

Источник

File system is 100% full

Recently, my system disk, somehow, got filled up to 92%. According to the recommendations in the forums, I removed (using the Synaptics) obsolete version of Linux kernels (which lead to ONLY 62% of the system filled), cleaned the system trash etc., even tried to removed emails from Evolution. The computer has been on since then (for an hour or two), and then I've got a message of the system FULL (100%)! Any suggestions?

I've just ran the Disk Usage Analyser, that's shown a HUGE file in the .cache directory. The file's come from a system utility, which sits in the System Tools->Administration->System Testing. Shift-Deleted it and got ONLY 56% of the disk taken. Thanks to everybody for the help!

2 Answers 2

Something is rapidly filling your disk.

My first shot would be to check if there are some unusually big files in /var/log and subdirectories.

will list all directory of file in current directory with the size;

will list the 10 biggest files of current directory. If you find which file is growing and with which data you are a step nearer to the solution.

yeah the logs occupies the whole disk; I delete them & the Ubuntu box can work right after; thank you.! ^_^

Did you check you log files? Sometimes applications running in debug mode can write huge log files that take up all space.

Do sudo du -sh * . on your root to find out the FS utilization directory wise and post it here if you can.

Another thing that happens sometimes when you have mounts on NFS is that some open files got deleted forcefully and the orphans start getting huge and huge till it takes up all space in no time.

Источник

Find why a disk is at 100% utilization in linux

I have a virtual machine running an application. After some time, its load starts increasing and the machine becomes unresponsive to commands. After monitoring the disks usage, I found out a mounted SSD disk(AWS EBS General SSD) used by application is 100% busy with no read and writes from nmon . Snapshot of nmon is: Snapshot of top is: I also tried using iotop to find the read and writes but there is no process doing a lot of read/writes. Output of iostat -x 2 5 is: Besides this, All ps commands are getting stuck and enter into D state. How to find the cause of 100% disk busy/utilized? Edit: The mounted partition is using XFS file system.

For VM’s with otherwise inexplicable performance issues it may be worthwhile to look at “stealtime” to see if a VM is suffering from noisy neighbours. If that is the case ; simply power the VM down and restart it after a couple of minutes. Usually that will restart the VM on a different hypervisor; mitigating performance issues.

In this case I would also stop the instance and copy its storage to a new storage volume, then restart the instance with the new volume.

There are a number of volume metrics exposed by EBS volumes. One of these may provide some useful insight, as may dmesg . It is possible, even likely, that this condition reflects bad hardware or bad Nitro behavior that can only be mediated by moving to new equipment, but I'm a little disappointed by what feels like premature and speculative throwing up of hands in some of the previous comments. It should not be the instance and the volume, but it may very well be one of them. Trashing the whole thing doesn't provide much of a learning opportunity.

Источник

>11GB free space, but it says 100% disk usage?

I've also tried running sudo tune2fs -m 0 /dev/sda1 , to no avail.

@EEAA: Those answers do not solve my problem. I've restarted multiple times, so it's not like there's some file that was to be deleted that hasn't yet been removed. There is >11GB of free-space, but I can't use it. Reopen this question.

1 Answer 1

I don't see in the info you provided any reason for which you'd think you have 11G left (other than the difference in G between Size and Used + Available , but it's incorrect to assume that such difference means Available , especially when Available is clearly stated as 0). On all extX filesystems Used + Available < Size due to reserved blocks and maybe other reasons.

There is no discrepancy between the df and pydf reports on the respective columns (as you questions appears to suggest) if you take into account that 1G = 1024 * 1024 K:

Plus both df and pydf indicate 0 on the available column.

Does that also explain this? - i.imgur.com/KwqY5f3.png - Also, even when I delete a few files (let's say 10MB of files), I don't gain [10MB] free space.

Yes, unused doesn't mean available. If the running system has /tmp, /var or the active user's homedir on that partition there are many processes constantly trying to write to it and will immediately use any little free space you make available. In general I try to keep at least 10-15% (or 10-20G for the homedir) free to prevent problems and reduce fragmentation which can degrade performance significantly.

Источник