¿Cómo afecta PAGEIOLATCH en SQL Server?

Seguramente viste también en tus métodos de monitoreo del servidor a un tipo de espera llamado PAGEIOLATCH. Uno de los más comunes, más fáciles de interpretar y muchas veces con una propuesta muy rápida para mejorar el performance. Al ejecutar una consulta cualquiera, veamos cómo afecta PAGEIOLATCH en SQL Server.

Como otros tipos de espera del servidor de base de datos, lo importante es el conocer el significado antes de pensar en una acción.

---

¿Qué es PAGEIOLATCH?

Este tipo de espera hace una referencia directa al IO tal como se evidencia en su nombre. Entonces estamos hablando de disco y de páginas de datos que deben ser leídos desde el storage.

Según la documentación oficial de Microsoft, donde se describe la vista de sistema sys.dm_os_wait_stats, existen diferentes tipos de PAGEIOLATCH. Hablaremos en este post de los más representativos.

Al igual que vimos en los Tipos de Bloqueos en SQL Server, en los LOCKS tenemos diferentes modos que referencian a los escenarios en los que se genera la espera LCK. Pasa la mismo con PAGEIOLATCH.

PAGEIOLATCH_	DESCRIPCIÓN
SH (Shared)	La espera por el paso de una página de datos desde el storage al buffer pool para que su contenido pueda ser leído.
UP (Update)	La espera por el paso de una página de datos desde el storage al buffer pool para que su contenido pueda ser modificado.
EX (Exclusive)	De la misma manera; la espera por el paso de una página de datos desde el storage al buffer pool para que su contenido pueda ser modificado.

Los origenes de esta espera

Lectura y escritura de datos, evidentemente. Sobretodo la veremos durante la generación de escaneos de tablas heap, índices y páginas no ordenadas.

Cuando los tiempos de espera crecen más de lo normal, tenemos un indicio de que los sistemas de discos pueden tener algún problema. Por eso es importante tener claramente una línea base en nuestro monitoreo y así identificar cambios muy fuertes.

---

Entonces, ¿cómo afecta PAGEIOLATCH en SQL Server?

Mientras más tiempos de esperas, menos eficientes nuestras consultas. Por eso debemos tener claramente identificados los cambios de comportamiento en nuestros servidores.

Las lecturas que se hacen con PAGEIOLATCH_SH suelen estar de la mano con la espera CXPACKET. Esto ya que cantidades grandes de lectura pueden obligar al motor a decidirse por aplicar paralelismo.

---

Conclusiones

• No debe partirse de la idea de que el storage tiene problemas. Estas esperas muchas veces pueden disminuirse analizando las consultas.
• Revisa tus parámetros en un SP, que sean los adecuados, que no existan conversiones y que los índices puedan ser bien usados.
• Revisa si estás generando SCAN o SEEK con tus índices y cuál es la cantidad de uso. Puedes obtener fácilmente un Reporte de Uso de Índices.
• Cuando las consultas tienen mucho por leer, crear índices puede ayudarte. Puedes generar un Reporte de Missing Indexes para ver sugerencias de nuevos índices, pero con cuidado, las recomendaciones están también en el enlace.
• Puedes ver en el cache aquellas consultas con mayor cantidad de lecturas. Pueden estar referenciadas con PAGEIOLATCH. Genera un Reporte de Cache con @OrderBy = ‘reads’