Eliminar archivos muy grandes sin congelar el servidor web

En mi servidor web (Apache se está ejecutando, Linux CentOS), hay un archivo de registro muy grande ( 50 Gbyte ). Este servidor web tiene algunos servicios web en producción.

Cuando traté de eliminar el archivo de registro, el servidor web no respondió durante unos 10 segundos. (Servicio fuera de tiempo.)

rm -f monthly.log

¿Hay alguna forma de eliminar este archivo grande sin congelar Apache?

Gírelo primero logrotateusando una configuración como esta:

/path/to/the/log {
    missingok
    notifempty
    sharedscripts
    daily   
    rotate 7
    postrotate
        /sbin/service httpd reload > /dev/null 2>/dev/null || true
    endscript
    compress
}

luego cree un trabajo cron a medianoche para eliminar el archivo girado:

30 2 * * * nice -n 19 ionice -c2 -n7 rm -f /path/to/the/log/file.1

Para una eliminación más rápida de archivos grandes, puede usar el truncatecomando - Diga para reducirlo a un tamaño de cero y luego eliminarlo:

 truncate -s 0  monthly.log && rm -f monthly.log

Sin embargo, como se recomienda quanta, primero debe registrarlo.

echo "0" > monthly.log && rm -f monthly.log

Truncaría / cero el archivo con la : > /path/to/monthly.logoperación. Luego, posiblemente reinicie el proceso de Apache y configure la rotación de registros para evitar que esto suceda en el futuro ...

Sin embargo, esto surge a menudo:

Ver: ¿Hay alguna forma de eliminar un archivo de 100GB en Linux sin agotar IO / load?

En Unix, ¿cuál es la mejor manera de reducir el tamaño de un archivo de registro masivo en el que se está escribiendo activamente?

Servidor Linux sin espacio

Si no necesita los datos, trúnquelos usando / dev / null:

cat /dev/null > monthly.log

El servidor web continuará escribiendo datos en el archivo después del truncamiento, lo que evita la necesidad de reiniciar el servidor web (a diferencia de lo rm monthly.logque elimina el archivo).

Después de resolver la crisis inmediata, considere la rotación como sugirió Quanta. No quieres que esto vuelva a suceder. Tenga en cuenta que los archivos de registro de Apache ya están rotados de forma predeterminada en CentOS

También considere enviar los registros web a través de syslog (usando /usr/bin/logger, por ejemplo). Los registros que se crean utilizando syslog también suelen tener configurada la rotación de registros.

Si está utilizando el sistema de archivos ext3, considere cambiar a ext4.

Ext3 puede ser lento para eliminar archivos grandes porque almacena la ubicación de cada bloque 4k individual: un archivo 50GiB (50 * 1024 ^ 3 bytes) ocupa 13107200 bloques, cada uno de los cuales se registra en la tabla de inodo como un número de bloque de 32 bits , para un total de 50MiB de datos de contabilidad solo para realizar un seguimiento de dónde se encuentran los contenidos del archivo en el disco. Esa gran lista de bloqueos puede estar dispersa en muchos bloques indirectos , todos los cuales deben actualizarse cuando se elimina el archivo. El disco que busca acceder a todos esos bloques indirectos es probablemente lo que está causando el retraso.

Ext4, por otro lado, asigna archivos en "extensiones" de hasta 128MiB. Ese archivo de 50GiB se puede grabar en la tabla de inodo usando solo 400 registros de extensión, en lugar de 13107200 números de bloque individuales, lo que reduce drásticamente la cantidad de E / S de disco necesaria al eliminar el archivo.

Tenga en cuenta que si convierte un sistema de archivos ext3 existente en su lugar en ext4, los archivos nuevos se asignarán usando extensiones, pero los archivos existentes seguirán usando listas de bloqueo. Puede usar el chattr +ecomando para reasignar un archivo existente usando extensiones; En cuanto al rendimiento, esto es comparable a hacer una copia del archivo y luego eliminar el original.

Esto se reduce a un problema de rendimiento del sistema de archivos. Hay una respuesta interesante a esto en esta pregunta SO, pero esto depende bastante de qué sistema de archivos esté usando. Utilicé XFS al crear un sistema de archivos para almacenar cientos de archivos MPEG2 de varios gigabytes para MythTV porque en ese momento el rendimiento de eliminación de XFS era muy superior a ext3. Las cosas pueden haber cambiado considerablemente en los años intermedios.

Sin embargo, me gusta la respuesta de @ quanta. Dividir el archivo en partes más pequeñas conducirá a una eliminación más rápida.

El problema proviene, supongo, de que está eliminando el archivo del usuario privilegiado que tiene más prioridad para las operaciones de disco que el usuario del servidor web apache. Independientemente de la forma en que elija eliminar el archivo de registro (rm -f o truncar por>), debe reducir sus operaciones de prioridad de disco a un mínimo:

  ionice -c3 rm -f filename.log