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


8

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:

ingrese la descripción de la imagen aquí

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

ingrese la descripción de la imagen aquí

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.

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.

ingrese la descripción de la imagen aquí

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

ingrese la descripción de la imagen aquí

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

ingrese la descripción de la imagen aquí

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

ingrese la descripción de la imagen aquí

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.

ingrese la descripción de la imagen aquí

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.

ingrese la descripción de la imagen aquí

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

Gráfico de vSphere en tiempo real de VM

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.


Suponiendo que ha estado utilizando una alta utilización del disco en términos de IOPS durante un largo período de tiempo, es probable que experimente saturación del disco en algún nivel (ya sea en el nivel de la cola de escritura del disco del sistema operativo o más probablemente en el nivel del disco duro) donde tiene más solicitudes de las que su disco puede manejar en este momento. No tengo la experiencia suficiente para decirle cómo determinar si está experimentando saturación de disco, pero creo que podría ser un punto de investigación para usted.
Jason Zhu

@JasonZhu Es una buena pregunta. He estado asumiendo que debido a que el sistema no está haciendo nada más, y simplemente estoy ejecutando el mismo comando repetidamente, el nivel de uso del disco sería más o menos constante. Sin embargo, toma mucho tiempo antes de que el comportamiento se manifieste a pesar de esto. Ejecuté iostaty mostró ~ 90% de utilización tanto antes como después. Pero no soy un experto en juzgar estas cosas, tal vez la saturación está sucediendo en alguna parte. Estoy actualizando mi pregunta para mostrar la iostatsalida en caso de que sea útil.
mhucka

¿Hay alguna posibilidad de que esto se deba al almacenamiento en caché de disco ESX? ¿El disco que está probando está optimizado para rendimiento o seguridad? Además, si está optimizado para el rendimiento, ¿puede mirar la utilización de la caché ESX mientras realiza la prueba? Este cambio de E / S de escritura en el rendimiento parece que las escrituras golpean un caché y luego disminuyen a la velocidad de descarte cuando se llena.
Basil

¿Podría eso tener algo que ver con el caché de tu controlador RAID? ¿Alto IOPS / rendimiento hasta que esté lleno y luego vuelvas al rendimiento de HDD sin procesar? Solo adivinando ...
Mario Lenz

@MarioLenz Como mencioné en la descripción, esto no tiene RAID.
mhucka

Respuestas:


2

¿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.


Argh, no mencioné que realmente cambié el programador a noop. Editaré mi pregunta para decir eso. En cuanto al número de compilación, es 1746018. (Incluí eso en el segundo párrafo, pero veo que algo sucedió y se truncó; debe haber sido un accidente de edición. También lo arreglaré). marco ajustado y otras herramientas. Gracias por sus sugerencias
mhucka

Lo intenté tuned, usando el perfil virtual-guesty manteniendo todo lo demás igual (técnica experimental adecuada, evite cambiar más de una variable). No afectó el comportamiento: al igual que antes, las cosas comienzan bien, pero después de muchas ejecuciones repetidas (10-30) dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct, el rendimiento se reduce a la mitad. También probé el perfil latency-performance: el mismo resultado. Actualmente lo estoy intentando throughput-performance.
mhucka

¿Puedes probar algo que no implique ddcarreras? Quizás el fioo iozonemencionado anteriormente?
ewwhite

Voy a. Pero primero, tenía sentido repetir la misma prueba, para ver si el comportamiento cambió.
mhucka

2

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 ...


Gracias por compartir esto. Es útil saber acerca de cómo cambiar el tamaño del bloque de disco. Lamento no poder probarlo porque ya no tengo esta configuración (finalmente la abandoné y elegí CentOS en metal desnudo), pero si alguna vez vuelvo a intentar algo como esto, puedes estar seguro de que lo investigaré .
mhucka

Intenté calcular tiempos de alta latencia en mi esxi 6.5 en la máquina ProLiant 380 Gen9. Disk.DiskMaxIOSizehizo el truco para mí Estuve investigando y midiendo durante 2 semanas. Gracias por compartir.
EvanBlack

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.