(LIOs vs PIOs) & Hit Ratio

Al estar haciendo el post de ¿Cómo interpretar la salida de un trace? que se relaciona con el de ¿Cómo realizar un trace?, se me ocurrió el hablar un poco de este interesante tema. ¿Qué es un LIO? ¿un PIO? y ¿cómo nos afectan y se relacionan con el famosísimo y no siempre bien ponderado Hit Ratio? Así, decidí escribir este post, espero que les guste y sea de utilidad.

Primero, vamos a definir los términos involucrados en este post:

LIO

Es el Logical I/O o buffer gets o consistent reads o consistent gets como se les conoce en distintos lugares. Son las lecturas medidas en bloques de base de datos, que se hacen al área de memoria dentro del SGA llamada buffer cache. Esta área está determinada por el parámetro db_cache_size:

SQL> show parameter db_cache_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- -----------------
db_cache_size                        big integer 200M

En ésta área, Oracle guarda los registros más comúnmente consultados de las tablas. Si la tabla es pequeña, es fácil que se localice toda la tabla en memoria. Si es grande esto ya no será tan fácil.

PIO

Es el Physical I/O o physical reads o physical writes. Son las lecturas y/o las escrituras que se hacen al disco medido también en bloques de la base de datos. En el caso de una consulta que trata de traer información de una tabla, siempre un PIO será un hijo o causado por un LIO. Es decir, al consultar un bloque en el buffer cache, si no fue encontrado, entonces lo busca en el disco. Así, puntualizando: un PIO siempre es causado por un LIO y un LIO puede no tener PIOs.

Hit Ratio

Oficialmente, el Hit Ratio está definido por la fórmula:

hit ratio = (LIOs - PIOs - hit misses) / LIOs

Básicamente, es el porcentaje de información encontrada en memoria al realizar una consulta. Si toda una tabla se encuentra localizada en memoria, el hit ratio de una consulta hacia la misma, será del 100%.

El porcentaje comenzará a disminuir conforme más PIOs se tengan que realizar por no encontrar la información en memoria. Por ejemplo en un Full Table Scan.

Acerca de LIOs, PIOs y Hit Ratio

He leído y oído, que mucha gente se basa ciegamente en el hit ratio para realizar sus consultas, buscando que este sea el mayor. Incluso, si ven una consulta con un hit ratio bajo, automáticamente la catalogan como una mala consulta. Esto no siempre es así.

Si buscamos algo como lo que menciono en el párrafo anterior: incrementar a fuerza el hit ratio, ¿Cómo lo podemos lograr?

Simplemente, incrementando el tamaño del buffer cache. Pero, esto no siempre va a ser posible por alguna limitación física de memoria o que las tablas consultadas estén muy grandes. En un cliente vi una tabla que crecía 1,000 millones de registros al mes; y guardaban 18 meses de historia, es decir, 18,000 millones de registros. Creo que aquí sería un poco imposible tener toda la tabla en memoria para lograr un hit ratio al 100%, ¿no lo creen?.

Entonces, ¿cuál es la mejor aproximación en este aspecto? ¿Cual es el verdadero camino a seguir? La respuesta aunque un tanto simple, no siempre es la opción más seguida:

Disminuir los LIOs

Al respecto, podemos ver un documento que realizó Cary Millsap en su momento como parte de Hotsos, acerca de este tema. El documento en PDF lo pueden bajar de la siguiente liga:

Cary Millsap – Why you should focus on LIOs instead of PIOs

Entonces, ¿cómo le hago para disminuir los LIOs? Definitivamente se tienen que usar las armas para realizar un Performance Tuning para poder discernir una mejor forma de consultar información a la base de datos. Por ejemplo:

  • Planes de ejecución
  • Índices
  • Distribución de la información en las tablas involucradas
  • Estadísticas
  • Histogramas
  • Como último recurso (una vez agotado todo lo demás): Uso de hints

Por mencionar un ejemplo, en una ocasión me tocó ver una consulta hacia la BD que realizaba unas lecturas como Full Table Scan a diversas tablas de cien-miles de registros y todo para regresar un sólo valor. En ese caso, se tenía una cantidad impresionante de LIOs que causaban muchos PIOs.

Para resolver dicha consulta, se optó por el método de “divide y vencerás”, separando cosas que podían hacerse de manera independiente ahorrando una considerable cantidad de LIOs. Estos se incrementaban porque para cada registro de una tabla se hacía el Full Table Scan a otra tabla. Al reducir los LIOs, se redujeron los PIOs.

Conclusiones

Ya sabemos que los PIOs son causados por los LIOs; por lo tanto, si nos enfocamos en disminuir los segundos estaremos por ende disminuyendo los primeros.

Al realizar esto, estaremos creando aplicaciones más eficientes que estarán causando que también se tenga un mejor hit ratio al tener menor cantidad de información común en el buffer cache, alcanzando la misma para garantizar el rápido acceso a la información.

Si la información de este post te ha sido de utilidad o quieres que agregue algo más, deja por favor un comentario, contestaré a la brevedad.

Anuncios

2 Responses to (LIOs vs PIOs) & Hit Ratio

  1. Pingback: ¿Cómo interpretar la salida de un trace? « Orlando Olguín Olvera

  2. Pingback: ¿Cómo interpretar la salida de un trace? | Orlando Olguín Olvera

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: