Problema de espaço GZip / disco estranho

0

Estou trabalhando em um servidor que está usando regras de particionamento compatíveis com PCI, o que significa que cada um dos seguintes diretórios possui sua própria partição: /, / var, / boot, / usr, / tmp e / home. O servidor está hospedando um site no momento com um backend Apache / MySQL.

Recebi um aviso de que a partição / var (cujo tamanho é de 2 GB) estava ficando sem espaço. Eu verifiquei e o log de acesso do Apache localizado em /var/log/access.log estava gerando uma quantidade ridícula de texto: aproximadamente 1 GB em cerca de 10 dias sem configuração de rotação de log.

Eu reconfigurei a configuração do Apache para colocar os logs em outra partição com mais espaço, e configurei a rotação do log com a compactação gzip.

Aqui está a parte estranha. O antigo log de acesso do Apache estava localizado em /var/log/access.log e tinha cerca de 920 MB descomprimido. A partição / var estava cerca de 80% cheia, então usava 1,6 GB do total de 2,0 GB.

Eu executei o seguinte comando para compactar o arquivo de log:

cd /var/log && gzip -9 access.log > access-2011-12-19.log.gz

Eu percebo agora que eu estava um pouco enferrujado com o uso do gzip porque ele criou dois arquivos: access-2011-12-19.log.gz, que estava vazio, e access.log.gz, que agora era de 68 MB e continha o arquivo de log original de 920 MB. Eu apaguei o arquivo access-2011-12-19.log.gz, e o arquivo de log antigo foi embora.

O problema: Eu então verifiquei o espaço na partição / var, e para minha confusão, agora leia como trazer 78% completo, ou cerca de 1,4 GB.

Parece que a compactação de um arquivo de log de 920 MB para 68 MB deve economizar muito espaço em disco, mas parece que não. Qual poderia ser o problema? O servidor está rodando o CentOS 6, se isso ajudar qualquer um.

    
por Scott Crooks 20.12.2011 / 02:31

1 resposta

2

Quanto tempo após o gzip ter terminado, você verificou o uso do disco? A última etapa do gzip ping é excluir o arquivo original. Depois de excluir um arquivo grande, pode levar algum tempo até que o sistema de arquivos rastreie e libere todos os inodes associados. Eu às vezes vi algumas horas, embora isso estivesse em um arquivo muito maior do que o seu.

Editado para adicionar: Outra possibilidade é que algum processo ainda estava mantendo access.log open; talvez até mesmo que o Apache ainda estivesse escrevendo para ele? Mesmo depois de você desvincular ("excluir") um arquivo do sistema de arquivos, ele não será realmente excluído, desde que haja descritores de arquivo abertos apontando para ele.

Além disso, devo mencionar - se você quiser que gzip grave um arquivo compactado (ou descompactado) na saída padrão e não remova o original descompactado (ou original compactado), é possível especificar a opção -c . Alternativamente, você pode enviar o arquivo original na entrada padrão, em vez de passar seu nome como argumento. Então, qualquer um destes:

gzip -c -9 access.log > access-2011-12-19.log.gz
gzip -9 < access.log > access-2011-12-19.log.gz

(Eu costumo usar a última abordagem, pessoalmente).

    
por 20.12.2011 / 02:36