Velocidades de copia masiva de archivos extremadamente bajas en recursos compartidos AFP en Yosemite

Algunos antecedentes de hardware: administro un laboratorio de gráficos 3D de aproximadamente una docena de clientes iMac que ejecutan 10.10.5 y un Mini que ejecuta Server 10.10.2 (Server.app v4.0.3 / compilación 14S350). El Mini está en una carcasa Sonnet xMac, que lo conecta a través de Thunderbolt a un controlador Areca ARC-1883X SAS RAID y una tarjeta Ethernet SmallTree P2E10G-1-T de 10 Gb. El Areca gestiona dos RAID SAS de 40 TB y la tarjeta SmallTree conecta el Mini a través de Cat6a a un conmutador NetGear ProSafe XS708E de 10 GbE. Todos los iMac están cableados a través de 1 GbE Cat6 a un conmutador HP 1810-48G, que a su vez está conectado a través de un enlace troncal de 6 Gb al conmutador NetGear.

Mis artistas se han encontrado con un problema con las copias masivas de archivos entre directorios del recurso compartido AFP en el Mini con el que trabajan. Con frecuencia procesan secuencias de cientos o miles de imágenes, y después de que estas imágenes se procesan en su carpeta de salida, deben copiarse en un segundo directorio para que trabajen nuestros compositores. La operación de copia se ARRASTRA absolutamente. Un ejemplo, de hace media hora: 861 archivos .exr, con un total de alrededor de 350 MB, tardaron alrededor de 3 horas antes de que lo elimináramos al ~75 % y, en cambio, lo hicimos desde el escritorio del servidor a través de la pantalla compartida en unos 30 segundos (pero nuestros artistas no esto docenas de veces al día y, por supuesto, no se puede dar acceso a compartir pantalla con el servidor, por lo que no es una solución). No siempre cuelgan así, pero nos encontramos con un caso así al menos una vez al día y todas las copias masivas van mucho más lentas de lo que deberían. Esto solo sucede con grandes grupos de archivos: podemos copiar un solo archivo de 300 MB entre directorios casi instantáneamente.

He hecho algunas pruebas, y esto parece ser un problema del cliente de Yosemite más que nada. Ejecuté Mountain Lion en mi propia computadora portátil e hice algunas pruebas, en 10.8 y 10.10, en wifi y ethernet por cable, y en perfiles locales y de red, ya que nuestros artistas inician sesión en cuentas de red. Algunos resultados limitados para 300 archivos .exr con un total de 133 MB:

10.8 / Wifi / Perfil local: copia de 300 elementos en 53 segundos

10.8 / Alámbrico / Perfil local: copia de 300 elementos en 47 segundos

10.10 / Con cable / Perfil local: copia de 300 elementos en 223 segundos

10.10 / Con cable / Perfil de red: copia de 300 elementos en 263 segundos

Las cuentas de red son un poco más lentas, pero la gran diferencia parece ser el cliente 10.8 frente al cliente 10.10. Nuevamente, el problema es con largas listas de archivos y no con archivos monolíticos únicos. Nuestras velocidades directas de ethernet al servidor son fantásticas: tanto en la prueba de velocidad de Blackmagic 10.8 como en la 10.10, obtengo 110 MB/seg+ de lectura y escritura en el servidor, y solo un poco más lento en Wi-Fi inalámbrico N. Esto solo se convierte en un problema cuando necesitamos copiar largas listas de archivos, lo que debemos hacer muchas veces al día.

¡CUALQUIER ayuda para descubrir qué está mal aquí sería muy apreciada! Esto nos está volviendo absolutamente locos en este punto y está acabando con la productividad. Feliz de publicar los registros solicitados o intentar cualquier ajuste del sistema sugerido. ¡Gracias!

Este es un nivel de detalle increíble. Veré si tengo alguna idea, pero me pregunto si una solicitud a AppleCare le brindaría asistencia de ingeniería para obtener registros. Si esto es reproducible entre reinicios, estarían muy interesados ​​en una regresión de velocidad como la que informa. Es posible que pueda averiguar qué sucede con TCPDUMP entre la copia receptiva y las lentas.
¡Agregue la versión Server.app en el Mini (Servidor) 10.10.2!
Server.app v4.0.3 / compilación 14S350: se agregó a la información de fondo en la parte superior.

Respuestas (1)

Así es como atacaría el problema. No es una respuesta, pero con suerte podemos reunir ideas hasta que pueda informar el éxito o al menos una forma de medir las cosas.

  1. Configure un cliente de caso de prueba sin aplicaciones de terceros ejecutándose al iniciar sesión. Reinicie ese cliente y monte el recurso compartido de red. Ejecutar sudo sysdiagnose Finderantes de iniciar una copia.
  2. Inicie un seguimiento de tcp en el adaptador de red, copiará el archivo. Si no se está conectando en0, use Información del sistema para ver el nombre BSD de la conexión de red.
  3. Una vez iniciada la traza, inicie la copia del archivo en cuestión.
  4. Después de 3 minutos (o menos si la transferencia se realiza antes), presione Control+C para finalizar la captura
  5. Ejecutar un segundo sudo sysdiagnose Finderdespués de la captura de red

Con esta lentitud de la velocidad de transferencia, algo grave está ocurriendo en la pila de la red, pero sin mirar los registros del cliente, será difícil saber con certeza qué está deteniendo la operación. También puede ejecutar un diagnóstico del sistema en el lado del servidor una vez aproximadamente al mismo tiempo que lo hace en el lado del cliente para eliminar un servidor lento como problema. Parece que tiene mucha potencia para que el almacenamiento se mueva rápidamente, pero obtener registros del lado del servidor también ayudará:

sudo sysdiagnose
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serverdiagnose

la traza es:

sudo tcpdump -i en0 -s 0 -B 524288 -w ~/Desktop/AFPslow.pcap

ingrese la descripción de la imagen aquí

Ahora creo que en realidad estamos en algo. No quiero publicar el volcado completo porque tiene 100 MB (aunque puedo publicar más detalles si lo necesita), ¡pero aproximadamente la MITAD de los paquetes fallan en su suma de verificación! No sé con certeza si eso es normal, pero no puedo imaginar que lo sea. El contenido de estos paquetes de suma de comprobación fallidos es un poco diferente, pero muchos de ellos contienen "[nombre de archivo de uno de los archivos que se copian] #com.apple.metadata:_kMDItemUserTags" en la carga útil... ¿Sugiere tal vez metadatos incorrectos?
Además, puede acortar la ventana. Es probable que mis parámetros de volcado contengan información del archivo y posiblemente claves para las credenciales. Pero filtrar el tipo de mensaje de forma masiva le mostrará el error. Intentaré reproducir esto también @infinitesunrise.