44 votos

Solución de problemas de los picos de latencia en ESXi NFS almacenes de datos

Estoy experimentando fsync de las latencias de alrededor de cinco segundos en NFS almacenes de datos en ESXi, desencadenada por ciertos VMs. Sospecho que esto podría ser causado por VMs con NCQ/TCQ, como esto no ocurre con el virtual IDE.

Esto se puede reproducir mediante el uso de fsync-tester (por Ted ts'o) y ioping. Por ejemplo, utilizando un Grml sistema en vivo con una de 8GB de disco:

Linux 2.6.33-grml64:
root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 5.0391
fsync time: 5.0438
fsync time: 5.0300
fsync time: 0.0231
fsync time: 0.0243
fsync time: 5.0382
fsync time: 5.0400
[... goes on like this ...]

Que es de 5 segundos, no milisegundos. Esta es, incluso, la creación de IO-latencias en diferentes VM que se ejecutan en el mismo host y almacén de datos:

root@grml /mnt/sda/ioping-0.5 # ./ioping -i 0.3 -p 20 .
4096 bytes from . (reiserfs /dev/sda): request=1 time=7.2 ms
4096 bytes from . (reiserfs /dev/sda): request=2 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=3 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=4 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=5 time=4809.0 ms
4096 bytes from . (reiserfs /dev/sda): request=6 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=7 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=8 time=1.1 ms
4096 bytes from . (reiserfs /dev/sda): request=9 time=1.3 ms
4096 bytes from . (reiserfs /dev/sda): request=10 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=11 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=12 time=4950.0 ms

Cuando muevo el primer VM para el almacenamiento local se ve perfectamente normal:

root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 0.0191
fsync time: 0.0201
fsync time: 0.0203
fsync time: 0.0206
fsync time: 0.0192
fsync time: 0.0231
fsync time: 0.0201
[... tried that for one hour: no spike ...]

Cosas que he probado que no hizo ninguna diferencia:

  • Probado varios ESXi Construye: 381591, 348481, 260247
  • Probado en un hardware diferente, diferente de Intel y AMD cajas
  • Prueba con distintos servidores NFS, todos muestran el mismo comportamiento:
    • OpenIndiana b147 (ZFS de sincronización de siempre o discapacitados: no hay diferencia)
    • OpenIndiana b148 (ZFS de sincronización de siempre o discapacitados: no hay diferencia)
    • Linux 2.6.32 (sync o async: no hay diferencia)
    • No hace ninguna diferencia si el servidor NFS está en la misma máquina (virtual storage appliance) o en un host diferente

SO huésped probado, mostrando problemas:

  • Windows 7 de 64 Bits (utilizando CrystalDiskMark, los picos de latencia ocurre generalmente durante la preparación de la fase)
  • Linux 2.6.32 (fsync-tester + ioping)
  • Linux 2.6.38 (fsync-tester + ioping)

Yo no podía reproducir este problema en Linux 2.6.18 VMs.

Otra solución es utilizar virtual discos IDE (vs SCSI/SAS), pero que está limitando el rendimiento y el número de unidades por VM.

Actualización 2011-06-30:

Los picos de latencia parecen ocurrir más a menudo si la aplicación escribe en varios bloques pequeños antes de fsync. Por ejemplo fsync-tester hace (strace de salida):

pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576
fsync(3)                                = 0

ioping hace esto mientras se prepara el archivo:

[lots of pwrites]
pwrite(3, "********************************"..., 4096, 1036288) = 4096
pwrite(3, "********************************"..., 4096, 1040384) = 4096
pwrite(3, "********************************"..., 4096, 1044480) = 4096
fsync(3)                                = 0

La fase de configuración de ioping casi siempre se bloquea, mientras que fsync-tester a veces funciona bien. Es alguien capaz de actualizar fsync-tester para escribir varios bloques pequeños? Mi C habilidades de chupar ;)

Actualización 2011-07-02:

Este problema no ocurre con iSCSI. He intentado esto con el OpenIndiana COMSTAR iSCSI servidor. Pero iSCSI no le da el acceso fácil a los archivos VMDK así que usted puede moverlos entre los hosts con las instantáneas y rsync.

Actualización 2011-07-06:

Esto es parte de una captura de wireshark, capturado por una tercera máquina virtual en el mismo vSwitch. Todo esto ocurre en el mismo host, no hay red física de los involucrados.

He empezado a ioping alrededor de la hora 20. No hubo paquetes enviados hasta los cinco segundos de retraso:

No.  Time        Source                Destination           Protocol Info
1082 16.164096   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1085), FH:0x3eb56466 Offset:0 Len:84 FILE_SYNC
1083 16.164112   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1086), FH:0x3eb56f66 Offset:0 Len:84 FILE_SYNC
1084 16.166060   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet-locate [ACK] Seq=445 Ack=1057 Win=32806 Len=0 TSV=432016 TSER=769110
1085 16.167678   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1082) Len:84 FILE_SYNC
1086 16.168280   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1083) Len:84 FILE_SYNC
1087 16.168417   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1057 Ack=773 Win=4163 Len=0 TSV=769110 TSER=432016
1088 23.163028   192.168.250.10        192.168.250.20        NFS      V3 GETATTR Call (Reply In 1089), FH:0x0bb04963
1089 23.164541   192.168.250.20        192.168.250.10        NFS      V3 GETATTR Reply (Call In 1088)  Directory mode:0777 uid:0 gid:0
1090 23.274252   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1185 Ack=889 Win=4163 Len=0 TSV=769821 TSER=432716
1091 24.924188   192.168.250.10        192.168.250.20        RPC      Continuation
1092 24.924210   192.168.250.10        192.168.250.20        RPC      Continuation
1093 24.924216   192.168.250.10        192.168.250.20        RPC      Continuation
1094 24.924225   192.168.250.10        192.168.250.20        RPC      Continuation
1095 24.924555   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet_svinfo [ACK] Seq=6893 Ack=1118613 Win=32625 Len=0 TSV=432892 TSER=769986
1096 24.924626   192.168.250.10        192.168.250.20        RPC      Continuation
1097 24.924635   192.168.250.10        192.168.250.20        RPC      Continuation
1098 24.924643   192.168.250.10        192.168.250.20        RPC      Continuation
1099 24.924649   192.168.250.10        192.168.250.20        RPC      Continuation
1100 24.924653   192.168.250.10        192.168.250.20        RPC      Continuation

2ª Actualización 2011-07-06:

Parece que hay cierta influencia de los tamaños de ventana TCP. Yo no era capaz de reproducir este problema mediante FreeNAS (basado en FreeBSD) como un servidor NFS. El wireshark captura mostró la ventana de TCP actualizaciones a 29127 bytes en intervalos regulares. No he visto con OpenIndiana, que utiliza grandes tamaños de ventana por defecto.

No puedo reproducir este problema si me configure las siguientes opciones en OpenIndiana y reiniciar el servidor NFS:

ndd -set /dev/tcp tcp_recv_hiwat 8192 # default is 128000
ndd -set /dev/tcp tcp_max_buf 1048575 # default is 1048576

Pero esto mata el rendimiento: la Escritura de /dev/zero a un archivo con dd_rescue va de 170MB/s a 80 MB/s.

Actualización 2011-07-07:

He subido este tcpdump captura (pueden ser analizados con wireshark). En este caso 192.168.250.2 es el servidor NFS (OpenIndiana b148) y 192.168.250.10 es el host ESXi.

Cosas que he probado durante esta captura:

Comenzó "ioping-w 5-i 0.2 ." en vez de 30, 5 segundo colgar en la instalación, se completó en tiempo de 40.

Comenzó "ioping-w 5-i 0.2 ." en vez de 60, 5 segundo colgar en la instalación, completado en el momento de los 70.

Comenzó "fsync-tester" en el momento de los 90, con el siguiente resultado, se detuvo en el tiempo 120:

fsync time: 0.0248
fsync time: 5.0197
fsync time: 5.0287
fsync time: 5.0242
fsync time: 5.0225
fsync time: 0.0209

2ª Actualización 2011-07-07:

Prueba otro servidor NFS VM, esta vez NexentaStor 3.0.5 edición de la comunidad: Muestra los mismos problemas.

Actualización 2011-07-31:

También puedo reproducir este problema en la nueva ESXi construir 4.1.0.433742.

11voto

dtoubelis Puntos 1852

Aquí es otro adivinar... Es su IPv6 habilitado en EXS host? Si sí, entonces intente desactivarlo? Desde mi experiencia, si la red no está configurado correctamente para IPv6 (es decir, RADV, DHCP6, DNS, DNS inversa) puede ser un problema para algunos servicios. También, asegúrese de que está desactivado en el servidor NFS.

5voto

Nick Forge Puntos 13758

Este problema parece estar solucionado en ESXi 5. He probado construir 469512 con éxito.

3voto

Ryan Puntos 819

Gracias, nfsstat se ve bien. He revisado la captura. No he encontrado nada concluyente, pero sí encontrar algo interesante. Me filtra en tcp.time_delta > 5. Lo que he encontrado en cada retraso instancia fue el inicio de una llamada RPC. No todas las nuevas llamadas RPC fueron lentos, pero todos los períodos de desaceleración se produjo en el inicio de una llamada RPC. También, a partir de la captura parece que 192.168.250.10 contiene todo el retraso. 192.168.250.2 responde de forma inmediata a todas las solicitudes.

Conclusiones:

  • Los retrasos se producen siempre en el primer paquete de una llamada RPC
  • NFS tipos de Comandos no se correlacionaron con retraso instancias
  • La fragmentación = retrasos sólo el primer paquete

Una gran Llamada de Escritura se puede dividir en 300 paquetes TCP, y sólo el primero es retrasado, pero el resto de la mosca a través de. Nunca hace el retraso se produce en la mitad. No estoy seguro de cómo el tamaño de la ventana podría afectar el principio de la conexión de manera tan drástica.

Próximos pasos: Me gustaría empezar a ajustar el NFS opciones como NFSSVC_MAXBLKSIZE hacia abajo en lugar de la ventana TCP. También, me di cuenta de que 2.6.18 funciona mientras 2.6.38 no. Sé que fue agregado el soporte para la VMXnet3 conductor durante ese intervalo de tiempo. ¿Qué controladores de NIC están utilizando en los hosts? La descarga de TCP sí/no? Alrededor de la 95second marca hay más de 500 paquetes TCP para una sola NFS llamada de Escritura. Lo que está en cargo de TCP y de la ruptura de la PDU podría ser lo del bloqueo.

1voto

Joseph Kern Puntos 7103

¿Cómo es tu mirada DNS? Es su /etc/resolv.conf correcta? El tiempo de espera predeterminado es de 5 segundos.

De man resolv.conf

timeout:n
                 sets the amount of time the  resolver  will  wait  for  a
                 response  from  a  remote name server before retrying the
                 query via a different name server.  Measured in  seconds,
                 the default is RES_TIMEOUT (currently 5, see <resolv.h>).

Trate de adjuntar timeout:3 su /etc/resolv.conf y, a continuación, ejecutar el fsync pruebas de nuevo.

1voto

zippy Puntos 1215

Agarrar a un clavo ardiendo, pero lo que Nic están utilizando en estos servidores? El Stack Overflow de los administradores de sistemas han tenido extraño problemas de red con Nic Broadcom que fue cuando cambiaron a Intel Nic: http://blog.serverfault.com/post/broadcom-die-mutha/

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: