Tengo un servidor CentOS 5 VMWare que se conecta a una máquina OpenSolaris 2009.06 a través de NFS que contiene las imágenes de disco. Mis máquinas virtuales parecen estar unidas por un IO lento, por lo que me gustaría hacer todo lo posible para optimizar la conexión.
No estoy seguro de la mejor manera de medir el rendimiento en un sistema de producción, pero algunas pruebas no científicas que usan dd bs=1024k count=400escrituras locales (OpenSolaris) muestran ~ 1.6GB / sy escrituras remotas (CentOS) ~ 50MB / s. Me imagino que estos son más bajos de lo que realmente estoy obteniendo ya que 7 máquinas virtuales se ejecutan actualmente a través de la conexión.
Actualmente, las 2 máquinas son gigE conectadas directamente con marcos jumbo habilitados en ambas NIC (MTU = 9000). Aparte de eso, no se han realizado optimizaciones. NFS mount / export está utilizando los valores predeterminados.
¿Dónde debo comenzar a girar las perillas para mejorar el rendimiento?
Respuestas:
Solo para aclarar, ¿está obteniendo 50 MB / seg con NFS a través de una sola conexión de Ethernet Gb?
¿Y el servidor host ejecuta CentOS con VMware Server instalado, que a su vez ejecuta las 7 VM? ¿Hay alguna razón en particular por la que haya optado por CentOS y VMware Server combinados, en lugar de VMware ESXi, que es una solución de mayor rendimiento?
Los 50 MB / seg no son geniales, pero no están muy por debajo de lo que esperarías de un solo cable de red de Gb: una vez que hayas introducido los ajustes de NFS que la gente ha mencionado anteriormente, verás quizás 70- 80MB / seg. Opciones a lo largo de la línea de:
"ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"
son probablemente razonables para usted en ambos extremos del sistema.
Para superar eso, tendrá que considerar agrupar las tarjetas de red en pares, lo que debería aumentar su rendimiento en aproximadamente un 90%. Es posible que necesite un conmutador que admita 802.3ad para obtener el mejor rendimiento con la agregación de enlaces .
Sin embargo, una cosa que sugeriría es que su rendimiento de E / S en el cuadro de OpenSolaris suena sospechosamente alto, es probable que 12 discos no admitan 1,6 GB / seg de rendimiento, y que Solaris + ZFS puede almacenar mucho en caché.
fuente
Para nuestras máquinas RHEL / CentOS 5 utilizamos las siguientes banderas de montaje
nfsvers = 3, tcp, timeo = 600, retrans = 2, rsize = 32768, wsize = 32768, hard, intr, noatime
La versión más reciente del kernel de Linux admite parámetros rsize / wsize aún más grandes, pero 32k es el máximo para el kernel 2.6.18 en EL5.
En los servidores NFS, al menos para Linux no_wdelay supuestamente ayuda si tiene un controlador de disco con BBWC. Además, si usa el indicador noatime en los clientes, probablemente tenga sentido montar los sistemas de archivos en los servidores también con noatime.
Y, como ya se mencionó, no te molestes con UDP. Con redes de mayor velocidad (1GbE +) existe una pequeña, pero no nula, posibilidad de que un número de secuencia se ajuste y cause corrupción de datos. Además, si existe la posibilidad de pérdida de paquetes, TCP funcionará mejor que UDP.
Si no le preocupa tanto la integridad de los datos, la opción de exportación "asíncrona" puede ser una mejora importante en el rendimiento (el problema con la asíncrona es que podría perder datos si el servidor falla).
Además, al menos para el servidor Linux, debe asegurarse de tener suficientes subprocesos del servidor NFS en ejecución. El valor predeterminado 8 es demasiado bajo.
fuente
Una vez hice una prueba con un dell r710, 1 cpu, 4 GB de RAM, 6 discos SATA con RAID-10. El cliente era un sun x2100, ambos con CentOS 5.3 y los parámetros nfs como se mencionó anteriormente
"ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"
montado en ambos lados con noatime.
También subí a nfsds a 256 y usé el programador noop para el controlador de incursión perc6. Otra cosa que hice fue alinear las particiones con el tamaño de banda de 64K del controlador de banda.
luego medí el rendimiento de nfs con dd: para las lecturas podría llenar el tubo gigE pero para las escrituras solo podría obtener resultados ligeramente mejores que usted. Con async habilitado pude obtener de 70 a 80 MB / s, pero async no era una opción para mi.
¿Tal vez no puedas obtener más con nfs desde un enlace gigE?
fuente
Pruebe esto: deshabilite el registro de intención de ZFS (ZIL) temporalmente en el servidor OpenSolaris NFS con los siguientes dos pasos
echo zil_disable/W0t1 | mdb -kwLuego prueba de nuevo. Puede usar zilstat para asegurarse de que realmente no haya más IO en el ZIL. Si la prueba se ejecuta más rápido, sabrá que el problema de rendimiento tiene algo que ver con el ZIL. Si todavía funciona lento, sabe que el ZIL no es el culpable y que usar un SSD para el ZIL tampoco ayudará. Consulte la Guía de ajuste de ZFS Evil para obtener más información sobre el ZIL.
Otra opción sería capturar el tráfico de red (por ejemplo, con Wireshark) y ver si hay algún problema, por ejemplo, con las tramas Jumbo. Verifique que los paquetes en el cable se vean como espera de su configuración. ¿Hay alguna mala fragmentación? ¿Hay retransmisiones?
fuente
Aumentar el tamaño de la carga útil de lectura y escritura puede ayudar. Especialmente en combinación con marcos jumbo.
Tiendo a encontrar 32k para ser óptimo.
Cambiar al transporte UDP es, por supuesto, más rápido que TCP, porque ahorra la sobrecarga del control de transmisión. Pero solo es aplicable en redes confiables y donde NFSv4 no está en uso.
fuente
El rendimiento de NFS en ZFS mejora enormemente mediante el uso de un SSD para el registro de intenciones de ZFS (ZIL), ya que esto reduce la latencia de las operaciones. Este hilo sobre VMWare NFS en el rendimiento de ZFS en las listas de correo de OpenSolaris NFS y ZFS tiene más información, incluida una herramienta de referencia para ver si el rendimiento de ZIL es el cuello de botella.
fuente
FYI, el comando dd escribirá en la memoria caché y no en el disco, esto puede obtener números locos como 1.6G / s porque está escribiendo en RAM y no en disco en Solaris, puede usar "-oflag = sync" para forzar las escrituras en el disco
fuente