espaço em disco continua preenchendo a instância do EC2 sem arquivos / diretórios.

Question

Como é que os programas mostram o 6.5G usado, mas vejo apenas 3.6G em arquivos / diretórios?

Executado como root em um Amazon Linux AMI (parece o Centos), muita memória livre disponível, sem troca, sem a aparente falta de descritores de arquivo. A única coisa em que consigo pensar é um arquivo de log que foi excluído enquanto os aplicativos são anexados a ele.

O uso de espaço em disco está lenta mas continuamente aumentando em direção à capacidade total (~ 1k / min com diminuições muito pequenas de tempos em tempos)

Alguma explicação? Solução?

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<br/> /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<br/> access/proc/14024/fdinfo/4': No such file or directory 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 1

Se um arquivo que foi excluído ainda estiver aberto por um processo, o espaço não será recuperado até que o processo feche o arquivo (ou seja morto). Se você não conseguir identificar o processo que está mantendo um arquivo aberto, uma reinicialização ajudará, pois fechará todos os processos em execução (e, assim, fechará todos os arquivos abertos).

Outra consideração é a corrupção do sistema de arquivos. Como este é o seu sistema de arquivos raiz, você pode precisar reiniciar e forçar uma verificação do sistema de arquivos ao reiniciar ( shutdown -rF now ). Certifique-se de estar configurado para executar uma varredura + correção não interativa, a menos que tenha acesso KVM ou similar (para que possa interagir durante o processo de inicialização), caso contrário, sua máquina remota aguardará pela entrada local se encontrar erros durante a verificação.

Editar: (conforme a pergunta no comentário)

Se você souber que o processo está mantendo o arquivo aberto, basta reiniciar esse processo específico (seja por meio de scripts de parada / inicialização / reinício de serviço ou por meio da eliminação e reinicialização mais manual) em vez da instância inteira.

Além disso, alguns programas suportam poder redefinir a si mesmos sem reiniciar, o que geralmente inclui o fechamento e a reinicialização de arquivos de log (resolvendo o problema se realmente for devido a um arquivo de log excluído) em resposta ao envio de um sinal SIGHUP (via kill ). A reinicialização de processos dessa maneira é às vezes preferível, pois reduz (muitas vezes a zero) a quantidade de tempo que um processo do servidor é incapaz de aceitar novas conexões. Geralmente é o que acontece quando você executa /etc/init.d/<service> reload em vez de /etc/init.d/<service> restart (se eu tiver visto restart implementado dessa forma, para fazer uma redefinição completa adequada, você precisa fazer /etc/init.d/<service> stop; /etc/init.d/<service> start ).

    

Answer 2

Gerenciado para recuperar o espaço sem reiniciar o processo mantendo-o aberto através dos links fd em / proc // fd /.

1) acesse o caminho dos descritores de arquivos do processo de manutenção:

cd /proc/'lsof|grep '<deleted_file>'|head -1|awk '{print $2}''/fd

2) encontre o processo fd link:

ll | grep <deleted_file>

3) substituir com branco (todos os dados serão perdidos)

 > <fd>