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

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 procurando respostas depois do que pareciam 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

Eu não apaguei nada até agora e agora estou escrevendo isso 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? Impeço 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% /

* atualização 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 /

Eu acho que você tem algo gravando em um arquivo que foi excluído da unidade, mas ainda não foi fechado pelo aplicativo / servidor, portanto o espaço permanece alocado no disco, mas não pode ser visto dudesde que o arquivo foi removido do sistema de arquivos. O lsofprograma 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 sugeriria que você tivesse um sistema de arquivos montado em um diretório que não estivesse vazio (embora você possa tentar umount /var/lib/ureadahead/debugfsgarantir que o diretório esteja vazio e não há um monte de lixo gravado no diretório oculto sob esse ponto de montagem).

Se for esse o caso, você deve encontrá-las facilmente com sudo lsof | grep deleted. lsofinclui (deleted)na última coluna se um arquivo foi excluído enquanto um processo ainda o abre. A primeira coluna é o nome do comando, a segunda coluna é o PID. Você pode obter uma visão mais detalhada do comando usando, pspor exemplo ps auxww | grep PID, ou ps auxwwf | less -Spara ver a lista de processos no modo "floresta" para ver de qual processo veio o PID. Depois de rastrear os processos que estão mantendo arquivos gigantes abertos, você pode pará-lo para liberar espaço na unidade e descobrir como corrigi-lo para fechar o arquivo corretamente. A causa comum disso é um script logrotate que renomeia / exclui arquivos de log, mas não notifica o aplicativo que o fez (por meio de um sinal apropriado comkill ou reiniciando o aplicativo), para que o aplicativo continue mantendo o arquivo de log antigo aberto.

Corre

du -h --max-depth=1 /

E deve dar uma imagem mais clara. Se estiver indo e vindo, parece que os arquivos temporários estão sendo criados e não excluídos uma vez terminados, até que o processo esteja causando o travamento. Qual SO está executando este servidor e está executando algo em particular?

Parece que o problema é /var/lib/ureadahead/debugfs. Parece que este é um problema conhecido. Aqui está um link para o ubuntuforums com mais informações http://ubuntuguide.net/howto-fix-ureadahead-problem-after-upgrading-to-ubuntu-10-04 . O tl; dr parece estar atualizado e atualizado e sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabled, em seguida, reinicie. Obviamente, estou assumindo que você esteja executando o 10.04.

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

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

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

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

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

Parece que /var/lib/ureadahead/debugfspode ser um arenque vermelho. Aqui está o porquê...

Embora /var/lib/ureadahead/debugfsexista em /etc/mtab, não foi 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 dfcomando parece estar relatando exatamente a mesma coisa para /var/lib/ureadahead/debugfse/

$ 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 relatado 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 o /var/lib/ureadahead/debugfsdispositivo é um arenque vermelho, pois está apenas refletindo as estatísticas /. Se você estiver ficando sem espaço, isso se deve a algo que preenche seu sistema de arquivos raiz. Eu verificaria seu / var / log primeiro.

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

Como o código php em execução demorou mais de um minuto, não considerou o trabalho concluído, continuou executando repetidamente, aumentando a velocidade do crescimento dos dados (temporários?).

A mesma tarefa está em execução há quase um mês sem problemas, portanto não estava na minha mente como 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 a CLI! O_o