¿Por qué hay una diferencia de velocidad de escritura entre dd, cp, rsync y macOS Finder en una unidad SMB3?

Tl; dr : no podemos encontrar el motivo de la velocidad de escritura limitada de 60 MB / seg en nuestro NAS a través de SMB y AFP desde dos clientes Mac diferentes. En comparación: una vieja computadora portátil con Windows 7 en la misma red escribe 100 MB / seg.

Si lee esta pregunta por primera vez, pase a la sección Actualización 4 . rsynces la razón principal de la baja velocidad, a pesar de que no entendemos por qué (¡para un solo archivo!).

Pregunta original: Encuentre el cuello de botella de velocidad SMB3 / NAS con Mac OS 10.11.5 y superior

Probamos a través rsync --progress -a /localpath/test.file /nas/test.filede macOS y la información de copia de Windows.

El NAS es un DS713 + que ejecuta su DSM 6.0.2 actual (también probado con 5.x), con dos HGST Deskstar NAS SATA 4TB (HDN724040ALE640) en RAID1 con solo componentes de gigabit ethernet y nuevos cables de ethernet (al menos Cat5e).

Los clientes de Mac primero solo producían 20 MB / seg. Pero la aplicación de la signing_required=nocorrección (descrita aquí ) empujó la velocidad de escritura a 60 MB / seg a través de SMB2 y SMB3. AFP también entrega alrededor de 60 MB / seg. El resultado varía alrededor de 5 MB / seg dependiendo del protocolo y el cliente (Mac).

Lo que ya hemos probado:

Red

1. Rendimiento de red probado a través de iperf3. Resultado: 926 Mbit / s. Se ve bien.
2. Intento de agregación de doble enlace / interfaces de red enlazadas. Ningún cambio.
3. Aumento de MTU a 6000 y 9000. Sin cambios.
4. Comprobado todos los cables. Todo bien al menos Cat5e, en buen estado.

Discos

1. Marcado SMART Luce saludable.
2. Probado velocidad de escritura directamente en el disco con dd if=/dev/zero of=write.test bs=256M count=4con varios bsy countajustes (128/8, 512 M / 2, 1024/1). Resultado: alrededor de 120 MB / s (dependiendo del tamaño del bloque / recuento)

SMB / AFP

1. Benchmarked SMB2, SMB3 y AFP uno contra el otro. Sobre igual.
   Consulte la actualización a continuación: Se utilizó un método incorrecto para descartar la implementación SMB de macOS. SMB en Windows es más rápido, la nueva configuración SMB que viene con macOS 10.11 y 10.12 puede ser la razón.
2. Intenté ajustar la configuración de SMB, incluidas las opciones de socket (siguiendo estas instrucciones )
3. Intenté una versión diferente de la configuración de ack retrasado y rsync --sockopts=TCP_NODELAY(comentarios)

No hay cambio significativo de la velocidad de escritura. Verificamos dos veces que la configuración estaba realmente cargada y estábamos editando el smb.conf correcto .

Sistema

1. CPU vigilada y carga de RAM. Nada se agota. CPU alrededor del 20%, RAM alrededor del 25% durante la transferencia.
2. Probé el mismo NAS con DSM 5.xx en una configuración casi lista para usar. No hay software adicional instalado. Nota: Tenemos dos de estos en diferentes ubicaciones. Están sincronizados a través de CloudSync de Synology. Mismo resultado.
3. Desactivó todo lo innecesario que pudiera atraer recursos del sistema.

Creemos que esta es una configuración bastante predeterminada, sin adaptaciones sofisticadas, clientes o componentes de red. Según las métricas que Synology publica, el NAS debería realizar entre 40 MB / sa 75 MB / s más rápido. Pero simplemente no podemos encontrar el cuello de botella.

Clientes / NAS

Los clientes de Mac son un MacPro 5,1 (NIC con cable estándar, con 10.12.3 (16D32)) y un MacBookPro10,1 (adaptador de red Thunderbolt, con 10.11.6) a solo 2 m de cable del NAS, que se ejecuta sobre el mismo conmutador gigabit como el portátil con Windows en la prueba.

Tenemos dos de estos NAS en diferentes ubicaciones y los resultados son idénticos. Los segundos NAS son más o menos los valores predeterminados de fábrica (ni siquiera el software de terceros instalado). Solo dos discos formateados EXT4 RAID1 que se sincronizan con el otro NAS a través de Synology CloudSync. Hemos ido tan lejos como conectarnos directamente al NAS sin el conmutador, el mismo resultado.

Actualización importante

El método utilizado para descartar la implementación SMB de macOS / OS X era incorrecto. Lo probé a través de una máquina virtual, suponiendo que usaría su propia versión de SMB, pero obviamente el tráfico se transfiere a macOS, que se ejecuta a través de su versión de SMB.

Utilizando una computadora portátil con Windows, ahora he podido alcanzar un promedio de 100 MB / s. Indicando la implementación / actualizaciones de SMB que vienen con 10.11 y 10.12 puede causar un bajo rendimiento. Incluso si signing_requiredse establece en no.

Sería genial si alguien pudiera señalar algunas configuraciones adicionales que pueden haber cambiado con las actualizaciones y podrían afectar el rendimiento.

Actualización 2 - nuevas ideas

AndrewHenle señaló en los comentarios que debería investigar el tráfico en detalle utilizando Wireshark para obtener más información.

Por lo tanto, ejecuté sudo tcpdump -i eth0 -s 65535 -w tcpdump.dumpel NAS, mientras transfería dos archivos de prueba, uno con 512 MB y otro con 1 GB. E inspeccionó el vertedero con Wireshark.

Lo que encontré:

1. Parece que tanto OS X como Windows usan SMB2 aunque SMB3 está habilitado en el NAS (al menos según Wireshark).
2. OS X parece quedarse con la MTU . Los paquetes tienen 1514 bytes, lo que lleva a una mayor sobrecarga de red y paquetes enviados (visibles en los volcados).
3. Windows parece enviar paquetes de hasta 26334 bytes (¡si leo los datos correctamente! Por favor verifique), incluso si la MTU no debería permitir eso, ya que está configurado en 1500 en el NAS, la configuración máxima sería 9000 allí (Synology también usa la configuración 1500 en sus pruebas).
4. Intentar forzar a macOS a usar SMB3 agregando smb_neg=smb3_onlya /etc/nsmb.conf no funcionó o al menos no condujo a transferencias más rápidas.
5. Ejecutar rsync --sockopts=TCP_NODELAYcon varias combinaciones de configuraciones de confirmación retrasada de TCP (0 a 3) no tuvo ningún efecto (Nota: ejecuté tcpdump con la configuración predeterminada de confirmación de 3).

He creado 4 volcados como archivos .csv, 2 al copiar 512 MB (archivo de prueba 2.) y 2 al copiar 1024 MB (archivo de prueba). Puede descargar las exportaciones de Wireshark aquí (25.2 MB). Se comprimen para ahorrar espacio y se nombran de forma autoexplicativa.

Actualización 3 - salida smbutil

Salida de smbutil statshares -alo solicitado por harrymc en los comentarios.

==================================================================================================
SHARE                         ATTRIBUTE TYPE                VALUE
==================================================================================================
home
                              SERVER_NAME                   server-name._smb._tcp.local
                              USER_ID                       502
                              SMB_NEGOTIATE                 SMBV_NEG_SMB1_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB2_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB3_ENABLED
                              SMB_VERSION                   SMB_3.0
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              OS_X_SERVER                   TRUE
                              QUERYINFO_NOT_SUPPORTED       TRUE
                              DFS_SUPPORTED                 TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE

--------------------------------------------------------------------------------------------------

Nota sobre esto: estoy seguro de que SIGNING_SUPPORTEDestar trueaquí no significa que la configuración en la configuración no funcione. Pero solo eso es compatible con el NAS. Verifiqué tres veces que cambiar la signing_requiredconfiguración en mi configuración tiene un efecto en la velocidad de escritura (~ 20 MB / s cuando está activado, ~ 60 MB / s cuando está desactivado).

Actualización 4 - Samba Wars: una nueva esperanza

Se siente algo vergonzoso, pero el problema principal aquí, nuevamente, parece ser la medición.

Resulta que rsync --progress -acuesta unos 30 MB / s de velocidad de escritura. Escribir con ddSMB directamente y compartir time cp /local/test.file /NAS/test.filees más rápido a aproximadamente 85-90 MB / sy aparentemente la forma más rápida de copiar es el buscador de macOS a aproximadamente 100 MB / s (que también es el método más difícil de medir, ya que no hay Indicador de tiempo o velocidad: ¿quién lo necesita, verdad? Lo medimos copiando primero un archivo de 1 GB y luego un archivo de 10 GB, usando un cronómetro.

Lo que hemos intentado desde la última actualización de esta pregunta.

1. Copie del cliente Mac al cliente Mac. Ambos tienen SSD (MacPro escribe con 250 MB / s en el propio disco, MacBook Pro con 300 MB / s). Resultado: unos escasos 65 MB / s al ddescribir desde MacBook Pro a MacPro ( rsync25 MB / s). Ver los 25 MB / s fue el momento en que comenzamos a cuestionar rsync. Todavía 65 MB / s son extremadamente lentos. Entonces, la implementación de SMB en macOS parece ... bueno, cuestionable.
2. Probé diferentes configuraciones de ack con dd y cp, sin suerte.
3. Finalmente, encontramos una manera de enumerar todas las opciones nsmb.conf disponibles. Es un simple man nsmb.conf. ¡Atención, la versión en línea está desactualizada!

Así que probamos algunas configuraciones más, entre ellas:

notify_off=yes
validate_neg_off=yes
read_async_cnt=16
write_async_cnt=16
dir_cache_async_cnt=40
protocol_vers_map=4
streams=no
soft=yes

Nota: smb_neg=smb3_onlycomo ya esperaba, no es una configuración válida. protocol_vers_map=4debe ser el equivalente válido

De todos modos, ninguno de estos ajustes hizo una diferencia para nosotros.

Nuevas preguntas de un vistazo

1. ¿Por qué rsync es una forma tan costosa de copiar un (1) archivo? No hay mucho para sincronizar / comparar aquí, ¿verdad? El tcpdump tampoco indica una posible sobrecarga.

2. ¿Por qué son ddy cpmás lento que los macOS buscador cuando se transfiere a un recurso compartido SMB? Parece que al copiar con Finder hay significativamente menos confirmaciones en la comunicación TCP. (Nuevamente: la configuración de reconocimiento, por ejemplo, delayed_ack=1no hizo ninguna diferencia para nosotros).

3. ¿Por qué Windows parece ignorar la MTU, enviando paquetes TCP significativamente más grandes y, por lo tanto, menos, lo que resulta en el mejor rendimiento, en comparación con todo lo posible a través de macOS?

Así es como se ven los paquetes desde macOS (constantemente 1514)

"TCP","1514","[TCP segment of a reassembled PDU]"
"TCP","66","445  >  56932 [ACK] Seq=6603 Ack=35239 Win=4505 Len=0 TSval=520980697 TSecr=650208630"

Y esto viene de Windows (hasta 26334, que varía en tamaño)

"SMB2","1466","Write Request Len:65536 Off:196608 File: test.file"
"TCP","26334","[TCP segment of a reassembled PDU]"
"TCP","7354","[TCP segment of a reassembled PDU]"
"TCP","54","445  >  49220 [ACK] Seq=6831 Ack=267030 Win=4074 Len=0"

Puede descargar .csv completo aquí (25.2 MB), los nombres de los archivos explican lo que se ha copiado (SO, método de transferencia y tamaño del archivo).

1. pregunta similar pero tiene respuestas interesantes, puede consultar este hilo especialmente en el comentario 5: https://bugzilla.samba.org/show_bug.cgi?id=8512#c5

Aquí cita "Peter van Hooft". Aunque no estoy seguro de las pruebas basadas en qué / qué dist de Linux. y la versión de rsync también. Sin embargo: 1. nos da una idea para intentarlo - dispersar bandera si podía posible el rendimiento aumenta. 2. probó el protocolo NFS pero encontró el mismo problema de velocidad, por lo tanto, es posible que no sea la razón del protocolo (SMB2 / 3, AFP, etc.).

Usamos rsync para copiar datos de un servidor de archivos a otro usando montajes NFS3 a través de un enlace de 10 Gb. Descubrimos que aumentar el tamaño del búfer (como prueba rápida) aumenta el rendimiento. Cuando se usa --sparse esto aumenta el rendimiento con un factor de cincuenta, de 2MBps a 100MBps.

2. Aquí hay otra inspección interesante sobre el rendimiento de rsync. https://lwn.net/Articles/400489/

LWN.net tiene una conclusión de que el problema de rendimiento puede ser relevante para el núcleo, incluso el artículo publicado en 2010 y no podemos cambiarlo en NAS o MacOS. Sin embargo, este artículo nos da una idea de que el problema del núcleo puede causar la suma de comprobación cálculo de la (mi suposición)

Una cosa está clara: debería actualizar el kernel en mi sistema Mythtv. En general, los núcleos 2.6.34 y 2.6.35-rc3 ofrecen un mejor rendimiento que el antiguo núcleo 2.6.27. Pero, jugando o no, rsync todavía no puede vencer a un simple cp que copia a más de 100MiB / s. De hecho, rsync realmente necesita mucha potencia de CPU para copias locales simples. A la frecuencia más alta, cp solo necesitaba 0,34 + 20,95 segundos de tiempo de CPU, en comparación con los 70 + 55 segundos de rsync.

También los comentarios de citas tienen esto:

Tenga en cuenta que rsync siempre verifica que cada archivo transferido se haya reconstruido correctamente en el lado receptor al verificar una suma de verificación de todo el archivo que se genera a medida que se transfiere el archivo

actualización 1 : mi error, esta descripción es para --checksum. compruébelo aquí: [Mejorada la descripción de la opción --checksum.] PD, no tengo suficiente reputación para publicar más de 2 enlaces.

pero no puedo encontrar la misma descripción en la página de manual de rsync, así que supongo que alguien está hablando a continuación en negrita:

Rsync encuentra archivos que necesitan ser transferidos usando un algoritmo de "verificación rápida" (por defecto) que busca archivos que han cambiado de tamaño o en el último tiempo modificado. Cualquier cambio en los otros atributos conservados (según lo solicitado por las opciones) se realiza directamente en el archivo de destino cuando la comprobación rápida indica que no es necesario actualizar los datos del archivo.

Por lo tanto, compare con cp / tar / cat, si usamos rsync para copiar un montón de archivos pequeños o grandes, podría causar problemas de rendimiento. PERO debido a que no puedo leer el código fuente de rsync, por lo tanto, no puedo confirmar que esta sea la razón final.

mi idea es seguir revisando:

1. ¿Qué versión de rsync usa awenro para las pruebas? ¿Podría actualizar a la última versión?
2. veamos qué salida al usar --stats y -v con --debug = FLAGS

banderas

--stats Esto le dice a rsync que imprima un conjunto detallado de estadísticas sobre la transferencia de archivos, lo que le permite saber cuán efectivo es el algoritmo rsync para sus datos.

--debug = FLAGS Esta opción le permite tener un control detallado sobre la salida de depuración que desea ver. Un nombre de bandera individual puede ir seguido de un número de nivel, con 0 que significa silenciar esa salida, 1 es el nivel de salida predeterminado y los números más altos aumentan la salida de esa bandera (para aquellos que admiten niveles más altos). Use --debug = help para ver todos los nombres de banderas disponibles , lo que y qué nombres de banderas se agregan para cada aumento en el nivel detallado.

Por último, recomendaría leer esta publicación complementaria para obtener más conocimiento.
"Cómo transferir grandes cantidades de datos a través de la red" moo.nac.uci.edu/~hjm/HOWTO_move_data.html

Rsync / ssh cifra la conexión smb no, si no recuerdo mal. Si se trata solo de un archivo, un sistema podría leer ese archivo y el otro no. También tenga en cuenta que para tener una MTU superior a 1514, debe habilitar los paquetes "gigantes" / "Jumbo Frames". El hecho de que los paquetes deben reducirse aún más puede implicar que hay una sobrecarga para "volver a embalar" el paquete. La segunda cosa a tener en cuenta es que los "gigantes" / "Jumbo Frames" deben estar habilitados en ambos extremos Y TODO ENTRE.

1514 son las tramas Ethernet normales. Los marcos 6k-9k se llaman gigantes o "marcos jumbo" dependiendo del sistema operativo / aplicación

Tengo un promedio de 80 MB / s entre mi nas (una PC con VM, una de las VM es el NAS) y mi estación (una PC) con sftp (usando sshfs) [gigantes no habilitados] y el dispositivo intermedio es un microtik 2011 (funcionando chip de interruptor tru solamente)

Recuerde que la MTU se negocia entre dos puntos y que a lo largo de una ruta puede tener varias MTU a diferente capacidad y que la MTU será la más baja disponible.

editar: SMB no es muy eficiente para transferencias de archivos.