Resulta que tenemos preparada una maqueta con Oracle 10g RAC de dos VMs con Linux Red Hat 4 U4 para pruebas/tests y desde hace tiempo se quejaban de que iba lenta. Despues de determinar que efectivemente iba lenta, mirando las graficas de la VM se veia que todo era normal: Un relativo uso de CPU alto, disco normal, red normal, etc, etc... Por supuesto los DBAs echaban la culpa al disco (sin saber bien lo que es un vmdk o las capas de abstraccion, caches etc, que tiene desde los discos en RAID5 de una cabina hasta el disco en vmdk....), o a que estaba virtualizado y claro era mas lento por eso...
Despues de descartar una por una las ocurrencias de los DBAs y de probar a cambiar la VM de discos(locales/SAN), de host y probar los polvos magicos, me meti en arena y sacamos unas cuantas cosas (todas en relacion con Oracle):
Indices de base de datos no creados, discos en RAID1 de software realizado por ASM de Oracle... etc, y una vez que teniamos la base de datos mas relajada decidi ver cuanta CPU consumía la VM cuando estaba parada. Fue una sorpresa ver como los scripts de Oracle de administracion, de recogida de estadisticas y en concreto el CRS estaban comiendo CPU aun a pesar de que la DB estaba apagada.
Pues bien, parece ser que uno de estos procesos, en concreto el CRS, realiza chequeos cada cierto tiempo y ello provoca consumo de CPU(se solapan chequeos y se va engordando el consumo, etc...).
Por lo que he podido ver ocurre sólo en entornos de Oracle 10g RAC virtualizado.
He aqui un link http://www.oracloid.com/2007/10/crs-eating-cpu-on-vmware/ que nos dio la solucion.
En la grafica se puede ver el bajon de CPU que se produce al cambiar un SLEEP 1 por un SLEEP 35. L averdad es que no es la primera vez que he observado que en VMware (esto es solo una impresion) con VMs linux, los scripts(perl, shell, compilaciones...) no van todo lo bien que van en fisico....
Suscribirse a:
Enviar comentarios (Atom)
No hay comentarios:
Publicar un comentario