El rendimiento es un tema delicado y a veces espinoso. Por ejemplo, no basta con hacer una medida. Qué menos que hacer varias y calcular estadísticos (y ya puestos, representarlos gráficamente…)
A pesar de la delicadeza, hoy en día con el big data y la necesidad de mover grandes volúmenes de datos, no queda más remedio que optimizar como sea y donde sea.
El primer paso razonable sería conocer la infraestructura disponible.
En el caso de redes de datos, hay múltiples formas de hacerse una idea de las posibilidades de transmisión en Linux. Generalmente nos interesa la velocidad extremo a extremo con nuestros clientes, pero dicha velocidad puede verse afectada por cualquier punto intermedio. Con lo cual no siempre es fácil encontrar y/o eliminar los cuellos de botella.
De hecho, muchas veces no tenemos acceso “al otro extremo”, con lo cual el uso de herramientas como iperf (con su plétora de opciones TCP y UDP) se complica.
La primera variación fácil de observar es el rendimento de las herramientas / protocolos. En una red de área local (LAN) a 1 Gb/s se pueden alcanzar fácilmente 820 Mb/s con rsync (directo). Luego probamos con rsync sobre ssh y… ¡oh sorpresa! El rendimiento cae en picado: 270 Mb/s. ¿Será “culpa” de SSH?
Una forma simple de probar SSH “en sí” (minizando el impacto de, por ejemplo, el disco duro):
# desde h1 dd if=/dev/zero bs=4096 count=1048576 | ssh h2 "cat > /dev/null"
dd nos chiva que la velocidad fue de 330 Mb/s. El cifrado por defecto (3DES) no parece particularmente ágil. Probemos con arcfour:
# Normalmente arcfour viene de serie en sshd, si el comando se queja de "no matching cipher found", # seguramente es porque está deshabilitado en el "servidor" (ya que es rápido pero más inseguro). # Añadir una línea a sshd_config con los "cifrados" habilitados (que aparecen en el mensaje de error) + arcfour. # Por ejemplo, # Ciphers arcfour,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com dd if=/dev/zero bs=4096 count=1048576 | ssh -c arcfour h2 "cat > /dev/null"
La cosa mejora: 800 Mb/s. rsync sobre ssh arcfour:
# preparamos un sistema de ficheros sobre RAM antes de la prueba, en cada servidor, con el comando... # mount -t ramfs -o size=8G ramfs /mnt/ram/ rsync -av --progress -e "ssh -c arcfour" /mnt/ram/big-file h2:/mnt/ram/
740 Mb/s… casi 3 veces más rápido que sin opciones.
contraste, podemos usar iperf, que confiesa que disponemos de 900 Mb/s.
# TCP # Servidor, especificando puerto (-p) e IP (-B) iperf -s -p 1234 -B 192.168.22.14 # Cliente iperf -p 1234 -c 192.168.22.14 # UDP # Servidor iperf -s -u -p 1234 -B 192.168.22.14 # Cliente - objetivo 2 Gb/s iperf -p 1234 -c 192.168.22.14 -u -b 2G
Parece que el impuesto mínimo por disfrutar del cifrado que ofrece SSH son 150 Mb/s. Con el clásico netcat podemos comprobarlo:
# primero, ponemos a netcat a escuchar en h2 nc -l -p 8000 > /dev/null # luego, desde h1... dd if=/dev/zero bs=4096 count=1048576 | nc h2 8000
En efecto, dd sobre netcat va a 900 Mb/s.
Al salir del “área local” es común que los rendimientos bajen en picado, aún disfrutando de un enlace de 1 Gb/s. Un simple rsync (directo) baja a unos 90 Mb/s. Uno sospecha que quizá el otro extremo tenga una conexión de 100 Mb/s. Probemos varias descargas en paralelo, por cortesía de GNU paralel:
echo -e "file1\\nfile2\\nfile3" | parallel rsync -av --progress h3.remote.com::base_path/{} .
Parece que el otro extremo también disfruta de una buena conexión: este “rsync paralelo” fue a 260 Mb/s (aumentando el paralelismo se pudo llegar hasta 600 Mb/s). Molaría que rsync integrase de serie una opción para paralelizar las transmisiones (de momento, parece que aún no existe tal opción…). Como no siempre es práctico montarse una versión casera de este “rsync paralelo”, se hace necesario recurrir a herramientas especializadas en grandes transferencias, como puede ser GridFTP
Artículos relacionados
“Maximizing File Transfer Performance Using 10Gb Ethernet and Virtualization”
“How to optimize an UDP application for latency“, pensando en redes 10Gbps.
Herramientas
iftop
iperf
rsync
netcat
Globus GridFTP
Ejemplo de copia con bbcp en un entorno restringido (por cortafuegos y por usuario):
# -V -> transfer statistics # -Z 80 -> listen on port 80 in remote host (hence using sudo in -T) # -T '.... %I ...' -i aws_key.pem -> use a non-default keypair # -S -> run bbcp directly on local side (no ssh) bbcp -V -Z 80 -T '/usr/bin/ssh %I -l %U %H sudo /usr/local/bin/bbcp' -i aws_key.pem -S '/usr/local/bin/bbcp' SOURCE REMOTE_USER@REMOTE_HOST:REMOTE_PATH