Instalei recentemente o Munin em um servidor web de desenvolvimento para monitorar o uso do sistema. Percebi que o uso de inodes do sistema está aumentando cerca de 7 a 8% por dia, embora o uso do disco quase não tenha aumentado. Suponho que algo esteja gravando muitos arquivos minúsculos, mas não consigo encontrar o quê/onde.
Eu sei como encontrar o uso do espaço em disco, mas não consigo encontrar uma maneira de resumir o uso do inode.
Existe uma boa maneira de determinar o uso do inode por diretório para que eu possa localizar a origem do uso?
Responder1
Não espere que isso aconteça rapidamente...
cd para um diretório onde você suspeita que possa haver um subdiretório com muitos inodes. Se esse script levar muito tempo, você provavelmente já descobriu onde procurar no sistema de arquivos. /var é um bom começo...
Caso contrário, se você mudar para o diretório superior desse sistema de arquivos e executá-lo e esperar que ele termine, você encontrará o diretório com todos os inodes.
find . -type d |
while
read line
do
echo "$( find "$line" -maxdepth 1 | wc -l) $line"
done |
sort -rn | less
Não estou preocupado com o custo da classificação. Executei um teste e a classificação da saída não classificada em 350.000 diretórios levou 8 segundos. A descoberta inicial demorou . O custo real é abrir todos esses diretórios no loop while. (o loop em si leva 22 segundos). (Os dados de teste foram executados em um subdiretório com 350.000 diretórios, um dos quais tinha um milhão de arquivos, o restante tinha entre 1 e 15 diretórios).
Várias pessoas apontaram que ls não é bom nisso porque classifica a saída. Eu tentei echo, mas isso também não é ótimo. Alguém apontou que stat fornece essa informação (número de entradas de diretório), mas não é portátil. Acontece que find -maxprofundidade é muito rápido para abrir diretórios e contar .files, então... aqui está... pontos para todos!
Responder2
Se o problema for um diretório com muitos arquivos, aqui está uma solução simples:
# Let's find which partition is out of inodes:
$ df -hi
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda3 2.4M 2.4M 0 100% /
...
# Okay, now we know the mount point with no free inodes,
# let's find a directory with too many files:
$ find / -xdev -size +100k -type d
A ideia por trás da findlinha é que o tamanho de um diretório seja proporcional à quantidade de arquivos diretamente dentro desse diretório. Então, aqui procuramos diretórios com toneladas de arquivos dentro deles.
Se você não quiser adivinhar um número e preferir listar todos os diretórios suspeitos ordenados por "tamanho", isso também é fácil:
# Remove the "sort" command if you want incremental output
find / -xdev -size +10k -type d -printf '%s %p\n' | sort -n
Responder3
Grrr, comentar requer 50 repetições. Portanto, esta resposta é na verdade um comentário sobre a resposta de Chris.
Como o questionador provavelmente não se importa com todos os diretórios, apenas com os piores, então usar sort é provavelmente um exagero muito caro.
find . -type d |
while
read line
do
echo "$(ls "$line" | wc -l) $line"
done |
perl -a -ne'next unless $F[0]>=$max; print; $max=$F[0]' | less
Isso não é tão completo quanto a sua versão, mas o que faz é imprimir linhas se forem maiores que o máximo anterior, reduzindo bastante a quantidade de ruído impresso e economizando nas despesas da classificação.
A desvantagem disso é que se você tiver 2 diretórios muito grandes e o primeiro tiver 1 inode a mais que o segundo, você nunca verá o segundo.
Uma solução mais completa seria escrever um script Perl mais inteligente que monitorasse os 10 principais valores vistos e os imprimisse no final. Mas isso é muito longo para uma resposta rápida de falha no servidor.
Além disso, alguns scripts Perl mais inteligentes permitiriam pular o loop while - na maioria das plataformas, ls classifica os resultados, e isso também pode ser muito caro para diretórios grandes. A classificação ls não é necessária aqui, pois tudo o que nos importa é a contagem.
Responder4
Esta não é uma resposta direta à sua pergunta, mas pesquisar arquivos modificados recentemente com um tamanho pequeno usando find pode restringir sua pesquisa:
find / -mmin -10 -size -20k