Desde los últimos días tengo picos de E/S extraños en una máquina virtual.
Es 2.6.32-504.el6.x86_64 #1 SMP martes 16 de septiembre 01:56:35 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Server versión 6.6 (Santiago)
Alrededor de 50 G de memoria y 24 CPU ejecutando el nodo de datos de elasticsearch.
Detectamos tiempos de espera en las solicitudes que van a ese nodo de elasticsearch y después de inspeccionar la máquina virtual por ahora solo logramos ver que esporádicamente la E/S del disco se atasca. Usé ioping en uno de los discos de la máquina virtual.
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=1 tiempo=3,76 ms (calentamiento)
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=2 tiempo=1,17 s
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=3 tiempo=131,7 us
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=4 tiempo=282,8 us
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=5 tiempo=999,4 ms
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=6 tiempo=632,7 ms
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=7 tiempo=2,15 s (lento)
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=8 tiempo=400,2 ms
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=9 tiempo=20,0 s (lento)
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=10 tiempo=1,10 ms (rápido)
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=11 tiempo=1,30 ms (rápido)
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=12 tiempo=2,20 ms (rápido)
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=13 tiempo=2,61 ms (rápido)
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=14 tiempo=203,6 us (rápido)
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=15 tiempo=1,09 ms (rápido)
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=16 tiempo=319,3 us (rápido)
4 KiB <<< /dev/sdf1 (dispositivo de bloque 100,0 GiB): solicitud=17 tiempo=249,8 us (rápido)
Como puede ver, hubo un pico de 20 segundos en un momento dado. La máquina virtual está en vmware esxi blade. El almacén de datos está siendo utilizado por 3 máquinas virtuales más, pero ninguna de ellas muestra este tipo de problemas de latencia. Probé fsck y tune2fs y ambos no mostraron problemas en el sistema de archivos.
No había actualizaciones en la máquina virtual cuando esto empezó a suceder. Se agradece cualquier sugerencia sobre cómo depurar este problema.
editar: aquí está encima de -d información. Parece que lv está 100% ocupado y java (elasticsearch está leyendo en ese momento)
LVM | vg00-lv_data | ocupado 100% | | leer 8904 | escribe 4 | | KiB/r 11 | KiB/w4 |
| MBr/s 10,03 | MBw/s 0,00 | | promedio 21.41 | avio 1,12ms |PID TID
RDDSK WRDSK
WCANCL DSK
CMD 1/12629 -
100,3M 12K 0K 100%
Java
Respuesta1
Al final, parece que todo fue causado por elasticsearch. Excluimos el nodo del clúster y luego lo volvimos a agregar, lo que provocó que los fragmentos se reubicaran de la máquina y luego regresaran a la máquina. Por alguna extraña razón eso solucionó el problema.