Es kann nicht erkannt werden, wer auf Centos viel Speicherplatz beansprucht

Es kann nicht erkannt werden, wer auf Centos viel Speicherplatz beansprucht

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.

  1. 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.
  2. 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.

verwandte Informationen