¿Cómo almacenar en caché o acelerar los resúmenes `du`?


33

Tenemos un gran sistema de archivos en el que un duresumen completo (uso del disco) lleva más de dos minutos. Me gustaría encontrar una manera de acelerar un resumen del uso del disco para directorios arbitrarios en ese sistema de archivos.

Para las ramas pequeñas, he notado que los duresultados parecen estar almacenados en caché de alguna manera, ya que las solicitudes repetidas son mucho más rápidas, pero en las ramas grandes la velocidad se vuelve insignificante.

¿Existe una manera simple de acelerar duo almacenar en caché los resultados de forma más agresiva para las ramas que no se han modificado desde la búsqueda anterior?

¿O hay un comando alternativo que puede entregar resúmenes de uso de disco más rápido?


8
Dos minutos no me parecen largos. Pero la verdadera pregunta es: "¿Realmente quieres du para almacenar algo?" ¿No debería darte recuentos de bloques de disco reales, tan actuales como sea posible?
Bruce Ediger

Estoy de acuerdo en que reemplazarlo dusería malo, pero un script de envoltura más rápido con una interfaz idéntica sería muy útil para nosotros. Además, esperaría que los resultados de almacenamiento en caché dependientes del tiempo de última modificación (y suponiendo que no haya operaciones en todo el disco, por ejemplo, desfragmentación) arrojarían resultados de tamaño exacto: ¿me estoy perdiendo algo?
Ian Mackinnon

2
Si le preocupa el uso excesivo del disco, puede considerar implementar una cuota.
pyasi

2
Bruce: podrías hacer la misma pregunta find. Pero luego está locate.
Yuval

Si está en Android , eche un vistazo a StatFsuna estimación súper rápida de los tamaños de directorio. Fue casi 1000 veces más rápido para directorios grandes y complejos, en comparación con du.
Joshua Pinter

Respuestas:


21

Lo que está viendo cuando vuelve a ejecutar un comando du es el efecto del almacenamiento en búfer de disco. Una vez que lee un bloque, el búfer de su disco se mantiene en la caché del búfer hasta que se necesita ese bloque. Para du necesita leer el directorio y el inodo para cada archivo en el directorio. Los resultados du no se almacenan en caché en este caso, pero pueden derivarse con mucho menos E / S de disco.

Si bien sería posible forzar al sistema a almacenar en caché esta información, el rendimiento general se vería afectado ya que el espacio de búfer requerido no estaría disponible para archivos de acceso activo.

El directorio en sí no tiene idea de qué tan grande es un archivo, por lo que se necesita acceder al inodo de cada archivo. Para mantener actualizado el valor en caché cada vez que un archivo cambia de tamaño, el valor en caché debería actualizarse. Como un archivo se puede enumerar en 0 o más directorios, esto requeriría que el inodo de cada archivo sepa en qué directorios está incluido. Esto complicaría en gran medida la estructura del inodo y reduciría el rendimiento de IO. Además, dado que du le permite obtener resultados asumiendo diferentes tamaños de bloque, los datos requeridos en la memoria caché necesitarían aumentar o disminuir el valor almacenado en caché para cada posible tamaño de bloque, lo que ralentizaría aún más el rendimiento.


7

Si puede organizar las diferentes jerarquías de archivos para que pertenezcan a diferentes grupos, puede configurar cuotas de disco . No le dé un límite superior (ni lo haga del tamaño del disco) a menos que desee uno. Aún podrá saber instantáneamente cuánto de su cuota (efectivamente infinita) está usando el grupo.

Esto requiere que su sistema de archivos admita cuotas por grupo. Ext [234] de Linux y zfs de Solaris / * BSD / Linux. Sería bueno para su caso de uso si las cuotas grupales tomaran en cuenta las ACL, pero no creo que lo hagan.


7

El uso común de duse puede acelerar enormemente mediante el uso ncdu.

ncdu - NCurses Disk Usage

realiza du, almacena en caché los resultados y los muestra en una bonita interfaz gráfica de línea de comando, algo comparable a du -hc -d 1 | sort -h. La indexación inicial lleva el mismo tiempo du, pero se acelera la búsqueda del "culpable" real que llena un espacio precioso, ya que todos los subdirectorios tienen disponible inicialmente la información almacenada en caché.

Si es necesario, los subdirectorios se pueden actualizar presionando [r] y los archivos / carpetas se pueden eliminar presionando [d], los cuales actualizan las estadísticas para todos los directorios principales. La eliminación solicita confirmación.

Si es necesario, se puede lograr ncdu -1xo- / | gzip >export.gzuna mayor aceleración al preajustar en un cronjob y luego acceder a él zcat export.gz | ncdu -f-, pero obviamente proporciona más información desactualizada.


7

Prefiero usar el agedu

Agedu es un software que intenta encontrar archivos viejos y de uso irregular con la presunción de que es muy probable que estos archivos no sean deseados. (por ejemplo, descargas que solo se han visto una vez).

Básicamente realiza el mismo tipo de escaneo de disco du, pero también registra los últimos tiempos de acceso de todo lo que escanea. Luego, crea un índice que le permite generar de manera eficiente informes que dan un resumen de los resultados para cada subdirectorio, y luego produce esos informes a pedido.


44
No responde la pregunta, pero sigue siendo +1. Buen consejo.
0xC0000022L

He editado la pregunta para aclarar que esto realmente responde a la pregunta (agedu indexa el uso del disco y el tiempo de acceso).
Anthony G - justicia para Mónica

5

Como mencionó SHW, de ageduhecho creó un índice. Pensé en compartir otra forma de crear un índice, después de leer sobre locatedb. Puede crear su propia versión de a locatedbdesde la dusalida:

du | awk '{print $2,$1}' | /usr/lib/locate/frcode > du.locatedb

awkreorganiza la salida du para tener nombres de archivo primero, para que frcodefuncione correctamente. Luego, use locateesta base de datos para informar rápidamente el uso del disco:

locate --database=du.locatedb pingus

Puede ampliar esto para satisfacer sus necesidades. Creo que es un buen uso de ubicaciónb.


3
duc

(ver https://duc.zevv.nl ) podría ser lo que está buscando.

Duc almacena el uso del disco en una base de datos optimizada, lo que resulta en una interfaz de usuario rápida. No hay tiempos de espera una vez que se completa el índice.

Actualizar el índice es muy rápido para mí (menos de 10 segundos para alrededor de 950k archivos en 121k directorios, 2.8 TB). Tiene una GUI y una interfaz de usuario ncurses también.

Uso, por ejemplo:

duc index /usr
duc ui /usr

Desde el sitio web:

Duc está diseñado para escalar a grandes sistemas de archivos: indexará y mostrará cientos de millones de archivos en petabytes de almacenamiento sin problemas.


2

Tengo un cronjob configurado para ejecutar updatedb cada 10 minutos. Mantiene todos los búferes del sistema de archivos agradables y frescos. También podría usar esa RAM barata para algo bueno. Use slabtop ver 'antes' y 'después'.


No entiendo cómo su respuesta se relaciona con la pregunta. updatedbno dice nada sobre el uso del disco. Si lo hace solo para atravesar el disco, perjudicará el rendimiento general.
Gilles 'SO- deja de ser malvado'

3
El conteo de tamaños de archivo dues lento porque tiene que acceder a los metadatos de una cantidad potencialmente grande de archivos, dispersos por el disco. Si ejecuta updatedb agresivamente, los metadatos de todos los archivos se verán obligados a almacenarse en la RAM. La próxima vez que ejecute cualquier otra operación con muchos metadatos, en lugar de hacer miles de búsquedas en los discos, usará el caché. Normalmente tiene una pequeña posibilidad de tener esa parte particular de los metadatos del árbol en caché. Con mi 'cebado de caché de metadatos' es muy probable que los datos que desea estén recién almacenados en caché. Sin búsquedas físicas == RÁPIDO.
Marcin

2

Si solo necesita saber el tamaño del directorio, puede acelerarlo mucho simplemente evitando escribir la información en la pantalla. Como el total general es la última línea del ducomando, simplemente puede canalizarlo tail.

du -hc | tail -n 1

Una estructura de directorio de 2GB toma más de un segundo para la lista completa, pero menos de un quinto de eso con este formulario.


2
Creo que du -hses más conveniente para ese propósito.
lepe

1
también--max-depth 1
stevesliva
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.