¿Cómo limitar la E / S del disco durante la copia de seguridad?

14

Tengo un cron que básicamente hace un simple "tar zcf" en la noche.

El servidor tiene:

8 núcleos - Intel (R) Xeon (R) CPU E5606 @ 2.13GHz
25 GB de RAM
Ubuntu 12.04.2 LTS
RAID de hardware 1 (LSI Logic / Symbios Logic MegaRAID SAS SMC2108) con dos discos duros de 2.728 TB

Como puede ver en la pantalla de monitoreo:

Durante casi todo el tiempo del alquitrán, la E / S del disco llega a> 90% y hace que todas las demás aplicaciones (mysql, apache) se ralenticen mucho.

2 preguntas:

¿Es normal tener una E / S de disco tan alta durante la copia de seguridad?
¿Hay alguna forma de limitar la E / S del disco para que otra aplicación pueda continuar funcionando correctamente?

¡Gracias!

— acemtp
fuente

11

Además del enfoque bastante general, ionicehay un buen objetivo de mapeador de dispositivos (ioband) que permite un control preciso sobre el ancho de banda a un dispositivo de bloque (DM). Desafortunadamente no es parte del núcleo estándar.

Además, probablemente pueda acelerar el alquitrán

Lectura de los nombres de archivo en el caché del disco: find /source/path -printf ""
Lectura de los inodos en el caché del disco: find /source/path -perm 777 -printf ""
Hacer que el alquitrán lea y escriba bloques más grandes desde y hacia el disco, por ejemplo, utilizando una tubería con mbuffer o buffer (con al menos 100 MiB de RAM): tar ... | mbuffer -m 256M -P 100 -p 1 ...

— Hauke Laging
fuente

¿Por qué leer los nombres de archivo / inodes en la memoria caché reduce la E / S de disco mientras se taringa? Esperaría que aumente el IO promedio al tiempo que reduce el tiempo total solo ligeramente.

— scai

3

@scai Esto no ayuda con los SSD; mi recomendación se refiere solo a discos duros giratorios. Lo que mata el rendimiento con esos es el movimiento de la cabeza. Los nombres de los archivos se almacenan en bloques continuos, los inodes se almacenan en bloques continuos y el contenido del archivo se almacena en bloques continuos. Si lo hace de la manera tar, entonces lee los nombres de archivo (y subdirectorio) de un directorio, accede al inodo para un archivo, luego al archivo en sí, luego al inodo para el siguiente archivo, luego al siguiente archivo ... Eso causa más movimiento de la cabeza que leer todos los nombres e inodos uno tras otro.

— Hauke Laging

@scai El impacto en el rendimiento depende de lo que hagas. Es bastante pequeño para las copias de seguridad completas (probablemente depende del tamaño de los archivos), pero noté una gran diferencia para las copias de seguridad diferenciales (no para tar, sin embargo, ya que no lo uso, pero esto debería ser un efecto general).

— Hauke Laging

Solo para estar seguro de que entendí correctamente. Para 1. y 2., ¿solo tenemos que llamar al comando find y Linux lo almacenará automáticamente en caché?

— acemtp

@acemtp Eso es correcto. findsin -permembargo (sin) no accederá al archivo inode. Pero eso permite que la optimización use dos findllamadas. Si realiza la misma findllamada dos veces (con poco tiempo en el medio), la segunda generalmente terminará en segundos (o menos). Dependiendo de la cantidad de memoria libre y la cantidad de datos almacenados en caché en un determinado punto, los datos se expulsan de la memoria caché. Por lo tanto, leer demasiado puede ralentizar la operación. Si puede alimentar el programa de copia de seguridad con nombres de archivos a través de stdin, puede evitar esto leyendo bloques de, por ejemplo, 100 archivos.

— Hauke Laging

13

Se espera que vea E / S altas durante las copias de seguridad porque generalmente se realizan sobre árboles de archivos grandes con archivos grandes. Puede usar ionicepara priorizar trabajos de E / S en Linux con clases y niveles. IIRC, clase 2, nivel 7 es el nivel más bajo, sin hambre, lo que lo hará prácticamente invisible para otras cargas y usuarios de E / S. Ver man ionicepara uso y detalles.

— bayindirh
fuente

1

Recomendaría deshacerse del alquitrán e ir con rsync (como lo mencionó Dogsbody). Utilizo BackupPC para hacer copias de seguridad de archivos en mis sistemas Windows y Linux y admite el uso de tar y rsync y automáticamente se encarga de los enlaces duros para usted, además de proporcionar una interfaz web agradable.

http://backuppc.sourceforge.net/

— Atari911
fuente

0

Como han respondido otros, sí, esto es normal y ionicees una buena forma genérica de no dejar que afecte a su sistema.

Sin tarembargo, varias veces he visto cosas de la gente cuando no es necesario. Si algún porcentaje de los datos que está copiando no ha cambiado desde la última copia, le sugiero que lo rsyncintente.

Esto reducirá la E / S al copiar solo los archivos que han cambiado desde la última copia. no podrá reducir el IO en más de la mitad, ya que todos los datos aún tendrían que leerse, pero reducirá significativamente la cantidad de datos escritos (lo que, dependiendo de su hardware, también puede ser una operación más lenta).

Si desea copias / copias de seguridad separadas cada vez que se ejecuta, la opción más potente es –link-dest, que le permite vincular archivos sin cambios a una copia de seguridad anterior. Esto ahorra ENORMES cantidades de espacio en el servidor de respaldo. por ejemplo, hago una copia de seguridad de una máquina (Fred), Fred tiene un disco duro de 20 GB y hago una copia de seguridad / copia de toda la unidad, excepto / proc y / dev. Ahora tengo un directorio de 20GB en mi servidor de respaldo. Al día siguiente vuelvo a respaldar a Fred y –link-dest a la copia de seguridad de ayer. Rsync compara los archivos remotos con la copia local y, si es exactamente lo mismo, no se molestará en transferirlos, pero vinculará el nuevo archivo al archivo de ayer. Todos los archivos que han cambiado se copian de nuevo (o se copian parcialmente usando la copia de seguridad de ayer si es posible). Si solo se modificaron 100 MB de archivos desde ayer, ahora tengo dos directorios, ambos con 20 GB de archivos, pero solo ocupan 20.

Espero que eso ayude y aún responda tu pregunta.

— Burro de carga
fuente