Não é possível detectar quem está ocupando muito espaço em disco no Centos

Não é possível detectar quem está ocupando muito espaço em disco no Centos

Estou ficando sem espaço em disco em um servidor onde estou executando o Tomcat com um aplicativo Java. Nenhum banco de dados nesta máquina.

Estou usando CentOS Linux 7 (Core) com Kernel: Linux 3.10.0-514.26.2.el7.x86_64

Esta é a minha situação de espaço em disco:

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

Esta é a lista dos maiores arquivos que posso encontrar:

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

E também:

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    /

A reinicialização não alterou significativamente a situação (apenas alguns MB adicionais). Então, tentei lsof | grep -i delete descobri que fechar o Tomcat poderia ter ajudado, pois o catalina.outarquivo que excluí ainda estava ocupando espaço. Parei e reiniciei o Tomcat, e agora a situação é

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)

Só para verificar, usei 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

Onde está o resto do meu espaço em disco?

Edit: mais uma informação

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

Responder1

É plausível que você tenha um sistema de arquivos montado sobre um diretório que contém o espaço usado. Ou seja, /tmp ou /var/tmp.

Você poderia tentar gerar o resultado de cat /proc/self/mounts?

Você pode tentar montar o sistema de arquivos raiz novamente em um novo caminho, de modo que não haja sistemas de arquivos acima dele.

$ 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

Alternativamente, é plausível que o sistema de arquivos esteja danificado de alguma forma e tenha consumido inodes usados ​​sem remover o arquivo subjacente. Não sei como isso funciona logicamente entre sistemas de arquivos.

Esperançosamente, montar o sistema de arquivos em seu estado 'purificado' pode revelar onde os arquivos estão ocultos.

Responder2

Maneira simples de verificar se há espaço perdido.

  1. Reinício. Em unices, o arquivo removido não é excluído do disco ou dos caches até que seja fechado por todos os processos. Se você sabe quem pode trabalhar com arquivos enormes, reinicie esse processo. Verifique se há alterações de espaço livre.
  2. Quando isso não ajudar, tente du -hs /path/*obter a lista de pastas enormes. Nem sempre o arquivo maior é a fonte do problema, mas alguns milhares de arquivos menores podem ser.

informação relacionada