Auf einem Server, auf dem ich Tomcat mit einer Java-Anwendung ausführe, geht mir der Speicherplatz aus. Auf diesem Rechner befindet sich keine Datenbank.
Ich verwende CentOS Linux 7 (Core) mit Kernel: Linux 3.10.0-514.26.2.el7.x86_64
So sieht meine Festplattenspeichersituation aus:
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/cl-root 37G 37G 86M 100% /
devtmpfs 3,9G 0 3,9G 0% /dev
tmpfs 3,9G 0 3,9G 0% /dev/shm
tmpfs 3,9G 8,6M 3,9G 1% /run
tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup
/dev/sda1 1014M 184M 831M 19% /boot
tmpfs 782M 0 782M 0% /run/user/1000
tmpfs 782M 0 782M 0% /run/user/0
Dies ist die Liste der größten Dateien, die ich finden kann:
du -a /var/ | sort -n -r | head -n 30
239816 /var/
95968 /var/log
75148 /var/cache
74300 /var/cache/yum/x86_64/7
74300 /var/cache/yum/x86_64
74300 /var/cache/yum
68564 /var/lib
61472 /var/lib/rpm
55856 /var/lib/rpm/Packages
38316 /var/cache/yum/x86_64/7/updates
36604 /var/log/audit
34932 /var/cache/yum/x86_64/7/base
32608 /var/log/messages
32108 /var/cache/yum/x86_64/7/updates/gen/primary_db.sqlite
32108 /var/cache/yum/x86_64/7/updates/gen
28876 /var/cache/yum/x86_64/7/base/gen/primary_db.sqlite
28876 /var/cache/yum/x86_64/7/base/gen
23652 /var/log/messages-20180304
8200 /var/log/audit/audit.log.4
8200 /var/log/audit/audit.log.3
8200 /var/log/audit/audit.log.2
8200 /var/log/audit/audit.log.1
6916 /var/lib/yum
6200 /var/cache/yum/x86_64/7/updates/6124c600ba0c1509090cbf4b4b33e565c0bd8b9a992285c1cbc1a92815249da9-primary.sqlite.bz2
5888 /var/cache/yum/x86_64/7/base/0c34273ad0292747ee5e15c047d3e51c67ca59861a446972db45d71abacc7ad7-primary.sqlite.bz2
5812 /var/lib/yum/yumdb
3804 /var/log/audit/audit.log
2060 /var/log/anaconda
1644 /var/lib/rpm/Providename
1560 /var/lib/rpm/Basenames
Und auch:
du -hs /
du: cannot access ‘/proc/9446/task/9446/fd/4’: No such file or directory
du: cannot access ‘/proc/9446/task/9446/fdinfo/4’: No such file or directory
du: cannot access ‘/proc/9446/fd/4’: No such file or directory
du: cannot access ‘/proc/9446/fdinfo/4’: No such file or directory
2,4G /
Der Neustart hat die Situation nicht wesentlich geändert (nur ein paar zusätzliche MB). Also habe ich versucht, lsof | grep -i deletTomcat zu schließen und festgestellt, dass es geholfen hätte, da die catalina.outgelöschte Datei immer noch Speicherplatz beanspruchte. Ich habe Tomcat angehalten und neu gestartet und jetzt ist die Situation
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/cl-root 37G 36G 1,8G 96% /
devtmpfs 3,9G 0 3,9G 0% /dev
tmpfs 3,9G 0 3,9G 0% /dev/shm
tmpfs 3,9G 8,6M 3,9G 1% /run
tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup
/dev/sda1 1014M 184M 831M 19% /boot
tmpfs 782M 0 782M 0% /run/user/1000
lsof | grep -i delet
firewalld 678 root 6u REG 253,0 4096 17241411 /tmp/ffiAcnGbQ (deleted)
gmain 678 779 root 6u REG 253,0 4096 17241411 /tmp/ffiAcnGbQ (deleted)
tuned 946 root 7u REG 253,0 4096 17241409 /tmp/ffiQ3hRrZ (deleted)
gmain 946 1532 root 7u REG 253,0 4096 17241409 /tmp/ffiQ3hRrZ (deleted)
tuned 946 1536 root 7u REG 253,0 4096 17241409 /tmp/ffiQ3hRrZ (deleted)
tuned 946 1541 root 7u REG 253,0 4096 17241409 /tmp/ffiQ3hRrZ (deleted)
tuned 946 1549 root 7u REG 253,0 4096 17241409 /tmp/ffiQ3hRrZ (deleted)
Nur um sicherzugehen, habe ich ncdu verwendet:
599,3 MiB [#### ] /opt
297,8 MiB [## ] /var
181,0 MiB [# ] /boot
68,7 MiB [ ] /tmp
55,6 MiB [ ] /root
33,7 MiB [ ] /etc
16,6 MiB [ ] /run
80,0 KiB [ ] /home
. 0,0 B [ ] /proc
0,0 B [ ] /sys
0,0 B [ ] /dev
@ 0,0 B [ ] lib64
@ 0,0 B [ ] sbin
@ 0,0 B [ ] lib
@ 0,0 B [ ] bin
e 0,0 B [ ] /srv
e 0,0 B [ ] /mnt
e 0,0 B [ ] /media
Wo ist der Rest meines Speicherplatzes?
Edit: noch eine Information
cat /proc/self/mounts
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,seclabel,nosuid,size=3990644k,nr_inodes=997661,mode=755 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,seclabel,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs ro,seclabel,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_prio,net_cls 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
/dev/mapper/cl-root / xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=36,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,seclabel,relatime 0 0
mqueue /dev/mqueue mqueue rw,seclabel,relatime 0 0
/dev/sda1 /boot xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/user/1000 tmpfs rw,seclabel,nosuid,nodev,relatime,size=800276k,mode=700,uid=1000,gid=1000 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
Antwort1
Es ist plausibel, dass Sie ein Dateisystem über einem Verzeichnis gemountet haben, das den verwendeten Speicherplatz enthält. Z. B. /tmp oder /var/tmp.
Könnten Sie versuchen, das Ergebnis von auszugeben cat /proc/self/mounts?
Sie könnten versuchen, das Root-Dateisystem erneut in einem neuen Pfad einzubinden, sodass sich keine Dateisysteme darüber befinden.
$ mkdir /tmp/tmproot
$ mount /dev/mapper/cl-root /tmp/tmproot
$# Do this to find largest single directories and descend down..
$ du -h --max-depth=1 -x /tmp/tmproot | sort -h
...
$ umount /tmp/tmproot
$ rmdir /tmp/tmproot
Alternativ ist es plausibel, dass das Dateisystem irgendwie beschädigt ist und verwendete Inodes verbraucht hat, ohne die zugrunde liegende Datei zu entfernen. Ich weiß jedoch nicht, wie das logisch zwischen Dateisystemen funktioniert.
Das Einbinden des Dateisystems in seinen ursprünglichen Zustand kann hoffentlich Aufschluss darüber geben, wo die Dateien versteckt sind.
Antwort2
Einfache Möglichkeit, nach verlorenem Speicherplatz zu suchen.
- Neustart. Bei Unix-Systemen wird die entfernte Datei nicht von der Festplatte oder aus dem Cache gelöscht, bis sie von allen Prozessen geschlossen wird. Wenn Sie wissen, wer mit großen Dateien arbeiten kann, starten Sie diesen Prozess neu. Überprüfen Sie, ob sich der freie Speicherplatz geändert hat.
- Wenn das nicht hilft, versuchen Sie,
du -hs /path/*die Liste der großen Ordner abzurufen. Nicht immer ist die größte Datei die Ursache des Problems, sondern einige tausend kleinere Dateien können es sein.