Recientemente instalé Munin en un servidor web de desarrollo para realizar un seguimiento del uso del sistema. He notado que el uso de inodos del sistema está aumentando aproximadamente entre un 7% y un 8% por día, aunque el uso del disco apenas ha aumentado. Supongo que algo está escribiendo un montón de archivos pequeños pero no puedo encontrar qué ni dónde.
Sé cómo encontrar el uso del espacio en disco, pero parece que no puedo encontrar una manera de resumir el uso del inodo.
¿Existe una buena manera de determinar el uso de inodos por directorio para poder localizar la fuente del uso?
Respuesta1
No espere que esto se ejecute rápidamente...
cd a un directorio donde sospecha que puede haber un subdirectorio con muchos inodos. Si este script lleva una gran cantidad de tiempo, es probable que haya encontrado en qué parte del sistema de archivos buscar. /var es un buen comienzo...
De lo contrario, si cambia al directorio superior de ese sistema de archivos, lo ejecuta y espera a que finalice, encontrará el directorio con todos los inodos.
find . -type d |
while
read line
do
echo "$( find "$line" -maxdepth 1 | wc -l) $line"
done |
sort -rn | less
No me preocupa el coste de la clasificación. Ejecuté una prueba y clasificar la salida sin clasificar de 350.000 directorios me llevó 8 segundos. El hallazgo inicial tomó . El costo real es abrir todos estos directorios en el ciclo while. (el bucle en sí dura 22 segundos). (Los datos de prueba se ejecutaron en un subdirectorio con 350.000 directorios, uno de los cuales tenía un millón de archivos, el resto tenía entre 1 y 15 directorios).
Varias personas han señalado que ls no es bueno en eso porque ordena la salida. Probé el eco, pero tampoco es muy bueno. Alguien más había señalado que las estadísticas brindan esta información (número de entradas del directorio) pero que no es portátil. Resulta que find -max Depth es muy rápido abriendo directorios y cuenta archivos ., así que... aquí está... ¡puntos para todos!
Respuesta2
Si el problema es un directorio con demasiados archivos, aquí tienes una solución sencilla:
# 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
La idea detrás de esta findlínea es que el tamaño de un directorio es proporcional a la cantidad de archivos directamente dentro de ese directorio. Entonces, aquí buscamos directorios con toneladas de archivos en su interior.
Si no desea adivinar un número y prefiere enumerar todos los directorios sospechosos ordenados por "tamaño", también es fácil:
# Remove the "sort" command if you want incremental output
find / -xdev -size +10k -type d -printf '%s %p\n' | sort -n
Respuesta3
Grrr, comentar requiere 50 repeticiones. Entonces esta respuesta es en realidad un comentario sobre la respuesta de Chris.
Dado que al interrogador probablemente no le importan todos los directorios, solo los peores, entonces usar sort probablemente sea una exageración muy costosa.
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
Esto no es tan completo como su versión, pero lo que hace es imprimir líneas si son más grandes que el máximo anterior, lo que reduce en gran medida la cantidad de ruido impreso y ahorra el gasto de ese tipo.
La desventaja de esto es que si tienes 2 directorios muy grandes y el primero tiene 1 inodo más que el segundo, nunca verás el segundo.
Una solución más completa sería escribir un script en Perl más inteligente que realice un seguimiento de los 10 valores principales vistos y los imprima al final. Pero eso es demasiado largo para una respuesta rápida a un error del servidor.
Además, algunas secuencias de comandos Perl medianamente más inteligentes le permitirían omitir el ciclo while; en la mayoría de las plataformas, ls ordena los resultados, y eso también puede ser muy costoso para directorios grandes. El tipo ls no es necesario aquí, ya que lo único que nos importa es el recuento.
Respuesta4
Esta no es una respuesta directa a su pregunta, pero buscar archivos modificados recientemente con un tamaño pequeño usando buscar puede limitar su búsqueda:
find / -mmin -10 -size -20k