NFS pobre rendimiento de escritura

Tengo dos máquinas conectadas con 10 Gbit Ethernet. Deje que uno de ellos sea servidor NFS y otro sea cliente NF.

Probar la velocidad de la red a través de TCP con iperfun rendimiento de ~ 9.8 Gbit / s en ambas direcciones, por lo que la red está bien.

Prueba del rendimiento del disco del servidor NFS:

dd if=/dev/zero of=/mnt/test/rnd2 count=1000000

El resultado es ~ 150 MBytes / s, por lo que el disco funciona bien para escribir.

El servidor /etc/exportses:

/mnt/test 192.168.1.0/24(rw,no_root_squash,insecure,sync,no_subtree_check)

El cliente monta este recurso compartido en su local /mnt/testcon las siguientes opciones:

node02:~ # mount | grep nfs
192.168.1.101:/mnt/test on /mnt/test type nfs4 (rw,relatime,sync,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.102,local_lock=none,addr=192.168.1.101)

Si intento descargar un archivo grande (~ 5 Gb) en el equipo cliente desde el recurso compartido NFS, obtengo un rendimiento de ~ 130-140 MBytes / s, que está cerca del rendimiento del disco local del servidor, por lo que es satisfactorio.

Pero cuando intento cargar un archivo grande en el recurso compartido NFS, la carga comienza a ~ 1.5 Mbytes / s, aumenta lentamente hasta 18-20 Mbytes / sy deja de aumentar. A veces, el recurso compartido se "cuelga" durante un par de minutos antes de que se inicie la carga, es decir, el tráfico entre los hosts se acerca a cero y, si lo ejecuto ls /mnt/test, no vuelve durante uno o dos minutos. Luego el lscomando regresa y la carga comienza a su velocidad inicial de 1.5Mbit / s.

Cuando la velocidad de carga alcanza su máximo (18-20 Mbytes / s), ejecuto iptraf-ngy muestra ~ 190 Mbit / s de tráfico en la interfaz de red, por lo que la red no es un cuello de botella aquí, así como el HDD del servidor.

Lo que probé:

1. Configure un servidor NFS en un tercer host que estaba conectado solo con una NIC Ethernet de 100Mbit. Los resultados son analógicos: DL muestra un buen rendimiento y una utilización de red casi completa de 100Mbit, la carga no se realiza más rápido que cientos de kilobytes por segundo, dejando la utilización de la red muy baja (2.5 Mbit / s según iptraf-ng).

2. Intenté ajustar algunos parámetros de NFS:

• sync o async

• noatime

• no hard

• rsizey wsizeson máximos en mis ejemplos, así que intenté disminuirlos en varios pasos hasta 8192

3. Traté de cambiar las máquinas cliente y servidor (configurar el servidor NFS en el cliente anterior y viceversa). Además, hay seis servidores más con la misma configuración, así que intenté montarlos entre sí en diferentes variaciones. Mismo resultado.

4. MTU = 9000, MTU = 9000 y agregación de enlace 802.3ad, agregación de enlace con MTU = 1500.

5. sintonización sysctl:

node01:~ # cat /etc/sysctl.conf 
net.core.wmem_max=16777216
net.core.rmem_max=16777216
net.ipv4.tcp_rmem= 10240 873800 16777216
net.ipv4.tcp_wmem= 10240 873800 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.core.netdev_max_backlog = 5000

Mismo resultado.

6. Montar desde localhost:

node01:~ # cat /etc/exports
/mnt/test *(rw,no_root_squash,insecure,sync,no_subtree_check)
node01:~ # mount -t nfs -o sync localhost:/mnt/test /mnt/testmount/

Y aquí obtengo el mismo resultado: la descarga /mnt/testmount/es rápida, la carga /mnt/testmount/es muy lenta, no más rápido que 22 MBytes / sy hay un pequeño retraso antes de que la transferencia comience realmente. ¿Significa que la pila de red funciona sin problemas y el problema está en NFS?

Todo esto no ayudó, los resultados no diferían significativamente de la configuración predeterminada. echo 3 > /proc/sys/vm/drop_cachesfue ejecutado antes de todas las pruebas.

La MTU de todos los NICS en los 3 hosts es 1500, no se realizó un ajuste de red no estándar. El conmutador Ethernet es Dell MXL 10 / 40Gbe.

El sistema operativo es CentOS 7.

node01:/mnt/test # uname -a
Linux node01 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

¿Qué configuraciones me estoy perdiendo? ¿Cómo hacer que NFS escriba rápidamente y sin bloqueos?

Utiliza la opción de sincronización en su declaración de exportación. Esto significa que el servidor solo confirma las operaciones de escritura después de que realmente se escriben en el disco. Dado que tiene un disco giratorio (es decir, sin SSD), esto requiere en promedio al menos 1/2 revolución del disco por operación de escritura, que es la causa de la desaceleración.

Usando la configuración asíncrona, el servidor reconoce inmediatamente la operación de escritura al cliente cuando se procesa pero aún no se ha escrito en el disco. Esto es un poco más poco confiable, por ejemplo, en caso de una falla de energía cuando el cliente recibió un reconocimiento por una operación que no sucedió. Sin embargo, ofrece un gran aumento en el rendimiento de escritura.

(editar) Acabo de ver que ya probaste las opciones async vs sync. Sin embargo, estoy casi seguro de que esta es la causa de su problema de degradación del rendimiento: una vez tuve exactamente la misma indicación con una configuración idencitcal. Quizás lo pruebes de nuevo. ¿Le dio la opción asíncrona en la declaración de exportación del servidor Y en la operación de montaje en el cliente al mismo tiempo?

Puede ser un problema relacionado con el tamaño del paquete y la latencia. Intenta lo siguiente:

• Habilitar tramas gigantes (MTU> = 9000 bytes) en ambas máquinas
• use UDP o, alternativamente, aumente manualmente el tamaño de la ventana TCP en ambas máquinas

El informe respalda sus resultados.

http://veerapen.blogspot.com/2011/09/tuning-redhat-enterprise-linux-rhel-54.html

Configurar el planificador de Linux en sistemas con RAID de hardware y cambiar el valor predeterminado de [cfq] a [noop] proporciona mejoras de E / S.

Use el comando nfsstat para calcular el porcentaje de lecturas / escrituras. Establezca la proporción de caché del controlador RAID para que coincida.

Para cargas de trabajo pesadas, deberá aumentar el número de subprocesos del servidor NFS.

Configure los hilos nfs para escribir sin demora en el disco utilizando la opción no_delay.

Dígale al kernel de Linux que vacíe lo más rápido posible para que las escrituras se mantengan lo más pequeñas posible. En el kernel de Linux, la frecuencia de reescritura de páginas sucias puede controlarse mediante dos parámetros.

Para grabaciones de disco más rápidas, use la opción data = journal del sistema de archivos y evite actualizaciones en los tiempos de acceso a los archivos, lo que en sí mismo da como resultado datos adicionales escritos en el disco. Este modo es el más rápido cuando los datos deben leerse y escribirse en el disco al mismo tiempo que supera a todos los demás modos