Restic: Las restauraciones podrían ser incluso más rápidas

Creado en 7 nov. 2018  ·  71Comentarios  ·  Fuente: restic/restic

Gracias a la fusión de PR1719, las restauraciones en restic son _mucho_ más rápidas.

Sin embargo, podrían ser aún más rápidos.

Con fines de prueba, restauré desde un bucket de AWS S3 restringido en la misma región (us-west-1) como una instancia i3.8xlarge EC2 dedicada. La restauración fue contra el nvme 4x1.9TB en la instancia, RAID-0 rayado a través de LVM con un sistema de archivos xfs debajo. La instancia tiene un ancho de banda teórico de 10 gbit / seg para S3.

Con workerCount en filerestorer.go subido a 32 (desde el límite compilado de 8), restic restaura una combinación de 228k archivos con un tamaño de archivo medio de 8KB y un tamaño de archivo máximo de 364GB a un promedio de 160mbit / seg.

En comparación, rclone con --transfers = 32 mueve datos del mismo depósito a 5636 mbit / seg, más de 30 veces más rápido.

No es una comparación de manzanas con manzanas. Los blobs de datos Restic tienen un tamaño de 4096KB, no de 8KB, y abrir / cerrar archivos ciertamente tiene _algunas_ sobrecargas. Pero sigue siendo una diferencia lo suficientemente grande como para indicar un cuello de botella en restic.

¡Estoy feliz de probar cosas, proporcionar instrumentación o ayudar de cualquier otra manera!

feature enhancement

Comentario más útil

Curiosidad por el estado de conseguir este fusionaron en. Esta rama, combinada con el trabajo @cbane 's en la velocidad de ciruela pasa hacia arriba, hacer utilizable restic extremadamente grandes para las copias de seguridad.

Todos 71 comentarios

160mbit / seg de hecho parece lento. Me estaba acercando a los 200 Mbps en un macbook pro insignificante que se descargaba desde onedrive a través de una conexión ftth de 1 Gbps (rápida concedida). Realmente no puedo decir nada específico sin acceso a sus sistemas y repositorio, pero aquí hay algunas cosas que debería hacer para reducir el problema, sin ningún orden en particular:

  • Calcule el tiempo que lleva descargar un archivo de paquete único en un solo hilo. Puede calcular esto a partir de su prueba de descarga de rclone 32x, pero también me gustaría saber el tiempo para descargar paquetes individuales con curl para que podamos estimar la sobrecarga de la solicitud http también.
  • Verificaría las estadísticas del sistema operativo cuánto restic se descarga realmente desde S3 durante la restauración. Esto nos dirá si la restauración descarga archivos de paquetes individuales varias veces (lo cual es posible, pero no debería suceder muy a menudo, a menos que haya pasado por alto algo).
  • El nivel de simultaneidad de S3 parece estar limitado a solo 5 conexiones . ¿Puede esto explicar la velocidad de restauración que ve dada la estimación de velocidad de un solo subproceso desde arriba? ¿Qué sucede si aumenta el límite de conexión de backend de S3 para que coincida con el del restaurador?
  • Grafique la utilización de la red durante la restauración para ver si hay brechas o ralentizaciones.
  • Excluya ese archivo de 364 GB de la restauración y vea qué sucede. Actualmente, los archivos individuales se restauran secuencialmente, por lo que este archivo puede sesgar significativamente la velocidad de descarga promedio.

¡Hola!

Gracias por la respuesta. Fue interesante profundizar en

tl; dr: aumentar las conexiones s3 es la clave, pero los aumentos de rendimiento que proporciona son temporales, curiosamente.

  1. La transferencia de paquetes por valor de un solo directorio (3062 archivos con un total de 13 GB) / con rclone --transfers 1 se ejecuta a 233mbit / seg. Confirmado con lsof que solo se está ejecutando con un solo hilo y una sola conexión https en ese modo. La velocidad máxima se logra con --transfers 32 (8.5 gbit / seg, esencialmente velocidad de línea para esta instancia i3.8xlarge ec2). En ambos casos, escribimos en la matriz nvme seccionada.
  2. Feliz de recopilar algunas estadísticas, pero ¿qué te gustaría ver, específicamente? (pero puede que no sea necesario, consulte a continuación)
  3. ¡Vamos a matar dos pájaros de un tiro aquí! Aquí hay un gráfico de la utilización de la red durante las restauraciones con:
  • un stock de acciones restic con este PR fusionado (comete c0572ca15f946c622d9c4009347dc4d6c31cba4c)
  • restic con workerCount subió a 32 y filesWriterCount subió a 128
  • restic con los cambios anteriores + las conexiones s3 aumentaron a 32.
  • resitc con los cambios anteriores + conexiones s3 aumentadas a 64.
  • rclone con --transfers 32 moviendo el directorio data /

El número de ancho de banda está en kbps y se tomó en intervalos de 3 segundos durante 10 minutos. Para las ejecuciones restic, comenzamos a recopilar datos _ después de que restic ya había comenzado a restaurar archivos (es decir, excluye el tiempo de inicio y el tiempo que restic pasa al comienzo de la ejecución recreando la jerarquía de directorios. Durante todas las ejecuciones, la utilización de la CPU en el instancia no superó el 25%.

Obtenemos un ligero aumento al aumentar el workerCount, pero la simultaneidad de S3 parece donde está la ganancia real. Pero si bien comienza fuerte (¡acercándose a la velocidad del clon, a veces!), Las tasas bajan abruptamente y permanecen bajas durante el resto de la carrera. restic también arroja errores que parecen "ignorando el error para [ruta redactada]: no hay suficiente capacidad de caché: solicitada 2148380, disponible 872640" que no arroja con menor concurrencia s3.

Como puede ver, el rendimiento de rclone comienza alto y permanece alto, por lo que no es una situación en la que las escrituras vayan al caché del búfer de la instancia y luego se detengan cuando se vacían en el disco. La matriz nvme es más rápida que la tubería de red, en términos de rendimiento.

  1. No creo que el único archivo grande sea un factor, ya que estoy midiendo la E / S de disco / red durante la restauración, por lo que el hecho de que ese único archivo tarde un tiempo en restaurarse por completo no afectará los números que estoy mirando aquí.

Dado lo anterior, parece que aumentar la concurrencia de S3 es lo que se necesitará para obtener tasas razonables aquí, pero es necesario averiguar por qué el rendimiento está disminuyendo (y si está relacionado con los errores de caché o no).

Si sería útil hacer una instancia i3 rápida y algo de espacio y ancho de banda s3 disponible para sus pruebas, hágamelo saber, feliz de patrocinarlo.

  1. 233mbit / seg por 32 es 7456 y bastante menos de 8.5 gbit / seg. Lo que es extraño. Esperaba que la descarga de un solo subproceso fuera más rápida que el rendimiento por flujo de la descarga de varios subprocesos. Sin embargo, no estoy seguro de lo que esto significa.

  2. Estaba buscando confirmar que restic no vuelve a descargar los mismos paquetes una y otra vez. Creo que el gráfico muestra que las recargas no son un problema, por lo que no se necesitan más estadísticas, al menos no ahora.

  3. ¿Puede confirmar la escala del gráfico? rclone ronda la línea etiquetada como "1000000", si es "1,000,000 kbps", que creo que significa "1gbps" y no se alinea con el número de "8.5 gbit / seg" que mencionaste anteriormente.

  4. Como dije, los archivos individuales se restauran secuencialmente. La descarga de 364 GB a 233mbit / s tomará alrededor de 3.5 horas, y probablemente más debido a la sobrecarga por paquete y al descifrado, todo lo cual ocurre secuencialmente. No puedo decir si 3,5 horas es algo que puede descartar como insignificante sin saber cuánto toma el resto de la restauración.

En cuanto al error not enough cache capacity , aumente averagePackSize al tamaño del archivo de paquete más grande en su repositorio (¿qué tan grande es, por cierto?) Y necesito pensar cómo dimensionar mejor el caché, no tengo un archivo listo respuesta todavía.

¡Hola!

Ups, lo siento. La escala en el gráfico es KB / seg, no kbit / seg. Entonces, 1.012.995 en la primera fila son 8.1 gbit / seg.

Entendí que los archivos se restauraron secuencialmente, pero no entendí que no existe paralelismo para la recuperación de paquetes para un solo archivo. Definitivamente es un obstáculo para las copias de seguridad con archivos grandes, ya que se convierte en su factor limitante. Sería fantástico tener algún paralelismo aquí por esa razón.

Tomando muestras de 10 cubetas al azar, nuestro tamaño máximo de paquete es un poco menos de 12 MB y nuestro tamaño de paquete promedio es de 4,3 MB.

Quizás con más trabajadores y conexiones S3, estamos excediendo el packCacheCapacity de (workerCount + 5) * averagePackSize. Intentaré aumentar eso y ver si los errores desaparecen.

Quizás con más trabajadores y conexiones S3, estamos excediendo el packCacheCapacity de (workerCount + 5) * averagePackSize. Intentaré aumentar eso y ver si los errores desaparecen.

El tamaño de la caché se calcula en función del tamaño del archivo del paquete de 5 MB y workerCount . Aumentar workerCount aumenta el tamaño de la caché. Entonces, o hay una pérdida de memoria o la restauración necesita almacenar en caché muchos archivos de 12 MB por pura casualidad. Subir averagePackSize a 12 MB debería indicarnos cuál.

No hay errores de caché con averagePackSize establecido en 12.

Si hay alguna otra información que podamos brindarle que sea útil, ¡hágamelo saber! Gracias de nuevo.

Parece que estamos perdiendo paralelismo a medida que avanza la restauración y no parece estar relacionado con archivos grandes. Armaré un caso de prueba e informaré.

¡Hola!

Intenté reproducir las caídas de rendimiento que estaba viendo con mi mezcla de archivos de producción con tres mezclas de archivos artificiales diferentes.

Para todas las pruebas, utilicé c0572ca15f946c622d9c4009347dc4d6c31cba4c con conexiones S3 aumentadas a 128, workerCount aumentó a 128, filesWriterCount aumentó a 128 y averagePackSize aumentó a 12 * 1024 * 1024.

Todas las pruebas utilizaron archivos con datos aleatorios para evitar cualquier impacto de la deduplicación.

Para la primera prueba, creé y realicé una copia de seguridad de 4000 archivos de 100 MB, divididos uniformemente en 100 directorios (~ 400 GB en total). Las copias de seguridad y las restauraciones se ejecutaron desde volúmenes nvme seccionados en una instancia i3.8xlarge. El depósito de respaldo estaba ubicado en la misma región que la instancia (us-west-1).

Con esta combinación de archivos, vi velocidades promedio de 9,7 gbit / seg (!) Sin pérdida de paralelismo o velocidad en toda la restauración. Estos números están a la par o por encima de los números de rclone y son esencialmente velocidad de línea, lo cual es fantástico.

Posteriormente, creé y realicé una copia de seguridad de 400,000 archivos de 1 MB, divididos uniformemente en 100 directorios (nuevamente, ~ 400 GB en total).

Los mismos (excelentes) resultados que los anteriores.

Finalmente, creé 40 directorios con 1 archivo de 10GB por directorio. Aquí, las cosas se pusieron interesantes.

Esperaba que esta restauración fuera un poco más lenta, ya que restic solo podría hacer 40 restauraciones simultáneas con 40 conexiones a S3.

En cambio, sin embargo, mientras que Restic abre los 40 archivos para escrituras y escribe en los 40 archivos simultáneamente, solo mantiene una única conexión TCP a S3 abierta a la vez, no 40.

Déjame saber qué estadísticas o instrumentación te gustaría ver.

¿Puede confirmar que hubo 128 conexiones S3 durante las pruebas "rápidas"?

Si habia.

Curioso ... Para ser honesto, la compatibilidad con archivos grandes no es una prioridad en mi lista de prioridades, pero es posible que encuentre algo de tiempo para analizar esto en las próximas semanas. Si alguien quiere profundizar en esto antes que yo, hágamelo saber.

Hice algunas pruebas más y en realidad parece que el tamaño del archivo es una pista falsa, es el recuento de archivos lo que está impulsando el recuento de conexiones de AWS.

Con 128 archivos de 10 MB en 4 directorios, restic solo abre 6 conexiones a AWS, aunque está escribiendo en los 128 archivos.

Con 512 archivos de 10 MB en 4 directorios, restic abre 18 conexiones durante su vida útil, aunque tiene 128 archivos abiertos a la vez.

Con 5120 archivos de 10 MB en 4 directorios, restic abre solo 75 conexiones a AWS durante su vida útil, y nuevamente mantiene abiertos 128 archivos a la vez.

¡Impar!

Me sorprendería mucho si el cliente Go S3 no agrupara y reutilizara las conexiones http. Lo más probable es que no exista una correlación de uno a uno entre el número de trabajadores concurrentes y los sockets TCP abiertos. Entonces, por ejemplo, si la restauración es lenta y procesa los paquetes descargados por cualquier motivo, varios trabajadores compartirán la misma conexión S3.

Hay dos propiedades del restaurador concurrente actual que son responsables de la mayor parte de la complejidad de la implementación y muy probablemente causen la desaceleración que se informa aquí:

  • los archivos individuales se restauran de principio a fin
  • el número de archivos en curso se mantiene al mínimo

La implementación será mucho más simple, usará menos memoria y muy probablemente será más rápida en muchos casos si aceptamos escribir blobs de archivos en cualquier orden y permitir cualquier cantidad de archivos en curso.

La desventaja es que no será posible saber cuántos datos ya se restauraron en un archivo determinado hasta el final de la restauración. Lo que puede resultar confuso, especialmente si la restauración falla o muere. Por lo tanto, es posible que vea un archivo de 10 GB en el sistema de archivos, que en realidad tiene solo unos pocos bytes escritos al final del archivo.

@ fd0 , ¿cree que vale la pena mejorar la restauración actual de principio a fin? Personalmente, estoy dispuesto a admitir que fue sobre ingeniería de mi parte y puedo proporcionar una implementación fuera de orden más simple si está de acuerdo.

No recuerdo si Restic admite la restauración a la salida estándar. Si es así, obviamente deberá mantener la restauración de principio a fin (posiblemente como un caso especial).

@ifedorenko Personalmente estoy a favor de la simplificación, en general, especialmente si viene con mejoras en el rendimiento. Sin embargo, estoy tratando de entender las compensaciones:

La desventaja es que no será posible saber cuántos datos ya se restauraron en un archivo determinado hasta el final de la restauración.

Si no estamos hablando de miles de archivos escritos simultáneamente aquí, ¿tal vez podría usarse un mapa del nombre del archivo a los bytes escritos? Obviamente, la información no estará disponible para el sistema de archivos, pero, para los informes de progreso, aún podría hacerse, ¿no? (¿Y para reanudar una restauración que se interrumpió, tal vez solo verificando las manchas y las compensaciones del archivo en busca de bytes no nulos, tal vez? No lo sé).

No recuerdo si Restic admite la restauración a la salida estándar. Si es así, obviamente deberá mantener la restauración de principio a fin (posiblemente como un caso especial).

No creo que lo haga, no estoy seguro de cómo funcionaría eso de todos modos, ya que las restauraciones son múltiples archivos, tendrías que codificarlos de alguna manera y separarlos de alguna manera, creo.

Si no estamos hablando de miles de archivos escritos simultáneamente aquí, ¿tal vez podría usarse un mapa del nombre del archivo a los bytes escritos?

La implementación más simple es abrir y cerrar archivos para escribir blobs individuales. Si esto resulta ser demasiado lento, entonces tendremos que encontrar una manera de mantener los archivos abiertos para múltiples escrituras de blob, por ejemplo, almacenando en caché los identificadores de archivos abiertos y ordenando las descargas de paquetes para favorecer los archivos ya abiertos.

Restaurar ya rastrea qué blobs se escribieron en qué archivos y qué aún están pendientes. No espero que esta parte cambie mucho. El progreso se rastrea en una estructura de datos separada y tampoco espero que eso cambie.

¿Y para reanudar una restauración que se interrumpió, tal vez simplemente verificando las manchas y las compensaciones del archivo en busca de bytes no nulos, tal vez?

Resume necesita verificar las sumas de comprobación de los archivos en el disco para decidir qué blobs aún deben restaurarse. Creo que esto es cierto independientemente de si la restauración es secuencial o no funciona. Por ejemplo, si el currículum se recupera de un corte de energía, no creo que se pueda suponer que todos los bloques de archivos se vertieron en los discos antes del corte de energía, es decir, los archivos pueden tener espacios o bloques parcialmente escritos.

@pmkane me pregunto si puedes probar # 2101? implementa la restauración fuera de orden, aunque las escrituras en archivos individuales todavía se serializan y el rendimiento de la restauración de archivos grandes aún puede ser subóptimo. y necesita ajustar el número de trabajadores como antes.

Absolutamente. Viajaré esta semana, pero haré la prueba tan pronto como pueda e informaré.

@ifedorenko Probé este PR y crea con éxito la estructura del directorio, pero luego todas las restauraciones de archivos fallan con errores como:

Carga(, 3172070, 0) devolvió un error, volviendo a intentarlo después de 12.182749645s: EOF

maestro restaura bien.

Mi comando de restauración es:

/usr/local/bin/restic.outoforder -r s3: s3.amazonaws.com/ [redactado] -p /root/.restic_pass restore [snapshotid] -t.

Hágame saber qué información adicional puedo proporcionar para ayudar a depurar.

¿Cuántas solicitudes de descarga simultáneas de S3 permiten? Si es 128, ¿puede limitarlo a 32 (que sabemos que funciona)?

Semi-relacionado ... ¿sabe cuántos archivos de índice tiene su repositorio real? Intentando estimar cuánta memoria necesita el restaurador.

No especifiqué un límite de conexión, así que supongo que estaba predeterminado en 5.

Recibo los mismos errores con -o s3.connections = 2 y -o s3.connections = 1.

Actualmente tengo 85 blobs de índice en el índice / carpeta. Tienen un tamaño total de 745 MB.

Mmm. Tendré otra mirada cuando llegue a mi computadora más tarde hoy. Por cierto, "devolvió el error, reintentando" es una advertencia, no un error, por lo que puede estar relacionado con la falla de restauración o puede ser solo una pista falsa.

No estoy seguro de cómo me lo perdí ... el restaurador no leyó completamente todos los archivos del paquete desde el backend en la mayoría de los casos. Debería arreglarse ahora. @pmkane, ¿puedes intentar tu prueba de nuevo?

¡Le daré una vuelta!

Confirmado que los archivos se restauran correctamente con esta corrección. Probando el rendimiento ahora.

Desafortunadamente, parece que es más lento que el maestro. Todas las pruebas se ejecutan en la instancia i3.8xlarge descrita anteriormente.

Con un workerCount de 8 (el valor predeterminado), la rama fuera de servicio se restauró a 86mbit / seg.

Con un workerCount aumentado a 32, lo hizo un poco mejor, con un promedio de 160mbit / seg.

La utilización de la CPU con esta rama es significativamente mayor que en la maestra, pero no está maximizando la CPU de la instancia en ninguno de los casos.

Como anécdota, la interfaz de usuario de restauración hace que parezca que algo se está "pegando", casi como si estuviera compitiendo contra sí mismo por un bloqueo en alguna parte.

Feliz de proporcionar más detalles, creación de perfiles o una instancia de prueba para replicar.

Solo para confirmar, tenía el recuento de trabajadores de backend del restaurador y s3 ​​establecido en 32, ¿verdad?

Un par de pensamientos que pueden explicar el comportamiento que observó:

  • Las escrituras en archivos individuales todavía se serializan. Supuse que esto no sería un problema con los sistemas de archivos de destino rápidos, pero nunca lo medí.
  • El archivo abrir / cerrar alrededor de cada blob ciertamente contribuye a la sobrecarga del restaurador. Cuando medí esto en macos, pude "abrir archivo; escribir un byte; cerrar archivo" 100K veces en ~ 70 segundos, lo que se aproxima a la sobrecarga de escribir 100K blobs. La prueba fue realmente simple y los gastos generales de la vida real pueden ser significativamente más altos.
  • Actualmente no tengo una explicación plausible para la alta utilización de la CPU. La implementación fuera de orden descifra cada blob solo una vez (el maestro descifra los blobs para cada archivo de destino), y hay mucha menos contabilidad en comparación con el maestro. Tal vez las escrituras de archivos "dispersas" no sean realmente escasas y requieran que Go o el sistema operativo hagan algo que requiera mucha CPU. Realmente no lo sé.

¡Hola!

Eso es correcto. workerCount se estableció en 8 o 32 en internal / restorer / filerestorer.go y -o s3.connections = 32 se pasó a través de la cli restic en ambos casos.

Aquí hay una vista de nivel superior de los datos de seguimiento mientras la rama fuera de servicio está restaurando archivos con 8 trabajadores.

Parece que hay pausas significativas (> 500-1000ms) que los trabajadores golpean con frecuencia.
screen shot 2018-12-03 at 9 50 05 am

Decidí dedicar más tiempo a esto y comencé escribiendo una prueba independiente simple que genera bytes aleatorios de 10GiB en bloques de 4KiB. Mi objetivo era evaluar qué tan rápido mi sistema puede mover bytes. Para mi sorpresa, esta prueba tardó 18,64 segundos en ejecutarse en mi macbook pro (2018, Intel Core i7 de 2,6 GHz). Lo que se traduce en ~ 4.29 Gigabits / so aproximadamente la mitad de lo que puede hacer Ethernet 10G. Y esto es sin ninguna E / S de criptografía, red o disco. Y estaba usando Xoshiro256 ** prng, math/rand era aproximadamente 2 veces más lento, lo que, por supuesto, está completamente fuera de lugar. El punto es que el restaurador tiene que procesar blobs en múltiples subprocesos para saturar la red 10G, la E / S de red multiproceso por sí sola no es suficiente.

Y solo por diversión, Rust impl similar genera 10GiB de bytes aleatorios en 3.1 segundos y Java en 10.77s. Imagínate :-)

Prueba interesante!

Entiendo que la tasa de restic será limitada por la cantidad de tiempo que lleva restaurar el archivo más grande, actualmente.

En este momento, sin embargo, ese no es nuestro bloqueador, ya que sé que restic puede restaurar un solo archivo mucho más rápido que los 160mbit / seg que vemos aquí.

Reuniré un repositorio de prueba de 100 GB que consta de archivos de 10 MB en SSD rápido y en S3 y ejecutaré algunos números para obtener el mejor escenario actual en el maestro y en esta rama.

Hola a todos, ¿hay alguna forma de cambiar el número de trabajadores usando un parámetro o tiene que hacerse directamente en el código? También estamos teniendo el problema de las restauraciones lentas y me gustaría mejorar lo que tenemos de alguna manera ... ¡Por favor, avíseme si puedo contribuir con pruebas para ayudar a mejorar esta parte!

¡Gracias!

@robvalca ¿qué backend usas? ¿Qué tan rápido copia rclone su repositorio en el sistema de destino? ¿Qué es la velocidad de restauración restic?

En este momento no estoy seguro de lo que está pasando, por lo que sería realmente útil si pudiera proporcionar un repositorio de prueba y los pasos que puedo usar para reproducir el problema localmente (y por "repositorio de prueba" me refiero a datos basura / aleatorios, no privados datos por favor).

@ifedorenko estamos usando S3 (ceph + radosgw) como backend (administrado por nosotros). Intenté copiar el repositorio usando rclone y estos son los resultados:

rclone copy -P remoto: cboxback-aabbcc / / var / tmp / restic / aabbcc /
Transferido: 127.309G / 127.309 GBytes, 100%, 45.419 MBytes / s, ETA 0s
Errores: 0
Controles: 0/0, -
Transferido: 25435/25435, 100%
Tiempo transcurrido: 47 min 50,2 s

La restauración del repositorio utilizando "stock" restic 0.9.4 tomó ~ 8 horas. En ambos casos, estoy usando 32 conexiones S3 y el mismo host de destino. He puesto un poco más de información en este hilo del foro.

Prepararé un repositorio para que lo pruebes y te avisaré cuando esté listo,
¡Muchas gracias por su ayuda!

@robvalca, ¿puedes intentar restaurar usando mi rama de restauración fuera de orden ? Se supone que la rama mejora el rendimiento de restauración de archivos muy grandes, que parece ser el problema al que se enfrenta.

Si la rama no mejora el rendimiento de restauración para usted, cargue el repositorio de prueba en un depósito s3 público y publique el nombre del depósito y la contraseña del repositorio aquí.

@pmkane ¿ es posible que restaure una gran cantidad de archivos idénticos o casi idénticos? eso explicaría la contención entre los trabajadores, creo.

Editar: en realidad, ¿puede volver a intentar restaurar la prueba de rendimiento con el último # 2101? Ahora debería manejar mejor las escrituras simultáneas en el mismo archivo y el mismo blob en varios archivos.

@ifedorenko de hecho, ¡con la versión fuera de orden ahora es mucho mejor! Me tomó menos de una hora, lo que está más cerca de lo que tengo con rclone. Algunos comentarios que podría extraer de mis pruebas, así que tal vez pueda encontrarlos útiles (¡vea también los gráficos adjuntos!):

  • En el restic 0.9.4 normal, el proceso comienza más rápido, con picos de 200MB/sec y estamos obteniendo casi 50 requests por segundo en el lado S3. Después de solo un par de minutos, ocurre la degradación y las solicitudes bajan a 1 más o menos y la velocidad ~ 5MB/sec durante el resto del proceso.
  • Con la versión "ooo", la velocidad de transferencia es algo así como 40MB/sec y ~ 8 S3 solicitudes constantes durante todo el proceso.
  • Otra cosa que he notado es que no veo casi ninguna mejora al aumentar las conexiones S3, ¿es esto esperado?

32 conexiones:

Created 2197 directories, listed 171.141 GiB in 20930 files
Restored 171.136 GiB in 170258 files

real    57m54.588s
user    229m25.229s
sys 6m51.763s

64 contactos

real    53m13.876s
user    242m57.081s
sys 7m12.455s
  • Finalmente hice una prueba con otro repositorio diferente (51G, 1.3M archivos pequeños, muchos duplicados) y aún es más rápido que 0.9.4 por un buen margen:

0.9.4

real    16m6.966s
user    25m4.116s
sys 4m19.424s

0.9.4-ooo:

real    8m14.375s
user    14m30.107s
sys 3m41.538s

¡¡Entonces no solo está mejorando con archivos grandes, también mejora todos los casos !!

¡Y por cierto, la nueva vista de progreso de la restauración es agradable! 8)

Avísame si quieres que haga otras pruebas.

¡Gracias!

restic_restore_full

restic_restore_ooo

Gracias por los comentarios, @robvalca , es muy útil.

  • Otra cosa que he notado es que no veo casi ninguna mejora al aumentar las conexiones S3, ¿es esto esperado?

Lo siento, olvidé mencionar que necesita cambiar el código para aumentar el número de trabajadores de restauración simultáneos. Está codificado en 8 en este momento:
https://github.com/ifedorenko/restic/blob/099f51c01c189a84b96be86ce6be61a45e3705fc/internal/restorer/filerestorer.go#L22

Avísame si quieres que haga otras pruebas.

Todavía no sabemos qué está causando la aparente contención de los trabajadores durante la restauración fuera de servicio mencionada anteriormente en este número https://github.com/restic/restic/issues/2074#issuecomment -443759511. ¿Puedes probar este compromiso específico?
https://github.com/ifedorenko/restic/commit/d410668ce3a8c7284d86a2b06bf42a0e654d43bc? Si observa la disputa con sus repositorios, eso significaría que no es específica de los datos de pmkane y que mis cambios recientes solucionan la disputa.

Gracias de nuevo por tu ayuda.

Hola a todos, sigo monitoreando esto, pero estoy absolutamente abrumado. Me pondré al día este fin de semana y veré si todavía podemos reproducir con ifedorenko @ d410668. Nuestros datos no son idénticos / casi idénticos, pero en caso de que importe, muchos de ellos están comprimidos.

@ifedorenko Gracias, con 32 trabajadores el proceso es mucho más rápido bajando a 30 minutos, lo cual es un gran resultado. También intenté aumentar las conexiones de trabajadores / s3 a 64/64, 128/128 pero no veo mejoras, obteniendo casi los mismos resultados. De todos modos, estoy contento con los resultados actuales.

Probé también la versión con https://github.com/ifedorenko/restic/commit/d410668 que me señaló y aquí hay una captura de pantalla del rastro. No tengo mucha experiencia con este tipo de herramientas, pero parece similar a los resultados de @pmkane . Lo he ejecutado con 8 trabajadores y con -o s3.connections=32

restic_trace

@robvalca entonces ifedorenko @ d410668 fue significativamente más lento en comparación con el jefe de la rama, ¿verdad? esta es una buena noticia, significa que probablemente hemos abordado todos los problemas conocidos. gracias por la actualizacion.

@ifedorenko no, se me olvidó mencionar, el desempeño es más o menos igual que el jefe de la sucursal (fuera de servicio) con el mismo número de trabajadores (8) y conexiones S3. (32). Ambos tomaron ~ 55 m, que está en línea con el tiempo para transferir el repositorio con rclone (~ 47 m)

Avísame si quieres que pruebe con otros parámetros;)

Encontré el desencadenante de problemas de rendimiento en mi caso de uso. El rendimiento de restauración para archivos grandes no es lineal más allá de un determinado tamaño de archivo.

Para probar, creé un nuevo repositorio en S3 y luego hice una copia de seguridad de 6 archivos que contenían datos aleatorios en el repositorio. Los archivos tenían un tamaño de 1, 5, 10, 20, 40 y 80 GB.

Al igual que con las pruebas anteriores, las pruebas se ejecutaron en instancias i3.8xlarge y las copias de seguridad y las restauraciones se realizaron en SSD veloces y seccionados.

Los tiempos de respaldo fueron lineales, como se esperaba (8, 25, 46, 92, 177 y 345 segundos).

Los tiempos de restauración, sin embargo, no fueron:

1 GB, 5 segundos
5 GB, 17 segundos
10 GB, 33 s
20 gb, 85 s
40 GB, 256 s
80 GB, 807 s

Entonces, algo extraño está sucediendo con archivos grandes y restaurar el rendimiento.

El depósito se denomina pmk-large-restic-test y el depósito y su contenido son públicos. Está en us-west-1 y la contraseña del repositorio restic es contraseña

Los ID de instantánea de los archivos son:

1 gb: 0154ae25
5gb: 3013e883
10 gb: 7463efa8
20 gb: 292650c6
40 gb: 5acb4bee
80 gb: d1b7e323

¡Avíseme si hay más datos que pueda proporcionar!

@pmkane, ¿ puede confirmar que utilizó el último encabezado de https://github.com/ifedorenko/restic/tree/out-order-restore branch (https://github.com/ifedorenko/restic/commit/ead78b375f2efed6de57c99b6766edbe9322e009 para ser específico) ?

Sí, lo hice. Perdón por no mencionar eso.

(se utilizaron 32 trabajadores y 32 conexiones s3 en todas las ejecuciones con ead78b3)

¿Sabes si necesito hacer algo especial para acceder a ese depósito? Nunca usé depósitos públicos antes, así que no estoy seguro de si estoy haciendo algo mal o si el usuario no tiene acceso. (Puedo acceder a los depósitos de mi equipo sin problemas, así que sé que mi sistema puede acceder a s3 en general)

Hola @ifedorenko ,

Lo siento, apliqué una política de depósito público, pero no actualicé los objetos del depósito en sí. Debería poder acceder a él ahora. Tenga en cuenta que deberá usar --no-lock, ya que solo he otorgado permisos de lectura.

Sí. Puedo acceder al repositorio ahora. Jugaré con él más tarde esta noche.

Y en caso de que sea útil / más fácil de probar, vemos características de rendimiento similares al realizar restauraciones de los mismos archivos hacia / desde un repositorio en SSD rápido, lo que saca a S3 de la ecuación.

@pmkane Puedo reproducir el problema localmente y ya no necesito acceso a ese depósito. esto fue muy útil, gracias.

@ifedorenko , fantástico. Eliminaré el cubo.

@pmkane, por favor, intentar la última rama de restauración fuera de orden cuando tenga tiempo. No tuve tiempo de probar esto en ec2, pero la restauración de mi macbook parece estar limitada por la velocidad de escritura del disco y ahora coincide con rclone.

@ifedorenko , eso suena muy prometedor. Estoy haciendo una prueba ahora.

@ifedorenko , bingo.

Se restauraron 133 GB de blobs que representan una combinación de tamaños de archivo, el más grande de 78 GB, en poco menos de 16 minutos. Anteriormente, esta restauración habría tomado la mayor parte de un día. Sospecho que podemos conseguir esto más rápido aún jugando con la cantidad de restoreWorkers, pero es bastante rápido tal como está.

¡Gracias por tu arduo trabajo en esto!

Y para la posteridad: nuestro rendimiento de restauración se duplica de 8-> 16 y nuevamente de 16-> 32 trabajadores de restauración. 32-> 64 solo es bueno para un aumento de ~ 50% en la parte superior de 32, momento en el que estamos restaurando a alrededor de 3gbit / seg. Casi a la par con rclone.

Sé que existe el deseo de minimizar la cantidad de configuración requerida para extraer el mejor rendimiento de restic, pero este es un salto lo suficientemente grande, especialmente para usuarios con conjuntos de archivos grandes, que sería bueno poder especificar el número de trabajadores en tiempo de ejecución.

No estoy seguro de por qué la restauración aún no puede obtener la máxima velocidad de cable. Hay una verificación de hash de blob redundante que puede comentar para ver si es responsable.

Lo probaré.

Hola a todos, Ejecuté algunas pruebas con la última solicitud de extracción n. ° 2195 y el rendimiento continúa mejorando.

(20k archivos pequeños, 2x70G archivos, 170G en total)

8w_32c

real    27m46.185s
user    24m31.290s
sys 3m55.153s

32w_32c

real    15m30.904s
user    24m1.982s
sys 4m55.128s

64w_32c

real    18m37.566s
user    23m33.684s
sys 5m3.024s

64w_64c

real    17m12.314s
user    23m44.318s
sys 4m43.090s

No estoy seguro de la caída del rendimiento de 32w a 64w (probado varias veces y parece legítimo). Adjunto algunas gráficas durante el proceso, parece que hay alguna degradación o límite, ¿debería ser así? Por ejemplo, con 64 trabajadores, el proceso comienza a 6gbit / seg, pero luego cae a menos de 1gbit / seg hasta el final del proceso (que creo que corresponde al tiempo para procesar esos archivos grandes). La primera captura de pantalla es con 32w, 32c y la segunda con 64w, 32c.

También estoy de acuerdo con @pmkane , sería útil cambiar el número de trabajador desde la línea de comando. Sería muy útil para escenarios de recuperación de desastres cuando desee restaurar sus datos lo más rápido posible. Hay una solicitud de extracción sobre esto por parte de mi compañero de trabajo # 2178

De todos modos, estoy realmente impresionado con las mejoras realizadas. muchas gracias @ifedorenko

restic_restore_32w_32c

restic_restore_64w_32c

++. Gracias @ifedorenko , esto es algo que cambia el juego para restic.

Gracias por el informe detallado @robvalca. ¿Alguna posibilidad de que pueda proporcionar un repositorio de prueba que pueda en AWS (o GCP o Azure) o localmente? No vi una caída en la velocidad de restauración de archivos grandes en mis pruebas y me gustaría entender qué está sucediendo allí.

@pmkane A mí también me gustaría configurar estas cosas en tiempo de ejecución . Mi sugerencia fue convertirlas en opciones --option para que no abarroten las banderas o comandos habituales, pero que estén disponibles para usuarios 'avanzados' que quieran experimentar o sintonizar su situación inusual. Ni siquiera necesitan estar documentados y pueden recibir nombres que dejen en claro que no puede contar con ellos, como --option experimental.fooCount=32 .

hola @ifedorenko , he creado un repositorio público con datos basura en s3.cern.ch/restic-testrepo . Tiene más o menos la misma forma que la que estaba probando (muchos archivos pequeños y algunos muy grandes) y también pude reproducir el mismo comportamiento en este (gráfico adjunto). La contraseña para el repositorio es restic . Avísame si tienes algún problema para acceder a él.

image

@robvalca No puedo reproducir el problema usando su repositorio de prueba. En AWS (us-east-2, s3 repo, i3.4xlarge 2x nvme raid0 target) veo una velocidad de restauración constante de 0,68 GB / s cuando utilizo 32 trabajadores y 32 conexiones (tiempo total de restauración 6 min 20 s). Su sistema de destino no puede soportar 10GB / s durante mucho tiempo, si tuviera que adivinar, al menos eso es lo que comprobaría primero si tuviera que solucionar este problema.

@pmkane , curiosamente, tampoco puedo confirmar tus observaciones. Como mencioné anteriormente, veo una velocidad de restauración de 0,68 GB / s usando la última rama out-of-order-restore-no-progress (la restauración parecía vinculada a la CPU), y 0,81 GB / s si desactivo la comprobación de hash de blob redundante (la restauración no parecía CPU- ligado). No sé cuánto más rápido puede ir una red de "hasta 10 Gbps", pero creo que ya estamos en territorio de "rendimientos decrecientes".

@ifedorenko Estoy totalmente de acuerdo con respecto a: rendimientos decrecientes. Es lo suficientemente rápido para nosotros tal como está.

@ifedorenko interesante, investigaré esto a nuestro lado. De todos modos, también es lo suficientemente rápido para nosotros, muchas gracias por tu esfuerzo.

Curiosidad por el estado de conseguir este fusionaron en. Esta rama, combinada con el trabajo @cbane 's en la velocidad de ciruela pasa hacia arriba, hacer utilizable restic extremadamente grandes para las copias de seguridad.

Pronto ... 👀

Cerrando esto ahora que # 2195 se ha fusionado. No dude en volver a abrirlo si no se han resuelto los detalles de los que trata este problema. Si aún quedan mejoras por hacer que no sean del tipo que se describe en este número, abra un nuevo número. ¡Gracias!

¿Fue útil esta página
0 / 5 - 0 calificaciones