Cómo eliminar millones de archivos sin molestar al servidor

Solución 1:

Haz un script de bash como este:

#!/bin/bash
rm -- "$*"
sleep 0.5

Guárdelo con el nombre deleter.sh por ejemplo. Ejecute chmod u+x deleter.sh para hacerlo ejecutable.

Este script elimina todos los archivos que se le pasan como argumentos y luego duerme 0,5 segundos.

Entonces, puedes ejecutar

find cache.bak -print0 | xargs -0 -n 5 deleter.sh

Este comando recupera una lista de todos los archivos en cache.bak y pasa los cinco nombres de archivo a la vez al script de eliminación.

Por lo tanto, puede ajustar cuántos archivos se eliminan a la vez y cuánto tiempo hay de retraso entre cada operación de eliminación.

Solución 2:

Debería considerar guardar su caché en un sistema de archivos separado que pueda montar/desmontar como alguien indicó en los comentarios. Hasta que lo hagas, puedes usar este delineador /usr/bin/find /path/to/files/ -type f -print0 -exec sleep 0.2 \; -exec echo \; -delete suponiendo que su binario de búsqueda se encuentra en /usr/bin y desea ver el progreso en la pantalla. Ajuste la suspensión en consecuencia, para no sobrecargar su HDD.

Solución 3:

Es posible que desee probar ionice en un script que consume la salida de un comando de búsqueda. Algo como lo siguiente:

ionice -c3 $(
for file in find cache.bak -type f; do
    rm $file
done
for dir in find cache.bak -depthe -type d -empty; do
    rmdir $dir
done
)

Dependiendo del sistema de archivos, cada eliminación de archivos puede resultar en la reescritura de todo el directorio. Para directorios grandes que pueden ser un gran éxito. Se requieren actualizaciones adicionales para la tabla de inodos y posiblemente una lista de espacio libre.

Si el sistema de archivos tiene un diario, los cambios se escriben en el diario; aplicado; y eliminado de la revista. Esto aumenta los requisitos de E/S para la actividad intensiva de escritura.

Es posible que desee utilizar un sistema de archivos sin diario para la memoria caché.

En lugar de ionice, puede usar un comando de suspensión para limitar la velocidad de las acciones. Esto funcionará incluso si ionice no lo hace, pero llevará mucho tiempo eliminar todos sus archivos.

Solución 4:

Obtuve muchas respuestas / comentarios útiles aquí, que me gustaría concluir y también mostrar mi solución.

1. Sí, la mejor forma de prevenir tal cosa que sucede es mantener el directorio de caché en un sistema de archivos separado. Nuking/formateo rápido de un sistema de archivos siempre lleva unos segundos (quizás minutos) como máximo, sin relación con la cantidad de archivos/directorios presentes en él.

2. El ionice / nice Las soluciones no hicieron nada, porque el proceso de eliminación en realidad casi no causó E/S. Lo que causó la E/S fue que creo que las colas/búferes a nivel de kernel/sistema de archivos se llenaron cuando los archivos se eliminaron demasiado rápido por el proceso de eliminación.

3. La forma en que lo resolví es similar a la solución de Tero Kilkanen, pero no requirió llamar a un script de shell. Utilicé el --bwlimit integrado de rsync interruptor para limitar la velocidad de eliminación.

El comando completo fue:

mkdir empty_dir
rsync -v -a --delete --bwlimit=1 empty_dir/ cache.bak/

Ahora bwlimit especifica el ancho de banda en kilobyes, que en este caso se aplica al nombre de archivo o la ruta de los archivos. Al establecerlo en 1 KBps, estaba eliminando alrededor de 100 000 archivos por hora, o 27 archivos por segundo. Los archivos tenían rutas relativas como cache.bak/e/c1/db98339573acc5c76bdac4a601f9ec1e , que tiene 47 caracteres, por lo que daría 1000/47 ~=21 archivos por segundo, algo similar a mi estimación de 100 000 archivos por hora.

Ahora por qué --bwlimit=1 ? Probé varios valores:

• 10000, 1000, 100 -> sistema ralentizándose como antes
• 10 -> el sistema funciona bastante bien durante un tiempo, pero produce ralentizaciones parciales una vez por minuto más o menos. Los tiempos de respuesta HTTP siguen siendo <1 segundo.
• 1 -> ninguna ralentización del sistema. No tengo prisa y se pueden eliminar 2 millones de archivos en <1 día de esta manera, así que lo elijo.

Me gusta la simplicidad del método integrado de rsync, pero esta solución depende de la longitud relativa de la ruta. No es un gran problema ya que la mayoría de las personas encontrarían el valor correcto a través de prueba y error.