Ok, hay un poco más en la historia de lo que implica el título.
Antecedentes y entorno: Estoy copiando varios TB de un servidor Ubuntu anterior a un servidor Windows 2012 más nuevo a través de SMB. (Técnicamente, es hardware básico, pero por aquí hay servidores). Todo el mundo está en una LAN gigabit y la caja Ubuntu más antigua tiene una interfaz vinculada. Creo que el servidor Ubuntu tiene dos tarjetas Ethernet Rosewill PCI-e 1x y el servidor Windows tiene una tarjeta Ethernet PCI Intel razonablemente buena.
La computadora de destino (el servidor de Windows) ejecuta un grupo de almacenamiento con paridad en 4 unidades de 2 TB. Está ejecutando el nuevo ReFS de Microsoft. La computadora de origen (el servidor Ubuntu) ejecuta un espejo RAID de software. Está funcionando bien EXT4.
Los dos servidores se ejecutan a través de un único conmutador gigabit. He experimentado rompiendo la conexión en la computadora fuente (Ubuntu) sin ninguna mejora.
Problema: No tengo problemas para realizar transferencias a velocidades razonables desde otras computadoras al servidor de Windows. Otras computadoras pueden almacenar entre 50 y 80 MB/s sin mucha dificultad, pero la transferencia desde ese servidor Ubuntu no supera los 20 MB/s. 4+TB a 20 MB/s lleva mucho tiempo (algo así como 2,3 días) y me pregunto qué puedo hacer para descubrir dónde está el cuello de botella.
Síntomas: La CPU en ambas computadoras es bastante mínima y ciertamente no está excesivamente ocupada. Los discos duros de ambas computadoras están activos pero no saturados, y la CPU IOwait es casi del 0% al menos en el servidor Ubuntu.
Hice un seguimiento de Wireshark durante 35 segundos (presumiblemente el tiempo suficiente para asegurarme de que todos los ACK fueran para paquetes nuevos) y noté que había bastantes cosas que no esperaba. (1) No hubo sumas de verificación para los ACK (y ALGUNOS paquetes SMB) de Windows a Ubuntu. Sin embargo, Wireshark afirma que esto puede deberse a una "descarga de suma de comprobación de IP". Ok, tengo una tarjeta bastante bonita ahí. Supongo que es posible que la tarjeta de red pueda realizar cálculos de suma de comprobación. Bien. Continuando... (2) "Segmento invisible TCP ACKed". Con este tengo un problema. El número ACK está dentro de un rango aceptable por lo que puedo decir y, a menudo, hay grandes bloques de estos mensajes. ¿Quizás Wireshark es demasiado lento?
Resumen: La velocidad de transferencia apesta (20 MB/s a través de Gigabit Ethernet) y no sé por qué. Wireshark afirma que Windows está RECONOCIENDO cosas que Ubuntu nunca envió.
Suposiciones: Mi suposición inicial es que las tarjetas Rosewill más baratas se están viendo inundadas. Mi segunda suposición es que el software tipo RAID en un extremo o en el otro se está inundando de cosas que hacer.
Respuesta1
Su brecha de rendimiento coincide con una experiencia común cuando Samba (no estoy seguro si sigue siendo el valor predeterminado; lo fue durante mucho tiempo) está configurado con el tamaño de búfer de socket de lectura y escritura predeterminado de 1024 bytes.
Solía ver esto con frecuencia en máquinas Linux y Mac. Esperemos que no siga siendo ese caso.
Hay un argumento de opción de socket en el archivo de configuración de Samba donde puede configurar el tamaño del búfer del socket de lectura y escritura. Le sugerimos que configure ambos en 8192 bytes (8 KiB). 4 u 8 KB suele ser similar, pero no lo he probado en un enlace gigabit.
Además, no espere que una única conexión TCP se beneficie de un enlace vinculado, el tráfico casi siempre pasará por uno de los enlaces; de lo contrario, terminará con muchos paquetes desordenados con los que lidiar; por lo tanto, solo espere un beneficio de equilibrio de carga cuando preste servicio a varios clientes. Incluso entonces, debe buscar los diferentes modos de enlace y saber que, al menos para el enlace "modo 4" (IEEE 802.3ad), existen básicamente dos modos hash de transmisión, que determinan a qué interfaz esclava enviar. Hay hash de capa 2 (predeterminado) y hash de capa 3. Si envía la mayor parte de sus datos a través de una puerta de enlace, el hash de capa 2 no se distribuirá bien, ya que la dirección MAC de la puerta de enlace será la misma. Considere usar la capa 3 en su lugar.
Respuesta2
Una vez tuve dos tarjetas Ethernet en una computadora Ubuntu y por alguna razón no funcionaba correctamente; parecía que ambas competían por los mismos paquetes, por lo que a veces obtenía una respuesta, otras no, dependiendo de si la otra tarjeta de red agarraba el empacado. Fue extraño. Debí haberlo configurado mal de alguna manera, pero habría pensado que simplemente habría funcionado. Por supuesto, las tarjetas tenían direcciones IP únicas.
De todos modos, sería sencillo probarlo con solo UNA tarjeta Ethernet en la máquina conectada a la red para descartarlo.