How come os shows 6.5G used but I see only 3.6G in files/directories?
Running as root on an Amazon Linux AMI (seems like Centos), lots of free memory available, no swapping going on, no apparent file descriptors issue.
The only thing I can think of is a log file that was deleted while applications append to it.
Disk space usage is slowly but continuously rising towards full capacity (~1k/min with very small decreases from time to time)
Any explanation?
Solution?
du --max-depth=1 -h /
1.2G /usr
4.0K /cgroup
22M /lib64
11M /sbin
19M /etc
52K /dev
2.1G /var
4.0K /media
0 /sys
4.0K /selinux
du: cannot access/proc/14024/task/14024/fd/4': No such file or directory du: cannot access
/proc/14024/task/14024/fdinfo/4': No such file or directory du:
cannot access/proc/14024/fd/4': No such file or directory du: cannot
/proc/14024/fdinfo/4': No such file or directory
access
0 /proc
18M /home
4.0K /logs
8.1M /bin
16K /lost+found
12M /tmp
4.0K /srv
35M /boot
79M /lib
56K /root
67M /opt
4.0K /local
4.0K /mnt
3.6G /
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 7.9G 6.5G 1.4G 84% / tmpfs 3.7G 0 3.7G 0% /dev/shm
sysctl fs.file-nr fs.file-nr = 864 0 761182
Answer
If a file that has been deleted is still open by a process, the space will not be reclaimed until the process closes the file (or is killed). If you can not identify the process that is holding a file open, then a reboot will help as that will close all running processes (and so close all open files).
Another consideration is filesystem corruption. As this is your root filesystem you may need to reboot and force a filesystem check on restart (shutdown -rF now
). Be sure that you are configured to perform a non-interactive scan+fix unless you have KVM access or similar (so you can interact during the boot process) otherwise your remote machine will hang waiting for local input if it finds errors during the check.
Edit: (as per question in comment)
If you know the process that is holding the file open, you can just restart that particular process (either via service stop/start/restart scripts or by killing and restarting more manually) rather than the whole instance.
Also some programs support being able to reset themselves without restarting which will usually include closing and restarting log files (solving your problem if it is indeed due to a deleted log file that is still open) in response to being sent a SIGHUP signal (via kill
). Resetting processes this way is sometimes preferable as it reduces (often to zero) the amount of time a server process is unable to accept new connections. This is often what happens when you run /etc/init.d/
instead of /etc/init.d/
(if fact I've seen restart
implemented this way so to do a proper full reset you have to do /etc/init.d/
).
Comments
Post a Comment