¿Por qué Linux VM en vSphere ESXi 5.5 muestra una latencia de E / S de disco dramáticamente incrementada?

Estoy perplejo y espero que alguien más reconozca los síntomas de este problema.

Hardware: nuevo Dell T110 II, Pentium G850 de doble núcleo a 2.9 GHz, controlador SATA integrado, un nuevo disco duro cableado de 500 GB 7200 RPM dentro de la caja, otros discos dentro pero aún no montados. Sin RAID Software: nueva máquina virtual CentOS 6.5 en VMware ESXi 5.5.0 (compilación 1746018) + vSphere Client. 2.5 GB de RAM asignados. El disco es cómo CentOS ofreció configurarlo, es decir, como un volumen dentro de un grupo de volúmenes LVM, excepto que omití tener un / home separado y simplemente tengo / y / boot. CentOS está parcheado, ESXi parcheado, las últimas herramientas de VMware instaladas en la VM. No hay usuarios en el sistema, no hay servicios en ejecución, no hay archivos en el disco sino la instalación del sistema operativo. Estoy interactuando con la VM a través de la consola virtual de VM en vSphere Client.

Antes de continuar, quería comprobar que configuré las cosas de manera más o menos razonable. Ejecuté el siguiente comando como root en un shell en la VM:

for i in 1 2 3 4 5 6 7 8 9 10; do
  dd if=/dev/zero of=/test.img bs=8k count=256k conv=fdatasync
done

Es decir, solo repite el comando dd 10 veces, lo que resulta en imprimir la velocidad de transferencia cada vez. Los resultados son inquietantes. Empieza bien:

262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.451 s, 105 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.4202 s, 105 MB/s
...

pero después de 7-8 de estos, imprime

262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GG) copied, 82.9779 s, 25.9 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 84.0396 s, 25.6 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 103.42 s, 20.8 MB/s

Si espero una cantidad significativa de tiempo, digamos 30-45 minutos, y lo vuelvo a ejecutar, vuelve a 105 MB / s, y después de varias rondas (a veces algunas, a veces más de 10), cae a ~ 20- 25 MB / s nuevamente.

Basado en la búsqueda preliminar de posibles causas, en particular VMware KB 2011861 , cambié el programador de E / S de Linux para que sea " noop" en lugar del predeterminado. cat /sys/block/sda/queue/schedulermuestra que está vigente. Sin embargo, no puedo ver que haya hecho ninguna diferencia en este comportamiento.

Al trazar la latencia de disco en la interfaz de vSphere, muestra períodos de alta latencia de disco que alcanzan 1.2-1.5 segundos durante los tiempos que ddinforman el bajo rendimiento. (Y sí, las cosas dejan de responder mientras eso sucede).

¿Qué podría estar causando esto?

Estoy seguro de que no se debe al fallo del disco, porque también configuré otros dos discos como un volumen adicional en el mismo sistema. Al principio pensé que había hecho algo mal con ese volumen, pero después de comentar el volumen de / etc / fstab y reiniciar, y probar las pruebas en / como se muestra arriba, quedó claro que el problema está en otra parte. Probablemente sea un problema de configuración de ESXi, pero no tengo mucha experiencia con ESXi. Probablemente sea algo estúpido, pero después de tratar de resolver esto durante muchas horas durante varios días, no puedo encontrar el problema, así que espero que alguien pueda señalarme en la dirección correcta.

(PD: sí, sé que este combo de hardware no ganará ningún premio de velocidad como servidor, y tengo razones para usar este hardware de gama baja y ejecutar una sola VM, pero creo que ese es el punto para esta pregunta [a menos que en realidad es un problema de hardware].

APÉNDICE # 1 : Al leer otras respuestas como ésta me hizo probar a añadir oflag=directa dd. Sin embargo, no hay diferencia en el patrón de resultados: inicialmente los números son más altos para muchas rondas, luego caen a 20-25 MB / s. (Los números absolutos iniciales están en el rango de 50 MB / s).

ANEXO # 2 : Agregar sync ; echo 3 > /proc/sys/vm/drop_cachesen el ciclo no hace ninguna diferencia.

ANEXO # 3 : Para eliminar más variables, ahora ejecuto de ddtal manera que el archivo que crea es mayor que la cantidad de RAM en el sistema. El nuevo comando es dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct. Los números de rendimiento inicial con esta versión del comando son ~ 50 MB / s. Caen a 20-25 MB / s cuando las cosas van al sur.

ANEXO # 4 : Aquí está el resultado de iostat -d -m -x 1ejecutarse en otra ventana de terminal mientras el rendimiento es "bueno" y luego nuevamente cuando es "malo". (Mientras esto sucede, estoy corriendo dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct). Primero, cuando las cosas están "bien", muestra esto:

Cuando las cosas van "mal", iostat -d -m -x 1muestra esto:

APÉNDICE # 5 : Por sugerencia de @ewwhite, intenté usar tunedcon diferentes perfiles y también lo intenté iozone. En este apéndice, informo los resultados de experimentar si diferentes tunedperfiles tuvieron algún efecto sobre el ddcomportamiento descrito anteriormente. Traté de cambiar el perfil a virtual-guest, latency-performancey throughput-performance, manteniendo todo lo demás igual, reiniciar después de cada cambio, y luego cada vez que se ejecuta dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct. No afectó el comportamiento: al igual que antes, las cosas comienzan bien y muchas ejecuciones repetidas ddmuestran el mismo rendimiento, pero luego, en algún momento después de 10-40 ejecuciones, el rendimiento se reduce a la mitad. A continuación, solía iozone. Esos resultados son más extensos, por lo que los incluyo como anexo # 6 a continuación.

ANEXO # 6 : Por sugerencia de @ewwhite, instalé y solía iozoneprobar el rendimiento. Lo ejecuté bajo diferentes tunedperfiles y usé un parámetro de tamaño de archivo máximo (4G) muy grande para iozone. (La máquina virtual tiene 2.5 GB de RAM asignada, y el host tiene 4 GB en total). Estas ejecuciones de prueba tomaron bastante tiempo. FWIW, los archivos de datos sin procesar están disponibles en los enlaces a continuación. En todos los casos, el comando utilizado para producir los archivos era iozone -g 4G -Rab filename.

• Perfil latency-performance:
  • resultados en bruto: http://cl.ly/0o043W442W2r
  • Hoja de cálculo de Excel (versión OSX) con gráficos: http://cl.ly/2M3r0U2z3b22
• Perfil enterprise-storage:
  • Resultados sin procesar: http://cl.ly/333U002p2R1n
  • Hoja de cálculo de Excel (versión OSX) con gráficos: http://cl.ly/3j0T2B1l0P46

El siguiente es mi resumen.

En algunos casos, reinicié después de una ejecución anterior, en otros casos no lo hice, y simplemente volví a ejecutar iozonedespués de cambiar el perfil con tuned. Esto no pareció marcar una diferencia obvia en los resultados generales.

Los diferentes tunedperfiles no parecían (para mis ojos, sin duda, inexpertos) afectar el amplio comportamiento informado por iozone, aunque los perfiles sí afectaron ciertos detalles. Primero, como era de esperar, algunos perfiles cambiaron el umbral en el que el rendimiento disminuyó para escribir archivos muy grandes: al trazar los iozoneresultados, puede ver un acantilado a 0.5 GB para el perfil, latency-performancepero esta caída se manifiesta a 1 GB bajo el perfilenterprise-storage. Segundo, aunque todos los perfiles exhiben una variabilidad extraña para combinaciones de tamaños de archivo pequeños y tamaños de registros pequeños, el patrón preciso de variabilidad difiere entre los perfiles. En otras palabras, en los gráficos que se muestran a continuación, el patrón escarpado en el lado izquierdo existe para todos los perfiles, pero las ubicaciones de los hoyos y sus profundidades son diferentes en los diferentes perfiles. (Sin embargo, no repetí corridas de los mismos perfiles para ver si el patrón de variabilidad cambia notablemente entre corridas iozonebajo el mismo perfil, por lo que es posible que lo que parecen diferencias entre perfiles sea realmente solo una variabilidad aleatoria).

Los siguientes son gráficos de superficie de las diferentes iozonepruebas para el tunedperfil de latency-performance. Las descripciones de las pruebas se copian de la documentación para iozone.

Prueba de lectura: esta prueba mide el rendimiento de leer un archivo existente.

Prueba de escritura: esta prueba mide el rendimiento de escribir un nuevo archivo.

Lectura aleatoria: esta prueba mide el rendimiento de leer un archivo con accesos a ubicaciones aleatorias dentro del archivo.

Escritura aleatoria: esta prueba mide el rendimiento de escribir un archivo con accesos realizados a ubicaciones aleatorias dentro del archivo.

Fread: esta prueba mide el rendimiento de leer un archivo usando la función de biblioteca fread (). Esta es una rutina de biblioteca que realiza operaciones de lectura almacenadas y bloqueadas. El búfer está dentro del espacio de direcciones del usuario. Si una aplicación se leyera en transferencias de tamaño muy pequeño, entonces la funcionalidad de E / S bloqueada y bloqueada de fread () puede mejorar el rendimiento de la aplicación al reducir el número de llamadas reales al sistema operativo y aumentar el tamaño de las transferencias cuando el sistema operativo Se hacen llamadas.

Fwrite: esta prueba mide el rendimiento de escribir un archivo usando la función de biblioteca fwrite (). Esta es una rutina de biblioteca que realiza operaciones de escritura en búfer. El búfer está dentro del espacio de direcciones del usuario. Si una aplicación escribiera en transferencias de tamaño muy pequeño, entonces la funcionalidad de E / S bloqueada y bloqueada de fwrite () puede mejorar el rendimiento de la aplicación al reducir el número de llamadas reales al sistema operativo y aumentar el tamaño de las transferencias cuando el sistema operativo Se hacen llamadas. Esta prueba está escribiendo un nuevo archivo, por lo que nuevamente la sobrecarga de los metadatos se incluye en la medición.

Finalmente, durante el tiempo que iozoneestaba haciendo lo suyo, también examiné los gráficos de rendimiento para la VM en la interfaz de cliente de vSphere 5. Cambié de un lado a otro entre las parcelas en tiempo real del disco virtual y el almacén de datos. Los parámetros de trazado disponibles para el almacén de datos fueron mayores que para el disco virtual, y los gráficos de rendimiento del almacén de datos parecían reflejar lo que estaban haciendo los gráficos del disco y del disco virtual, por lo que aquí adjunto solo una instantánea del gráfico del almacén de datos tomada después de iozoneterminar (debajo del tunedperfil latency-performance) Los colores son un poco difíciles de leer, pero lo que quizás sea más notable son los agudos picos verticales en la lectura.latencia (p. ej., a las 4:25, luego nuevamente ligeramente después de las 4:30 y nuevamente entre las 4: 50-4: 55). Nota: la trama es ilegible cuando se incrusta aquí, así que también la he subido a http://cl.ly/image/0w2m1z2T1z2b

Debo admitir que no sé qué hacer con todo esto. Especialmente no entiendo los perfiles de baches extraños en las regiones de registro pequeño / tamaño de archivo pequeño de las iozoneparcelas.

¿Puedes dar el número de compilación ESXi exacto? Intente realizar pruebas nuevamente con una herramienta de análisis de rendimiento de disco especialmente diseñada como fio o iozone para obtener una línea de base real. Usar ddno es realmente productivo para esto.

En general, el programador de E / S predeterminado en EL6 no es tan bueno. Debería considerar cambiar a la fecha límite o los elevadores de E / S noop, o mejor aún, instalar el marco ajustado .

Intenta: yum install tuned tuned-utilsy tuned-adm profile virtual-guestluego prueba de nuevo.

Me encontré con el mismo problema y noté un rendimiento de disco muy lento dentro de las máquinas virtuales. Estoy usando ESXi 5.5 en un Seagate ST33000650NS.

Siguiendo este artículo de kb cambié Disk.DiskMaxIOSizeal tamaño de bloque de mis discos. En mi caso 4096.

La nota de VMware sobre esto es muy agradable, ya que puede probarlo.

Nota: Puede realizar este cambio sin reiniciar el host ESX / ESXi o sin poner el host ESX / ESXi en modo de mantenimiento.

Sé que esta pregunta es muy antigua, pero Mhucka puso tanta energía e información en su publicación que tuve que responder.

Edición n. ° 1: después de usar 4096 durante un día, volví al valor anterior 32767. Probar el IO y todo parece estar estable. Supongo que ejecutar un ESXi en un HDD normal con Disk.DiskMaxIOSizeset to 32767funcionará bien durante algunas horas o quizás días. Tal vez se necesita algo de carga de las máquinas virtuales para reducir gradualmente el rendimiento.

Intento investigar y volver más tarde ...

Intente averiguar en qué lugar de su pila de almacenamiento se producen las altas latencias:

fuente: Solución de problemas de rendimiento de almacenamiento en vSphere - Parte 1 - Conceptos básicos