Copia lenta entre directorios NFS/CIFS en el mismo servidor

Question

Hmm... Noté algunos problemas y creo que encontré una o dos pruebas irrefutables. Pero primero haré algunas preguntas y haré suposiciones sobre sus probables respuestas. Presentaré algunos datos que al principio parecerán irrelevantes, pero prometo que valdrá la pena leerlos. Así que, por favor, espérenlo... :-)

Supongo que para raid10, tendrá cuatro unidades en total + redundantes.
Y que está utilizando el ataque automático de Linux (frente a un controlador de ataque de hardware).
También supongo que todos los puertos SATA pueden transferirse independientemente unos de otros a máxima velocidad de transferencia, bidireccionalmente, y que todos los puertos SATA tienen la misma velocidad. Es decir, si tiene un único adaptador/controlador SATA, es totalmente capaz de ejecutar todos los discos conectados a él a la velocidad nominal.
También supongo que tienes las últimas unidades y controlador SATA con especificaciones. Es decir, 6,0 Gb/s. Eso es 600 MB/seg. Para ser conservadores, supongamos que obtenemos la mitad, o 300 MB/seg.
La conexión cliente-servidor tiene una NIC limitada (a 100 MB/s), por lo que no puede estresar lo suficiente las unidades.
Para ir más rápido que la NIC, al hacer NFS a NFS, supongo que estás usando localhost, por lo que puedes ir más allá de las velocidades limitadas de la NIC (lo cual creo que dijiste que hiciste uniendo para demostrar que no es un problema). )

TEMA #1. Las tasas de transferencia reportadas incluso para las rápidas de local a local parecen bajas. Con discos tan rápidos, esperaría más de 150 MB/s. Tengo un sistema raid0 de 3 discos que solo produce 3,0 Gb/s [adaptador limitado] y puedo obtener 450 MB/s en franjas. Sus discos/controlador tienen el doble de velocidad que los míos, por lo que esperaría [debido a la división] que obtenga 300 MB/s, no solo 150 MB/s para local a local. O tal vez incluso 600 MB/s [menos la sobrecarga de FS que podría reducirlo a la mitad por el bien de la discusión]

De su información de zpool, noté que la configuración de su disco es Western Digital y es:

espejo-0
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0
espejo 1
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0

Ahora comparemos esto con la información de su iostat. Sería bueno tener información de iostat en todas las unidades para todas las pruebas, pero creo que puedo diagnosticar el problema solo con lo que usted proporcionó.
sdb y sdd están al máximo
Como has notado, esto esextraño. Yo esperaríatodoimpulsa a tener uso/estadísticas equilibradas en una incursión10. Esta es [mi] prueba irrefutable.
Combinando los dos. Las unidades al máximo son un modelo ligeramente diferente a las que no lo están. Supongo que el orden de zpool es sda/sdb sdc/sdd [pero podría invertirse]
sda/sdc son 68AX9N0
sdb/sdd son 68EUZN0

TEMA #2. De una búsqueda en Google sobre WD20EFRX + 68AX9N0 + 68EUZN0, encontré esta página:http://forums.whirlpool.net.au/archive/2197640

Parece que los accionamientos 68EUZN0 pueden aparcar la cabeza después de unos 8 segundos, mientras que el otro es más inteligente al respecto [o viceversa].

Entonces, dado el almacenamiento en caché NFS + el almacenamiento en caché FS + el almacenamiento en caché SSD, las unidades subyacentes pueden estar inactivas y estacionadas. Supongo que la capa adicional de almacenamiento en caché de NFS es lo que lo lleva al límite.

Puede probar esto variando las opciones de sincronización de FS, tal vez la sincronización sea mejor que la asíncrona. Además, si puede, volvería a ejecutar las pruebas con el almacenamiento en caché SSD desactivado. La idea es garantizar que el aparcamiento nonoocurrir y ver los resultados.

Como se menciona en la página web, existen algunas utilidades que pueden ajustar el intervalo de retraso del estacionamiento. Si esa es la opción, asegúrese de investigarla a fondo.

ACTUALIZAR:

Su problema puede verse como un problema de rendimiento a través de una red de almacenamiento y reenvío [con entrega garantizada]. Nota, estoynohablando de la NIC o equivalente.

Considere que una operación de E/S es como un paquete que contiene una solicitud (por ejemplo, lectura/escritura, buf_addr, buf_len) que se almacena en una estructura. Este paquete/estructura de solicitud se pasa entre las distintas capas de caché: NFS, ZFS, controlador de dispositivo, controlador SATA, disco duro. En cada punto, tiene una hora de llegada a la capa y una hora de salida cuando la solicitud se envía a la siguiente capa.

En este contexto, la velocidad real de transferencia del disco, cuando la transferencia realmente ocurre, es análoga a la velocidad del enlace. Cuando la mayoría de las personas consideran los discos, solo consideran la velocidad de transferencia y no cuándo se inició realmente la transferencia.

En un enrutador de red, los paquetes llegan, pero no siempre se reenvían inmediatamente, incluso si el enlace saliente está libre. Dependiendo de la política del enrutador, el enrutador puede retrasar el paquete un poco, esperando que lleguen más paquetes de otras fuentes [o de la misma fuente si es UDP], de modo que el enrutador pueda agregar los paquetes más pequeños en uno grande que pueda ser transmitirse en el enlace de salida de manera más eficiente.

Para los discos, este "retraso" podría caracterizarse por la política de caché de una capa FS determinada. En otras palabras, si una solicitud llega a una capa en el momento T, en lugar de salir de la capa en T+1 y llegar a la siguiente capa en T+1, podría salir/llegar a T+n. Una capa de caché de FS podría hacer esto, de modo que pueda buscar optimización/clasificación del orden.

El comportamiento que estás viendo es muy similar al de un socket TCP que redujo su ventana debido a la congestión.

Creo que es importante dividir las pruebas. Ahora mismo estás leyendo y escribiendo. Y no sabes cuál es el factor limitante/cuello de botella. Creo que sería útil dividir las pruebas en lectura o escritura. Un programa de referencia decente probablemente logrará esto. Lo que estoy defendiendo es una versión más sofisticada de [estos son sólo ejemplos aproximados, no los argumentos exactos a usar]:

Para escritura, tiempo dd if=/dev/zero of=/whatever_file count=64g
Para lectura, tiempo dd if=/whatever of=/dev/null count=64g

El motivo de 64 GB es que es el doble de tu RAM física y elimina los efectos del caché de bloque. Realice el comando de sincronización entre pruebas.

Aplique esto en FS local y repita en NFS.

Además, haz loleerprueba en cada uno de /dev/{sda,sdb,sdc,sdd}

Haga iostat durante estas pruebas.

Tenga en cuenta que realizar la prueba de lectura en el disco físico sin formato le brinda una línea de base/máximo de qué tan rápido puede funcionar realmente el hardware. Las lecturas sin procesar del dispositivo deben aproximarse a las capacidades máximas de las especificaciones de transferencia de sus unidades. La velocidad de escritura esperada debería ser similar para un disco duro. ¿Si no, porque no? Todos los discos deben probarse aproximadamente a la misma velocidad. Lo que busco aquí es la razón por la cual solo dos discos están al máximo en sus pruebas anteriores.

Haciendo los cálculos, con 32 GB y suponiendo una velocidad de transferencia máxima de 600 MB/seg, se necesitarían un mínimo de 50 segundos para llenar/vaciar eso. Entonces, ¿cuál es el tiempo de espera del parque?

Además, puede variar un poco las cosas reduciendo la cantidad de RAM física que permitirá el kernel a través del parámetro de arranque mem=. Pruebe algo como mem=8g para ver qué efecto tiene. También hay algunas entradas /proc que pueden ajustar la política de vaciado de caché de la capa de bloque.

Además, mis FS son ext4 y están montados con noatime. Quizás quieras considerarzfs set atime=off ...

Además, observe el registro del sistema. A veces, una unidad informa un error de detección y el sistema la reconfigura para utilizar una velocidad de transferencia más baja.

Además, eche un vistazo a los datos SMART de las unidades. ¿Ves algo inusual? Reintentos suaves excesivos en una unidad determinada (por ejemplo).

Como dije, el rendimiento del disco local es mucho menor de lo esperado. Creo que ese problema debe resolverse primero antes de abordar todo el sistema con NFS. Si todos los discos raid tuvieran una utilización equilibrada y estuvieran en el estadio, estaría menos preocupado por eso.

Mi sistema [que también tiene discos WDC] no está configurado para NFS (uso mucho rsync). Tengo algunas cosas urgentes que hacer durante los próximos 1 o 2 días. Después de eso, tendré tiempo para probarlo [yo mismo tendría curiosidad].

ACTUALIZACIÓN #2:

Buen truco para el problema del desequilibrio de ZFS. Esto ayuda a explicar mi "problema n.º 1". ÉlpodríaTambién explique la debilidad de NFS si las operaciones de reequilibrio de alguna manera confundieron a NFS con respecto a la latencia/sincronización, provocando el comportamiento de "ventana/retraso de TCP", no una probabilidad muy alta, pero de todos modos es una posibilidad.

Con las pruebas de rsync no es necesario ni deseo utilizar NFS. Si puede ingresar mediante ssh al servidor, rsyncyLos NFS son redundantes. Con NFS, simplemente use cp, etc. Para realizar rsync, vaya directamente al ZFS subyacente a través de ssh. Esto funcionará incluso sin un montaje NFS [aquí está la configuración de rsync que uso]:

exportar RSYNC_SSH="/usr/bin/ssh"
exportar SSH_NOCOMPRESS=1
rsync /dondequiera1 servidor:/zfsmount/lo que sea

Hacer este host local o vinculado puede lograr que el rendimiento sea el esperado (sin el problema del desequilibrio de ZFS). Si es así, claramente reduce el problema a NFS.sí mismo.

He examinado detenidamente algunas de las fuentes del kernel para NFS. Por lo poco que miré no me gustó lo que vi respecto a la puntualidad. NFS comenzó en los años 80, cuando los enlaces eran lentos, por lo que [todavía] tiene mucho código para intentar conservar el ancho de banda de la NIC. Es decir, sólo "comprometerse" [a] una acción cuando sea absolutamente necesario. No necesariamente lo que queremos. En mi extravagante analogía con la política del enrutador de red, la caché de NFS parecería ser la que tiene el retraso "T+n".

Recomiendo hacer todo lo posible para deshabilitar el caché de NFS y hacer que pase su solicitud a ZFS lo antes posible. Dejemos que ZFS sea el inteligente y NFS el "canal tonto". El almacenamiento en caché de NFS sólo puede ser de naturaleza genérica (por ejemplo, ni siquiera sabrá que el almacén de respaldo es un RAID o conocerá demasiado las características especiales del FS base en el que está montado). ZFS tiene un conocimiento profundo del RAID y de los discos que lo componen. Por lo tanto, la caché de ZFS puede ser mucho más inteligente en cuanto a las opciones.

Yo diría que intente hacer que NFS realice un montaje sincronizado; eso podría funcionar. Además, vi algo sobre noatime, así que activa esa opción también. Puede haber otras opciones de ajuste/montaje de NFS. Con suerte, si NFS es el sospechoso habitual, se puede reconfigurar para que funcione lo suficientemente bien.

Si, por otro lado, ninguna opción pone a NFS bajo control, ¿sería rsync sobre ssh una alternativa viable? ¿Cuál es el caso de uso real? Parece que está utilizando NFS como conducto para grandes transferencias masivas que necesitan un alto rendimiento (en comparación con [digamos] simplemente como un punto de montaje automático para los directorios de inicio de los usuarios). ¿Esto es para cosas como copia de seguridad del cliente en el servidor, etc.?

Answer 1

Hmm... Noté algunos problemas y creo que encontré una o dos pruebas irrefutables. Pero primero haré algunas preguntas y haré suposiciones sobre sus probables respuestas. Presentaré algunos datos que al principio parecerán irrelevantes, pero prometo que valdrá la pena leerlos. Así que, por favor, espérenlo... :-)

Supongo que para raid10, tendrá cuatro unidades en total + redundantes.
Y que está utilizando el ataque automático de Linux (frente a un controlador de ataque de hardware).
También supongo que todos los puertos SATA pueden transferirse independientemente unos de otros a máxima velocidad de transferencia, bidireccionalmente, y que todos los puertos SATA tienen la misma velocidad. Es decir, si tiene un único adaptador/controlador SATA, es totalmente capaz de ejecutar todos los discos conectados a él a la velocidad nominal.
También supongo que tienes las últimas unidades y controlador SATA con especificaciones. Es decir, 6,0 Gb/s. Eso es 600 MB/seg. Para ser conservadores, supongamos que obtenemos la mitad, o 300 MB/seg.
La conexión cliente-servidor tiene una NIC limitada (a 100 MB/s), por lo que no puede estresar lo suficiente las unidades.
Para ir más rápido que la NIC, al hacer NFS a NFS, supongo que estás usando localhost, por lo que puedes ir más allá de las velocidades limitadas de la NIC (lo cual creo que dijiste que hiciste uniendo para demostrar que no es un problema). )

TEMA #1. Las tasas de transferencia reportadas incluso para las rápidas de local a local parecen bajas. Con discos tan rápidos, esperaría más de 150 MB/s. Tengo un sistema raid0 de 3 discos que solo produce 3,0 Gb/s [adaptador limitado] y puedo obtener 450 MB/s en franjas. Sus discos/controlador tienen el doble de velocidad que los míos, por lo que esperaría [debido a la división] que obtenga 300 MB/s, no solo 150 MB/s para local a local. O tal vez incluso 600 MB/s [menos la sobrecarga de FS que podría reducirlo a la mitad por el bien de la discusión]

De su información de zpool, noté que la configuración de su disco es Western Digital y es:

espejo-0
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0
espejo 1
  ata-WDC_WD20EFRX-68AX9N0
  ata-WDC_WD20EFRX-68EUZN0

Ahora comparemos esto con la información de su iostat. Sería bueno tener información de iostat en todas las unidades para todas las pruebas, pero creo que puedo diagnosticar el problema solo con lo que usted proporcionó.
sdb y sdd están al máximo
Como has notado, esto esextraño. Yo esperaríatodoimpulsa a tener uso/estadísticas equilibradas en una incursión10. Esta es [mi] prueba irrefutable.
Combinando los dos. Las unidades al máximo son un modelo ligeramente diferente a las que no lo están. Supongo que el orden de zpool es sda/sdb sdc/sdd [pero podría invertirse]
sda/sdc son 68AX9N0
sdb/sdd son 68EUZN0

TEMA #2. De una búsqueda en Google sobre WD20EFRX + 68AX9N0 + 68EUZN0, encontré esta página:http://forums.whirlpool.net.au/archive/2197640

Parece que los accionamientos 68EUZN0 pueden aparcar la cabeza después de unos 8 segundos, mientras que el otro es más inteligente al respecto [o viceversa].

Entonces, dado el almacenamiento en caché NFS + el almacenamiento en caché FS + el almacenamiento en caché SSD, las unidades subyacentes pueden estar inactivas y estacionadas. Supongo que la capa adicional de almacenamiento en caché de NFS es lo que lo lleva al límite.

Puede probar esto variando las opciones de sincronización de FS, tal vez la sincronización sea mejor que la asíncrona. Además, si puede, volvería a ejecutar las pruebas con el almacenamiento en caché SSD desactivado. La idea es garantizar que el aparcamiento nonoocurrir y ver los resultados.

Como se menciona en la página web, existen algunas utilidades que pueden ajustar el intervalo de retraso del estacionamiento. Si esa es la opción, asegúrese de investigarla a fondo.

ACTUALIZAR:

Su problema puede verse como un problema de rendimiento a través de una red de almacenamiento y reenvío [con entrega garantizada]. Nota, estoynohablando de la NIC o equivalente.

Considere que una operación de E/S es como un paquete que contiene una solicitud (por ejemplo, lectura/escritura, buf_addr, buf_len) que se almacena en una estructura. Este paquete/estructura de solicitud se pasa entre las distintas capas de caché: NFS, ZFS, controlador de dispositivo, controlador SATA, disco duro. En cada punto, tiene una hora de llegada a la capa y una hora de salida cuando la solicitud se envía a la siguiente capa.

En este contexto, la velocidad real de transferencia del disco, cuando la transferencia realmente ocurre, es análoga a la velocidad del enlace. Cuando la mayoría de las personas consideran los discos, solo consideran la velocidad de transferencia y no cuándo se inició realmente la transferencia.

En un enrutador de red, los paquetes llegan, pero no siempre se reenvían inmediatamente, incluso si el enlace saliente está libre. Dependiendo de la política del enrutador, el enrutador puede retrasar el paquete un poco, esperando que lleguen más paquetes de otras fuentes [o de la misma fuente si es UDP], de modo que el enrutador pueda agregar los paquetes más pequeños en uno grande que pueda ser transmitirse en el enlace de salida de manera más eficiente.

Para los discos, este "retraso" podría caracterizarse por la política de caché de una capa FS determinada. En otras palabras, si una solicitud llega a una capa en el momento T, en lugar de salir de la capa en T+1 y llegar a la siguiente capa en T+1, podría salir/llegar a T+n. Una capa de caché de FS podría hacer esto, de modo que pueda buscar optimización/clasificación del orden.

El comportamiento que estás viendo es muy similar al de un socket TCP que redujo su ventana debido a la congestión.

Creo que es importante dividir las pruebas. Ahora mismo estás leyendo y escribiendo. Y no sabes cuál es el factor limitante/cuello de botella. Creo que sería útil dividir las pruebas en lectura o escritura. Un programa de referencia decente probablemente logrará esto. Lo que estoy defendiendo es una versión más sofisticada de [estos son sólo ejemplos aproximados, no los argumentos exactos a usar]:

Para escritura, tiempo dd if=/dev/zero of=/whatever_file count=64g
Para lectura, tiempo dd if=/whatever of=/dev/null count=64g