
Tivemos o compartilhamento do nosso servidor samba (ubuntu 8.04 ltr) preenchido outro dia, mas quando fui dar uma olhada nele, não consigo ver que nenhum dos compartilhamentos tenha muito neles
temos 5 compartilhamentos em grupo e cada usuário tem um compartilhamento individual
um usuário tem 22 GB de material, alguns outros têm de 10 a 20 MB de material e todos os outros estão vazios
então talvez uns 26 gigs no total
Excluí alguns arquivos ontem e liberei cerca de 250 MB de espaço hoje, quando verifiquei, estava completamente cheio novamente e excluí alguns arquivos mais antigos e liberei cerca de 170 MB de material, mas posso vê-lo lentamente diminuindo no espaço livre.
Continuo executando umdf -h
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 241690180 229340500 169200 100% /
varrun 257632 260 257372 1% /var/run
varlock 257632 0 257632 0% /var/lock
udev 257632 72 257560 1% /dev
devshm 257632 52 257580 1% /dev/shm
lrm 257632 40000 217632 16% /lib/modules/2.6.24-28-generic
/volátil
o que posso fazer para tentar descobrir o que está ocupando tanto do meu disco rígido? (sou bastante novo no Unix em geral, então peço desculpas se isso não estiver bem explicado)
Responder1
(Esta é uma resposta focada no Linux. Outras variantes do UNIX podem ser diferentes.)
Existem duas informações relevantes para o seu problema: (1) quais arquivos estão preenchendo seu sistema de arquivos e (2) quais processos estão gravando nesses arquivos.
Notas
Abaixo, quando coloco o $
caractere nos comandos, provavelmente é um espaço reservado onde você precisa substituir um valor real. Felizmente, é óbvio onde fazer isso e onde não fazer.
Quais arquivos?
Esteja ciente de que existem realmente dois recursos na maioria dos tipos de sistemas de arquivos que podem ser usados por arquivos individuais: metadados (por exemplo, inodes) e dados reais. Você pode ver o número de inodes (pesquise uma definição no Google, mas eles são "ponteiros" para as estruturas que compõem seus arquivos) com um comando como:
df -i
... e como você já sabe, algo assim mostrará o espaço que está sendo utilizado pelos dados reais:
df -h
Além disso, esteja ciente de que o espaço do sistema de arquivos pode ser ocupado por arquivos que não existem no disco. Esses arquivos ainda estão abertos por algum processo, mas foram removidos (abordaremos isso abaixo).
Depois de identificar o(s) sistema(s) de arquivos completo(s), você precisará começar a procurar muitos arquivos pequenos, alguns arquivos grandes ou ambos. A falta de recursos de metadados geralmente é causada por muitos arquivos pequenos, enquanto a falta de recursos de dados reais geralmente é causada por alguns arquivos grandes. Gosto de usar este comando para ajudar a encontrar arquivos grandes:
sudo find $file_system -mount -ls | awk '{print $7, $11}' | sort -rn > $output
... e este comando para ajudar a encontrar diretórios com muitos arquivos pequenos (Atualizar:: adição de terminação nula para melhorar o tratamento de nomes de arquivos):
sudo find . -mount -print0 | xargs -0n 1 dirname | sort | uniq -c | sort -rn > $output
... esteja ciente de que esses comandos podem demorar um pouco para serem executados e gerar muita E/S, dependendo. Depois de executado, você pode ler $output
para encontrar os arquivos ou diretórios incorretos. O nome e a localização de cada um podem dar uma dica sobre a origem dos dados, mas requer alguma experiência em Linux.
Depois de identificar os infratores, você pode rm $file
se livrar do problema.
Quais processos?
A maneira mais direta de encontrar os processos que potencialmente preenchem seu sistema de arquivos é executar um comando como:
fuser -c $file_system 2>/dev/null
... que informará o PID dos processos que possuem descritores de arquivos abertos (arquivos e soquetes de rede) para um determinado sistema de arquivos (a 2>/dev/null
parte elimina algumas informações que você não precisa). Você pode deduzir apenas desses PIDs qual processo está preenchendo seu sistema de arquivos. Procure os processos com:
ps -ef | grep $pid
Você também pode tentar executar este comando, que fornecerá ainda mais detalhes (e ajudará a identificar arquivos abertos sem nome de arquivo correspondente no disco - mencionei isso acima):
sudo lsof $file_system | grep $directory_filling_up
... e se você identificou um PID suspeito no fuser
comando, você pode fazer isso:
sudo lsof -p $pid
O problema com fuser
e lsof
é que eles fornecem apenas um instantâneo do sistema no momento em que você executa o comando. Se o processo ofensivo não estiver sendo escrito quando você os executar, você estará sem sorte. Você pode combater isso executando-os repetidamente ao longo do tempo e salvando a saída. Isso exigirá a leitura da saída para encontrar padrões ou a escrita de um programa para fazer isso por você. Uma alternativa é usar uma ferramenta comoSystemTap. SystemTap permite capturar todos os tipos de informações úteis e é “programável”. Ele ainda vem com alguns arquivos de origem de amostra que permitem ver quais processos estão gravando em quais arquivos durante um determinado período de tempo. Seria perfeito, mas é uma ferramenta avançada e requer muito conhecimento em Linux.
Depois de identificar o(s) processo(s) ofensivo(s), você pode matá-los (e talvez reiniciá-los). Se o processo estiver associado ao sistema operacional ou a algum software bem empacotado, provavelmente haverá um mecanismo para reiniciá-los, mas isso dependerá da sua distribuição Linux (acho que o Ubuntu permitirá que você execute algo como /etc/init.d/$init_script restart
, mas você terá para verificar a documentação da sua distribuição). Caso contrário, você pode matá-lo com kill $pid
ou kill -9 $pid
se ele não estiver se comportando. Tenha o cuidado de observar como o processo estava sendo executado (por exemplo, quais foram os argumentos mostrados em ps -ef
) caso você precise reiniciá-lo (talvez seja necessário consultar a documentação desse software).
Responder2
Use du
para rastrear o diretório que contém os arquivos que estão preenchendo o disco.
cd /
du -h --max-depth 1
mostrará qual diretório em / usa mais espaço. Percorra o sistema de arquivos executando o comando du para encontrar o culpado.
por exemplo
cd /
du -h --max-depth 1
mostra que /usr está usando 2,3G dos 3,5G usados no sistema.
cd /usr
du -h --max-depth 1
mostra que /usr/lib usa 1.1G do 2.3 em /usr ...
Isso também pode ser causado por um arquivo aberto que foi excluído.
Você pode usarlsofpara encontrar arquivos que estão abertos, mas desvinculados (excluídos)
lsof +L1
deve fazer o truque. Como afirma a página de manual:
Uma especificação do formulário
+L1
selecionará os arquivos abertos que foram desvinculados. Uma especificação do formulário+L1 <file_system>
selecionará arquivos abertos desvinculados no sistema de arquivos especificado.
Responder3
Algo está preenchendo a partição /. Provavelmente é algo dentro /var/log
ou dentro /home
. Isso depende da sua configuração. Procure também em locais onde seus usuários têm acesso.
Execute o seguinte comando em cada um dos diretórios em questão. Isso mostrará os subdiretórios que são os maiores consumidores de espaço.
cd /directory
du -cks -x * .* |sort -n
Esta ideia é emprestada do ducks
script ( du -cks
) deHacks de servidor Linuxde O'Reilly. Eu executo esse comando com frequência.
Na minha experiência, isso quase sempre se deve a arquivos de log grandes e crescentes. Neste caso, useLogrotate, ecertifique-se de usar compressão. Usando a compactação gzip com a taxa de compactação padrão, seus arquivos de log serão reduzidos em 80-95% (um /var/log/messages de 1 GB pode ser facilmente compactado até 200 MB ou menos). Isso coloca uma carga moderada na CPU, mas raramente vi isso afetar o desempenho real de um servidor. Algumas pessoas preferem usar a compactação Bzip2, ou usar, gzip --best
mas na minha experiência isso causa muita sobrecarga de CPU com poucos benefícios adicionais. gzip
com o índice de inadimplência geralmente é bom o suficiente.
E, obviamente, esse problema às vezes se deve ao fato de um usuário fazer coisas ruins. Use o du
comando acima para encontrar o culpado.
Responder4
O provável culpado são os logs, mas aqui está um comando que classificará os arquivos recentemente modificados (ou criados) por tamanho:
D=$(date --rfc-3339 date);
sudo sh -c 'find / -xdev -mtime -1 -type f -print0 |xargs -0 du -0sbc' \
|tee ~/recent-files.$D |sort -zn |tee ~/recent-by-size.$D |xargs -0n1
Você poderia executar este comando diariamente; provavelmente há uma maneira de fazer algo SQL para classificar esses arquivos por crescimento diário.
(editar) Para monitorar o crescimento, usegt5
sudo aptitude install gt5
cd /
gt5
Um dia depois; procure sinais ±
gt5