Hacer un rm -rf en un árbol de directorios masivo lleva horas

20

Estamos usando rsnapshot para copias de seguridad. Mantiene muchas instantáneas del archivo copiado, pero elimina las antiguas. Esto es bueno. Sin embargo, se tarda aproximadamente 7 horas en hacer un rm -rfárbol de directorios masivo. El sistema de archivos es XFS. No estoy seguro de cuántos archivos hay, pero probablemente sean millones.

¿Hay alguna forma de acelerarlo? ¿Hay algún comando que haga lo mismo rm -rfy no tome horas y horas?

— Rory
fuente

1

Solía find . -delete -name directoryy es mucho más rápido que rm -rf.

— Paolo

38

No.

rm -rfrealiza un recorrido recursivo en profundidad de su sistema de archivos, invocando unlink()cada archivo. Las dos operaciones que hacen que el proceso vaya lentamente son opendir()/ readdir()y unlink(). opendir()y readdir()dependen de la cantidad de archivos en el directorio. unlink()depende del tamaño del archivo que se elimina. La única forma de hacer que esto sea más rápido es reducir el tamaño y la cantidad de archivos (lo cual sospecho que no es probable) o cambiar el sistema de archivos a uno con mejores características para esas operaciones. Creo que XFS es bueno para unlink () en archivos grandes, pero no es tan bueno para estructuras de directorios grandes. Es posible que ext3 + dirindex o reiserfs sea más rápido. No estoy seguro de qué tan bien le va a JFS, pero estoy seguro de que hay muchos puntos de referencia del rendimiento del sistema de archivos diferente.

Editar: Parece que XFS es terrible para eliminar árboles , así que definitivamente cambie su sistema de archivos.

— David Pashley
fuente

1

Hace algunos años, noté un rendimiento terrible al usar reiserfs en un caso de uso similar.

— knweiss

1

¡Publicación maravillosa!

— wzzrd

2

Casi dice "no" :)

— David Pashley

2

Estoy de acuerdo con todo aquí, aparte de su declaración de que la velocidad de desvinculación depende del tamaño del archivo. unlink simplemente elimina el enlace al archivo y no hace nada al contenido real. No debería haber una diferencia apreciable entre archivos de diferente tamaño (puede probar esto usted mismo).

— Kamil Kisiel

@KamilKisiel Tiene razón al decir unlinkque no hace nada al contenido real, pero para realizar una unlinkllamada al sistema, el código del sistema de archivos tiene más trabajo que hacer si el enlace eliminado es el último al archivo y si no está abierto actualmente. Por supuesto, esto depende del sistema de archivos, pero puede haber una diferencia muy perceptible cuando el archivo eliminado es enorme.

— jlliagre

22

Como alternativa, mueva el directorio a un lado, vuelva a crearlo con el mismo nombre, permisos y propiedad y reinicie las aplicaciones / servicios que se preocupan por ese directorio.

Luego puede "rm agradable" el directorio original en segundo plano sin tener que preocuparse por una interrupción prolongada.

— Greg trabajo
fuente

Eso podría funcionar, ya que un mv es muy, muy rápido.

— Rory

Sí, funciona bien. He usado esta técnica muchas veces para "arreglar" buzones de correo basados en maildir donde un cliente de correo electrónico perdió el cerebro y dejó un desastre en el disco. El directorio (único) más grande que he arreglado de esta manera tenía alrededor de 1.5 o 2 millones de archivos IIRC. El tiempo de inactividad total para el usuario final fue de ~ 3 minutos, la mayor parte de los cuales estaba esperando que el cliente de correo y los procesos de imap murieran.

— Greg Work

7

Asegúrese de tener las opciones de montaje correctas establecidas para XFS.

Usando -ologbufs = 8, logbsize = 256k con XFS probablemente triplicará su rendimiento de eliminación.

— James
fuente

2

+1 por este consejo ... Uno también debería habilitar contadores flojos para otro aumento de rendimiento.

— hurikhan77

1

Alguna explicación sobre esta configuración sería útil para futuros lectores.

— Aron Rotteveel

5

Si está haciendo el rm efectivamente en el nivel de archivo, entonces llevará mucho tiempo. Es por eso que las instantáneas basadas en bloques son tan buenas :).

Podría intentar dividir el rm en áreas separadas e intentar hacerlo en paralelo, sin embargo, no podría esperar que mejore. Se sabe que XFS tiene problemas para eliminar archivos y si eso es una gran parte de lo que haces, tal vez sería una idea un sistema de archivos diferente para eso.

— James
fuente

Las instantáneas basadas en bloques no son únicamente buenas en este caso. Varios sistemas de archivos (WAFL y ZFS vienen a mi mente inmediatamente) también proporcionan un buen rendimiento para la eliminación de instantáneas. Tratan las instantáneas como objetos del sistema de archivos de primera clase. Entonces, en lugar de iterar (lentamente) sobre millones de archivos para determinar qué bloques liberar, solo tienen que mirar la lista de bloques asociada con la instantánea.

— Keith Smith el

Hmm Probablemente salí como siendo demasiado contrario arriba. El póster original debe estar usando Linux, y realmente no hay un sistema de archivos Linux bien probado que haga instantáneas, aunque btrfs y nilfs parecen interesantes para el futuro. Entonces, en términos prácticos, estoy de acuerdo: es mejor usar instantáneas basadas en bloques.

— Keith Smith el

+1 para que la punta divida y paralelice la carga de trabajo: xfs juega su fuerza en cargas de trabajo paralelas.

— hurikhan77

5

Es bueno usar ionice para operaciones intensivas en IO como esa, independientemente del sistema de archivos utilizado.
Sugiero este comando:

ionice -n7 nice rm -fr dir_name

Funcionará bien para operaciones en segundo plano en el servidor con una gran carga de E / S.

— ash108
fuente

2

Sé que esto es viejo, pero pensé que la identificación debería incluir una sugerencia. Está eliminando esos archivos secuencialmente, la ejecución de operaciones rm paralelas puede acelerar las cosas.

http://savannah.nongnu.org/projects/parallel/ parallel puede usarse comúnmente en lugar de xargs

así que si estás eliminando todos los archivos en deltedir

find -t f deletedir | parallel -j 10 rm

Eso te dejaría con estructuras de directorio vacías para eliminar.

Nota: Es probable que aún alcance las limitaciones del sistema de archivos como se indicó anteriormente.

— Nick Anderson
fuente

¿Qué ventaja tiene usar paralelo sobre xargs?

— Rory

1

¿Sería una opción alternativa aquí separar los datos de tal manera que pueda desechar y reconstruir el sistema de archivos real en lugar de hacer el rm?

— Mugir
fuente

3

Creo que rsnapshot usa enlaces duros como parte de la función de mantenimiento de múltiples instantáneas de manera eficiente. Así que si la pregunta está utilizando esa función por medio de sistemas de archivos separados no va a funcionar (como pueda no de vínculo físico sobrepasa el límite de sistema de archivos)

— David Spillett

0

¿Qué hay de disminuir la amabilidad del comando? Me gusta:

nice -20 rm -rf /path/to/dir/

— RainyRat
fuente

55

El cuello de botella no es el planificador, es el sistema de archivos, diría.

— Manuel Faux

En el improbable caso de que el planificador sea el cuello de botella, solo terminaría golpeando el subsistema de E / S con mayor dificultad, haciendo que el servidor sea aún menos utilizable durante el rm.

— David Mackintosh