Espaço ausente na partição / var?

2

Um de nossos administradores de servidores me pediu para dar uma olhada nisso, e estou perplexo - nossa partição / var está cheia, no entanto, não consigo determinar onde o espaço passou.

O seguinte é a saída de 'du / var -ah'

...
202M    var/

'df -h', no entanto, retorna

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/gza-root  268M  108M  147M  43% /
tmpfs                 2.0G     0  2.0G   0% /lib/init/rw
udev                   10M   68K   10M   1% /dev
tmpfs                 2.0G     0  2.0G   0% /dev/shm
/dev/sda1             236M   20M  204M   9% /boot
/dev/mapper/gza-home  115G   15G   95G  14% /home
/dev/mapper/gza-tmp   380M   11M  350M   3% /tmp
/dev/mapper/gza-usr   4.7G  3.9G  610M  87% /usr
/dev/mapper/gza-var   2.9G  2.7G   26M 100% /var

Não consigo localizar onde os outros 2,5 GB se foram, alguma ideia ou sugestão?

    
por Adam Frisby 01.06.2009 / 07:37

4 respostas

10

Tente reiniciar os serviços. É possível que algo tenha aberto um arquivo em / var quando você apagou (rm desvincula as coisas, ele). O sistema não liberará o espaço até que tudo feche suas alças de arquivo para esse arquivo.

Você pode precisar usar lsof para descobrir qual programa ainda tem os arquivos abertos em / var.

Como é / var, eu acho que algo ainda tem um arquivo de log aberto.

    
por 01.06.2009 / 07:49
3

Existem alguns possíveis caminhos a seguir:

  1. Você está fora de inodes e não de blocos livres (espaço real)? Se houver muitos arquivos pequenos, eles poderão consumir todos os inodes (efetivamente, entradas na tabela de alocação de arquivos). Depois que todos os inodes estiverem esgotados, você não poderá adicionar um novo arquivo, mesmo que haja muitos blocos livres. na partição. Esta é uma resposta curinga para verificar se não há uma arma óbvia para fumar. exaustão do inode é uma ocorrência rara, mas ainda acontece (Blackboard 7.0 ...)
  2. du -s /var/* | sort -rn deve dar uma idéia melhor do que está ocupando espaço em / var, assim como um utilitário gráfico como o KDirStat. Eu não recomendo o KDirStat por esse problema, já que você está lidando com / var. Problemas com / var tendem a afetar a estabilidade do sistema em comparação com problemas de espaço com / home. Além disso, em uma situação de servidor dedicado, você não deve estar executando uma GUI na caixa, em primeiro lugar, fazendo a noção de usar uma ferramenta GUI (local) discutível. Em situações menos críticas, a saída de mapa de árvores esquadrinhada de ferramentas como KDirStat, WinDirStat e SequoiaView torna trivial a identificação de problemas; o treemap é um ótimo meio de visualizar o uso do disco.
  3. Algum serviço está fora de controle e registra quantidades imensas de lixo para / var / log? Se a sua cultura organizacional aceitar, pode ser importante configurar um host de log dedicado e fazer com que todas as máquinas gravem logs na rede. No mínimo, certifique-se de que cada registro seja adequadamente rotacionado, compactado e excluído de acordo com a política de retenção de log do site. logrotate é seu amigo.
  4. Você faz tem uma política de retenção de log, certo? ;) Sério, se você não tiver um, defina um. Pode ser uma sentença - "Manteremos registros por sete dias no valor de registros, a menos que acordos alternativos sejam feitos com o proprietário do serviço. Por escrito."
por 01.06.2009 / 08:25
2

Você tem permissões para todas as pastas em / var? du não relata o espaço usado para coisas que você não tem permissão.

    
por 01.06.2009 / 07:42
0

Eu me pergunto o que sua máquina lhe dirá assim que você perguntar quantos inodes ela sobrou. A capacidade de armazenar dados em uma partição não é apenas uma função do número de blocos livres ...

    
por 01.06.2009 / 08:21