¿Existe una alternativa más rápida a cp para copiar archivos grandes (~ 20 GB)?

Soy un estudiante graduado, y el grupo en el que trabajo mantiene un clúster de Linux. Cada nodo del clúster tiene su propio disco local, pero estos discos locales son relativamente pequeños y no están equipados con copia de seguridad automática. Por lo tanto, el grupo posee un servidor de archivos con muchas TB de espacio de almacenamiento. Soy un novato relativo de Linux, por lo que no estoy seguro de cuáles son las especificaciones del servidor de archivos en términos de velocidad, capacidad de red, etc. Sé por experiencia que los discos locales son significativamente más rápidos que el servidor de archivos en términos de E / S . Alrededor de una docena de personas usan el servidor de archivos.

El uso cppara copiar un archivo de ~ 20 GB del servidor de archivos a uno de los discos locales demora aproximadamente 11.5 minutos en tiempo real en promedio (según time). Sé que esta cpoperación no es muy eficiente porque (1) timeme dice que el tiempo del sistema para tal copia es de solo ~ 45 segundos; y porque (2) cuando examino topdurante la copia, % CPU es bastante bajo (por inspección, aproximadamente 0-10% en promedio).

Usar cppara copiar el mismo archivo de ~ 20 GB de una carpeta en el disco local a otra carpeta en el mismo disco local toma menos tiempo, aproximadamente 9 minutos en tiempo real (~ 51 segundos en tiempo del sistema, según time). Entonces, aparentemente el servidor de archivos es algo más lento que el disco local, como se esperaba, pero quizás no significativamente más lento. Me sorprende que copiar de local a mismo local no sea más rápido que 9 minutos.

Necesito copiar ~ 200 archivos grandes, cada ~ 20 GB, del servidor de archivos a uno de los discos locales. Entonces, mi pregunta es: ¿Existe una alternativa más rápida cppara copiar archivos grandes en Linux? (¿O hay algún indicador dentro de cpeso que podría usar que aceleraría la copia?) Incluso si de alguna manera pudiera reducir un minuto este tiempo de copia, eso sería de gran ayuda.

Estoy seguro de que comprar discos de hardware nuevos y más rápidos, pero no tengo acceso a dichos recursos. Tampoco soy administrador del sistema, solo soy un usuario (novato), por lo que no tengo acceso a información más detallada sobre la carga que hay en los discos. Sé que, si bien alrededor de una docena de personas usan el servidor de archivos a diario, soy la única persona que usa este nodo particular / disco local.

El% de CPU debe estar bajo durante una copia. La CPU le dice al controlador de disco que "tome datos de los sectores X – Y en el búfer de memoria en Z". Luego se va y hace otra cosa (o duerme, si no hay nada más). El hardware desencadena una interrupción cuando los datos están en la memoria. Luego, la CPU tiene que copiarlo varias veces y le dice a la tarjeta de red que "transmita paquetes en las ubicaciones de memoria A, B y C". Luego vuelve a hacer otra cosa.

Estás empujando ~ 240mbps. En una LAN de gigabits, debe poder hacer al menos 800 mbps, pero:

1. Eso es compartido entre todos los que usan el servidor de archivos (y posiblemente una conexión entre conmutadores, etc.)
2. Eso está limitado por la velocidad que el servidor de archivos puede manejar la escritura, teniendo en cuenta que el ancho de banda de E / S del disco es compartido por todos los que lo usan.
3. No especificó cómo está accediendo al servidor de archivos (NFS, CIFS (Samba), AFS, etc.). Es posible que deba ajustar su montaje de red, pero en cualquier cosa que haya sido la mitad de las veces, los valores predeterminados suelen ser bastante sensatos.

Para rastrear el cuello de botella, iostat -kx 10será un comando útil. Le mostrará la utilización en sus discos duros locales. Si puede ejecutar eso en el servidor de archivos, le dirá qué tan ocupado está el servidor de archivos.

La solución general será acelerar ese cuello de botella, que por supuesto no tiene el presupuesto. Pero, hay un par de casos especiales en los que puede encontrar un enfoque más rápido:

• Si los archivos son comprimibles y tienes una CPU rápida, hacer una compresión mínima sobre la marcha podría ser más rápido. Algo así lzopo tal vez gzip --fastest.
• Si solo cambia algunos bits aquí y allá, y luego envía el archivo de regreso, solo el envío de deltas será mucho más rápido. Desafortunadamente, rsyncrealmente no ayudará aquí, ya que necesitará leer el archivo en ambos lados para encontrar el delta. En cambio, necesita algo que haga un seguimiento del delta a medida que cambia el archivo ... La mayoría de los enfoques aquí son específicos de la aplicación. Pero es posible que pueda armar algo con, por ejemplo, el mapeador de dispositivos (vea el nuevo objetivo de la era dm ) o btrfs.
• Si está copiando los mismos datos en varias máquinas, puede usar algo como udpcast para enviarlo a todas las máquinas a la vez.

Y, como notas que no eres el administrador del sistema, supongo que eso significa que tienes un administrador del sistema. O al menos alguien responsable del servidor de archivos y la red. Probablemente debería preguntarle a él / ella / ellos, deberían estar mucho más familiarizados con los detalles de su configuración. Sus administradores de sistemas deberían al menos poder decirle qué tasa de transferencia puede esperar razonablemente.

Posiblemente, esto podría ser una alternativa más rápida, y no obstruirá la red durante dos días: tome uno o dos discos USB grandes (USB 3 si lo tiene) o discos FireWire, conéctelos al servidor y copie los archivos a el disco. Lleve el disco a su máquina local. Copie los archivos a la máquina.

Su definición de eficiente es al revés. Una implementación más eficiente desperdicia menos tiempo de CPU. En la copia local, está promediando unos 74 MB / s de rendimiento (lectura + escritura), que es casi tan bueno como un disco duro.

Si tiene acceso directo SSH (o SFTP) (pregunte a su administrador de sistemas), puede usar scpcon compresión ( -C):

scp -C you@server:/path/to/yourfile .

Por supuesto, eso solo es útil si el archivo es compresible, y esto usará más tiempo de CPU, ya que usará cifrado (porque está sobre SSH) y compresión.

Lo cpmás probable es que la implementación no sea un cuello de botella. Intente observar el uso de IO a través iotopdel servidor y el nodo del clúster. Esto le dará una idea de dónde puede mejorar el rendimiento.

Otro consejo es evitar copiar los mismos datos del mismo host. Por ejemplo, si tiene un archivo 20G idéntico para distribuir desde el servidor de archivos a través de la red a todos los nodos del clúster, funcionará mucho más rápido si copia los archivos de manera punto a punto en lugar de un servidor a todos los clientes. Es un poco más complicado de implementar, pero incluso puedes intentar usar alguna línea de comando p2p como el hub de conexión directa.

Si dentro de esos archivos 20G, alguna parte es común y otras son específicas del nodo del clúster, considere dividirlo en partes comunes y específicas, y luego distribuya la parte común en forma p2p.

La naturaleza / contenido de esos archivos puede hacer alguna diferencia. Comprendí que necesita copiar 200 archivos, ~ 20 GB cada uno, de una computadora a otra, ¿es eso?

Si esos archivos son comprimibles o tienen piezas similares / idénticas, tiene dos enfoques:

• comprímalos antes de copiarlos o cree un túnel entre las computadoras con la habilitación zip habilitada. Entonces, si la red es el cuello de botella, será un poco más rápido

• si los archivos son muy similares o comparten algunos elementos de contenido común entre ellos, intente usar rsync . Pasará algún tiempo buscando lo que es común entre los archivos, y no necesitará copiarlo literalmente , porque lo reconstruirá en función de lo que es común.

editar

¿Necesitarás copiar esos archivos muchas veces? (como una copia -> use esos archivos -> cambie algo en los archivos de la computadora A -> copie los archivos nuevamente a la computadora B)

Si es así, rsync será útil, porque intentará detectar lo que es igual entre las versiones y no copiará lo que no ha cambiado.

Y un tercer método: si lo anterior es correcto (cambios en el archivo, luego copie todos los archivos nuevamente en la segunda computadora), puede intentar binary diffcambiar en la segunda computadora lo que se cambió en la primera computadora.

Veo lo siguiente aquí, el cifrado no es una buena idea, ya que podría AUMENTAR la cantidad de datos que se transferirán.

Si está copiando entre dos sistemas, entonces el cuello de botella es, por supuesto, la conexión entre los servidores.

Si está copiando localmente, observe cómo va el proceso, es de UN SOLO subproceso, por lo tanto, las utilidades estándar de Linux usan:

- for all blocks in a file
      read a block
      write a block

NO hay concurrencia a esta operación.

Para acelerar las cosas, puede usar algo como esto:

  buffer -i infile -o outfile -m size-of-shared-memory-default-1MByte

Consulte la página del comando man buffer (1) para obtener más información.

El comando buffer configura dos procesos para ejecutar el proceso de copia simultáneamente: uno para leer y el otro para escribir, y utiliza un buffer de memoria compartida para comunicar los datos entre los dos procesos. El búfer de memoria compartida es su búfer circular clásico que evita la sobrescritura de datos no escritos y la escritura de datos ya escritos. He usado este programa para cortar alrededor del 10-20% del tiempo de copia en transferencias del disco a la cinta.

¿Por qué no probar un algoritmo de propagación P2P si necesita actualizar todo su clúster al mismo tiempo?

https://github.com/lg/murder es lo que usa Twitter

Hay BTSync que puedes probar también.

Si está copiando los mismos conjuntos de archivos con frecuencia desde su computadora local al servidor con pequeños cambios aquí y allá. Puede acelerar la transferencia utilizando rsync o un DVCS (por ejemplo, hg o git).

git o hg pueden realizar un seguimiento y detectar deltas y solo transferir esos deltas. En caso de usar un git, ya que ambos lados tienen un historial completo del repositorio, descubrir el delta es muy barato.

rsync utiliza una forma de algoritmo de suma de comprobación continua para detectar deltas sin conocimiento previo de lo que hay al otro lado. Si bien rsync requiere más trabajo para calcular los deltas, no necesita almacenar todo el historial del archivo.

Es posible que desee intentar empaquetar todos los archivos en un solo archivo (no es necesario comprimirlo). En mi experiencia, copiar ese archivo es más rápido que copiar una gran cantidad de archivos individuales

Prueba bbcp . Las pruebas en nuestro entorno revelaron que cp tenía algún tipo de gobernador incorporado. Solo tenga cuidado porque cuando despega el gobernador, puede marcar su servidor y causar una interrupción. En nuestro caso, estábamos desconectando el servidor para hacer la copia, así que más rápido era mejor. Esto mejoró el tiempo de transferencia varias horas.

Asegúrese de que los archivos de destino no existan antes de copiar.

A veces es sorprendente la cantidad de tiempo que se gasta incluso copiando en el mismo host (sin red involucrada).

Vea mi respuesta a otra pregunta de CP aquí . En pocas palabras, sobrescribir un archivo existente es mucho más lento que truncarlo o desvincularlo primero, y luego copiarlo. Este último es 8 veces más rápido para un archivo de 1.2GB.