PageIOLatch_Sh espera notada después de ajustar un índice

Question

Últimamente, muchas consultas a la base de datos están agotadas.Mientras investigaba, descubrí que las consultas están en estado suspendido con wait_type como PageIOLatch_Sh.No había notado que se suspendieran tantas consultas antes en el servidor.Esto ha estado sucediendo desde el sábado.

Hace un par de semanas, la CPU del servidor de base de datos estaba al 100% constantemente.Mientras intentaba solucionarlo, cambié un par de índices que realmente no se estaban utilizando y estaban dando lugar a user_scans.Después de cambiar los índices, el uso de la CPU en el servidor disminuyó, el rendimiento del sitio fue en general más rápido y al observar las estadísticas del índice ahora se estaban produciendo una gran cantidad de búsquedas de usuarios, lo que pensé que era una buena señal.

Sin embargo, ahora, después de una o dos semanas, aunque el uso de la CPU no es 100, una gran cantidad de consultas han comenzado a agotarse y se observan esperas de PageIoLatch_Sh.Lo interesante es que estos tiempos de espera no ocurrían con una frecuencia tan alta antes a pesar de que la CPU estaba al 100%.

Ahora bien, mantener índices también es algo que ralentiza el procesamiento del servidor SQL, por lo que me preguntaba si los nuevos índices podrían haber dado lugar a una mayor cantidad de estas esperas y tiempos de espera.

Answer 1

Según la información general que ha proporcionado, parece que ha movido el punto de contención en su servidor de CPU a IO, como resultado de la implementación de una estrategia de indexación dirigida a consultas problemáticas específicas.

En su mayor parte (sin entrar en detalles de cuál es exactamente su estrategia de indexación), este es el comportamiento esperado porque como la CPU ya no es un punto de contención, las ESPERAS ocurren naturalmente en otros lugares.

Los problemas de rendimiento que está viendo ahora no se deben necesariamente a las modificaciones del índice que ha aplicado.Se requiere más investigación para identificar las consultas específicas que son responsables de las esperas de IO, así como de los tiempos de espera que está viendo.Desea revisar los planes de ejecución para cada uno de estos escenarios para identificar posibles áreas de optimización (busque primero operaciones típicamente no deseadas, como conversiones implícitas, escaneos de tablas, etc.).

Sin embargo, no quiero ser presuntuoso, a menudo encuentro tiempos de espera de consulta en entornos de clientes debido a malas elecciones de planes de consulta como resultado del rastreo de parámetros.Esto también puede ser algo a considerar.

Para algunas consultas útiles que puede utilizar durante sus investigaciones, consulte Consultas de diagnóstico de SQL Server de Glenn Berry.Hay una serie de consultas fantásticas para observar IO, por ejemplo, qué bases de datos son responsables de la mayor cantidad de IO, qué archivos de datos de bases de datos tienen más actividad, qué consultas causan más lecturas/escrituras, etc.

Answer 2

Suponiendo que sus índices están actualizados, que caen de 100% de CPU a algo menos, mientras que tiene problemas de tiempo de espera, implica que la aplicación ahora está esperando bloqueos o disco. El pestillo IO espera implica el disco. Usaría perfmon para mirar los discos para ver si parece haber una cantidad inusualmente alta de lecturas, ver los planes de consulta para consultas exactas que funcionan lentamente y repensar lo que hice sobre la indexación.

Otro pensamiento es que si he hecho un cambio y las cosas parecen peor después, lo primero que haría es deshacer ese cambio. Iow, devuelve los viejos índices.

Answer 3

Tendría que estar de acuerdo con John, el cuello de botella acaba de moverse sobre ti. Podría estar alcanzando los límites del hardware, o lo más probable, la consulta puede necesitar algo de trabajo.