Sem espaço em disco, qual é a fonte?

Question

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  220G     0 100% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  220G     0 100% /var/lib/ureadahead/debugfs

enquanto entrava em pânico em busca de respostas após o que pareciam ser idades, o uso diminuiu

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G  9.3G  200G   5% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G  9.3G  200G   5% /var/lib/ureadahead/debugfs

Ainda não deletei nada e o e agora que estou escrevendo isso está de volta para

/dev/sda1             220G   12G  197G   6% /

O que aconteceu? Como posso investigar a causa e definir as coisas para que isso não aconteça novamente? Evite que isso aconteça novamente

Durante o tempo de uso da massagem, descobri que o tamanho da pasta / var era constante em 1,8 GB, mas não consegui verificar todas as pastas

editar subiu para

/dev/sda1             220G   18G  192G   9% /

* update 2 * Está subindo novamente

ubuntu /: df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             220G   43G  167G  21% /
none                  1.9G  168K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G   52K  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  220G   43G  167G  21% /var/lib/ureadahead/debugfs

E verificando o comando que me foi dado

ubuntu /: du -h --max-depth=1 /
31M     /boot
4.0K    /selinux
8.0K    /srv
7.4M    /bin
du: cannot access '/proc/9993/task/9993/fd/4': No such file or directory
du: cannot access '/proc/9993/task/9993/fdinfo/4': No such file or directory
du: cannot access '/proc/9993/fd/4': No such file or directory
du: cannot access '/proc/9993/fdinfo/4': No such file or directory
0       /proc
12K     /tmp
2.4G    /var
0       /sys
100K    /root
4.0K    /media
575M    /usr
4.0K    /opt
16K     /lost+found
4.5M    /home
270M    /lib
168K    /dev
4.0K    /mnt
6.7M    /sbin
6.1M    /etc
4.0K    /cdrom
3.3G    /

observe o 3.3G para /

    

Answer 1

O problema estava sendo iniciado por uma tarefa Cron executando um comando CLI do PHP a cada minuto. O código PHP parecia estar preso em algum tipo de loop de insanidade de erros detectados e grande quantidade de dados de depuração crescendo na velocidade do processador.

Como o código php sendo executado demorava mais de um minuto, ele não considerava o trabalho realizado, ele continuava a executar de novo e de novo aumentando a velocidade de crescimento dos dados (temporários?).

A mesma tarefa foi executada por quase um mês sem problemas, por isso não foi em minha mente como uma causa.

O estranho é que o script php define o tempo máximo de execução manualmente

Eu verifiquei o php.ini em busca de pistas

; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time = 30

; Maximum amount of time each script may spend parsing request data. It's a good
; idea to limit this time on productions servers in order to eliminate unexpect$
; long running scripts.
; Note: This directive is hardcoded to -1 for the CLI SAPI
; Default Value: -1 (Unlimited)
; Development Value: 60 (60 seconds)
; Production Value: 60 (60 seconds)
; http://php.net/max-input-time
max_input_time = 60

Ele diz que os valores são codificados para ilimitado para o CLI!  O_o

    

Answer 2

Acho que você está escrevendo algo em um arquivo que foi excluído da unidade, mas que ainda não foi fechado pelo aplicativo / servidor, portanto, o espaço permanece alocado no disco, mas não pode ser visto por du , pois o arquivo estava removido do sistema de arquivos. O programa lsof lista processos que possuem arquivos abertos. Se você tivesse mais sistemas de arquivos montados e o número não flutuasse tanto, então eu teria sugerido que você tinha um sistema de arquivos montado sobre um diretório que não estava vazio (embora você pudesse tentar umount /var/lib/ureadahead/debugfs e certificar-se de que o diretório está vazio e não há um monte de lixo escrito no diretório escondido sob esse ponto de montagem).

Se este for o caso, você deve facilmente encontrá-los com sudo lsof | grep deleted . lsof inclui (deleted) na última coluna se um arquivo tiver sido excluído enquanto um processo ainda o tiver aberto. A primeira coluna é o nome do comando, a segunda coluna é o PID. Você pode obter uma visão mais detalhada do comando usando ps para a instância ps auxww | grep PID ou ps auxwwf | less -S para ver a lista de processos no modo "floresta" para que você possa ver de que processo esse PID veio. Depois de rastrear o (s) processo (s) que estão mantendo arquivos gigantes abertos, você pode pará-lo para liberar o espaço da unidade e, em seguida, descobrir como corrigi-lo para fechar o arquivo corretamente. A causa comum é um script logrotate que renomeia / exclui arquivos de log, mas não notifica o aplicativo de que o fez (seja através de um sinal apropriado com kill ou reiniciando o aplicativo), portanto, o aplicativo continua a manter o arquivo de log antigo aberto.

    

Answer 3

Executar

du -h --max-depth=1 /

E isso deve dar uma imagem mais clara. Se a sua vinda e vai soa como arquivos temporários sendo criados e, em seguida, não excluídos, uma vez feito com, até que processo está causando falhas. Qual sistema operacional é este servidor rodando e está executando algo em particular?

    

Answer 4

Parece que o problema é /var/lib/ureadahead/debugfs . Parece que este é um problema conhecido, aqui está um link para UbuntuDreams com mais informações. > link . O tl; dr parece ser atualizar e atualizar, sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabled , depois reinicializar. Claro, estou supondo que você esteja executando 10.04.

    

Answer 5

Meu palpite é dos arquivos de log; Eu tinha tantos avisos de PHP 5.3 "obsoletos" em meus logs do Apache em um servidor dev que eu não estava realmente prestando atenção ao que ele mastigou todos os 8GB de espaço na minha partição var (como uma barra lateral para o problema: você deve sempre colocar / var em uma partição separada que sua partição raiz como ficar sem espaço pode causar problemas de instabilidade do sistema).

    

Answer 6

Se o espaço foi consumido muito rapidamente (não em idades), provavelmente é apenas a alocação de arquivos.

A causa pode ser uma troca enorme ou arquivos temporários para algum aplicativo, que são esvaziados após o processo.

Faça um du --max-length=1 quando o espaço for muito consumido.

Se você acha que sua pasta raiz está demorando muito (3.3 GB), tente ll -a / e poste os resultados.

    

Answer 7

Parece que /var/lib/ureadahead/debugfs pode ser um "red-herring". Aqui está o porquê ...

Embora /var/lib/ureadahead/debugfs exista em /etc/mtab , ele não é encontrado em /proc/mounts :

$ mount | grep debug
none on /sys/kernel/debug type debugfs (rw)
none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)

$ cat /proc/mounts | grep debug
none /sys/kernel/debug debugfs rw,relatime 0 0

O comando df parece estar relatando exatamente a mesma coisa para /var/lib/ureadahead/debugfs e /

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   1681128   8115792  18% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   1681128   8115792  18% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

Criando um arquivo de 1 GB em /tmp :

$ dd if=/dev/zero of=/tmp/carypjunk.out bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 52.7234 s, 20.4 MB/s

Mostra o tamanho informado nos dois lugares:

$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             10321208   2730216   7066704  28% /
none                    830388       120    830268   1% /dev
none                    880752         0    880752   0% /dev/shm
none                    880752        60    880692   1% /var/run
none                    880752         0    880752   0% /var/lock
none                    880752         0    880752   0% /lib/init/rw
none                  10321208   2730216   7066704  28% /var/lib/ureadahead/debugfs
/dev/sdb             153899044    192068 145889352   1% /mnt

Então, parece que /var/lib/ureadahead/debugfs device é um "red-herring", já que está apenas espelhando as estatísticas de / . Se você está ficando sem espaço, isso se deve a algo que está preenchendo seu sistema de arquivos raiz. Eu checaria seu / var / log primeiro.