Centos でディスク容量を大量に消費しているユーザーを検出できない

Centos でディスク容量を大量に消費しているユーザーを検出できない

1 つの Java アプリケーションで Tomcat を実行しているサーバーのディスク領域が不足しています。このマシンにはデータベースがありません。

私は CentOS Linux 7 (Core) を使用しています。カーネル: Linux 3.10.0-514.26.2.el7.x86_64

私のディスク容量の状況は次のとおりです:

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

以下は私が見つけた最大のファイルのリストです:

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

さらに:

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    /

再起動しても状況は大きく変わりませんでした(数MB増えただけです)。そこで試してみたところ、 削除したファイルがまだスペースを占有していたlsof | grep -i deletため、Tomcatを閉じると改善される可能性があることがわかりましたcatalina.out。Tomcatを停止して再起動したところ、状況は次のようになりました。

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)

念のため、ncdu を使用しました:

  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

残りのディスク容量はどこにありますか?

編集: もう1つの情報

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

答え1

使用済み領域を含むディレクトリの上にファイルシステムがマウントされている可能性があります。たとえば、/tmp または /var/tmp などです。

の結果を出力してみていただけますかcat /proc/self/mounts?

ルート ファイルシステムを、その上にファイルシステムが存在しないように新しいパスに再度マウントしてみることもできます。

$ 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

あるいは、ファイルシステムが何らかの形で破損し、基礎となるファイルを削除せずに使用済みの inode を消費している可能性もあります。ただし、それがファイルシステム間で論理的にどのように機能するかはわかりません。

うまくいけば、ファイルシステムを「元の」状態でマウントすると、ファイルが隠されている場所が明らかになる可能性があります。

答え2

失われたスペースを確認する簡単な方法。

  1. 再起動します。 unices では、削除されたファイルは、すべてのプロセスによって閉じられるまで、ディスクまたはキャッシュから削除されません。 巨大なファイルを操作できるユーザーがわかっている場合は、そのプロセスを再起動します。 空き領域の変化を確認します。
  2. それでも解決しない場合は、du -hs /path/*巨大なフォルダーのリストを取得してみてください。常に最大のファイルが問題の原因であるとは限りませんが、数千の小さなファイルが原因である可能性があります。

関連情報