Por lo que puedo decir, la proporción de aciertos de caché de procedimiento por debajo del 95% es un problema. En mi caja, los valores oscilan entre 85 y 95%.
¿Cómo soluciono este problema? El servidor parece tener mucha RAM, por lo que no debería ser un problema. ¿Qué puede ser?
Respuestas:
Permítanme resumir (¡y redondear!) Los puntos de datos importantes en su hoja de cálculo:
Total Use Count 1
--------------------------------------- -----------------------
Total Plans Total MBs Avg Use Count Total Plans Total MBs
----------- --------- ------------- ----------- ---------
Adhoc 55,987 3,054 3 38,314 2,036
Proc 709 1,502 1,549 135 527Entonces, la primera fila muestra las cosas malas, ocupando aproximadamente 2/3 de la caché de su plan (cosas que en su mayoría solo se usan una vez, con algunas excepciones muy pequeñas). Debe intentar deshacerse de la mayor cantidad posible de estos. La segunda fila muestra las cosas buenas. Estas son las cosas que desea en su caché de planes (planes con una gran cantidad de reutilización). El resto de los datos es en gran medida irrelevante en mi humilde opinión. Sin embargo, otro punto: usted dice que el acceso es exclusivamente a través de procedimientos almacenados, pero si esos procedimientos usan SQL dinámico, esas declaraciones se almacenan en caché como AdHocplanes, no como Procplanes.
En 2008 o superior, diría que encienda optimize for ad hoc workloadsy pase al siguiente problema: esto llevaría la cantidad de MB que ocupan sus planes de uso único a casi nada. Desafortunadamente, en 2005, sus opciones son bastante limitadas, además de refactorizar esos procedimientos almacenados para usar OPTION (RECOMPILE)SQL dinámico a nivel de declaración y / o menos / no, o activar la parametrización forzada a nivel de base de datos , que intenta obtener una mejor reutilización del plan consultas similares tratando los literales como parámetros para propósitos de coincidencia de planes. Dudo incluso en mencionar las guías de planes porque no son para los tímidos y, como discuto más adelante en esta respuesta, no estoy seguro de que valga la pena seguir ese camino a menos que sepa que la caché de su plan es definitivamente la fuente de su rendimiento problema.
Le pregunté @@VERSIONporque, antes de SP2, el algoritmo para la cantidad de memoria que se podía asignar a la caché del plan era relativamente flojo. A partir de SP2 lo reforzaron bastante (el cambio está documentado y explicado en esta publicación y en esta publicación ). En su caso, el caché del plan está relativamente lleno, por lo que no es sorprendente que esté perdiendo caché. 26 GB = un límite superior de 5.8 GB; Veo ~ 4.5 GB en la hoja de cálculo, pero puede haber alguna diferencia de cálculo o configuración aquí que no conozco.
Este artículo de MSDN habla sobre la optimize for ad hoc workloadsconfiguración del servidor agregada en 2008 y menciona el indicador de rastreo 8032, que le permitirá asignar más memoria a sus cachés (presumiblemente en ausencia de establecer esta configuración en el nivel del servidor, que ahora recomiendo a todos nuestros clientes, o al menos el 99% que ya no están en 2005). Nunca probé este indicador de traza en 2005 SP3 o SP4, y sinceramente ni siquiera estoy seguro de cuándo se introdujo. Tampoco sé si resolverá su problema o simplemente lo cambiará, ya que creo que incluso si tuviera un% más de RAM asignada a los cachés, aún estaría llenándolo y teniendo muchos errores de caché debido a la naturaleza de sus procedimientos almacenados
O, por supuesto, si incluso hay un problema para resolver que se relaciona directamente con el caché del plan. El hecho de que su índice de aciertos de caché no sea tan alto como podría esperar no significa que esté causando su problema, y por supuesto lo contrario es que incluso con un índice de aciertos de caché del 100%, lo que no parece realista dado que tantos de sus planes son de un solo uso y ad hoc: sus usuarios aún pueden estar sufriendo problemas de rendimiento causados por algo completamente diferente.
Mi sugerencia es buscar mejores armas para fumar que la proporción de aciertos de caché planificada. Obtenga más detalles sobre las quejas de rendimiento de sus usuarios. ¿Todas las consultas son siempre lentas? Ciertas consultas? ¿Ciertos momentos del día / semana / ciclo económico? ¿Solo las consultas de informes son lentas? Lea detenidamente este documento largo y seco sobre las mejores prácticas de SQL Server , en particular, la sección de esperas y colas, que puede ayudarlo a formular un enfoque lógico para identificar, diagnosticar y resolver problemas de rendimiento. Hacer que algún número en un tablero se vea mejor, un número que ni siquiera sabe que contribuye directamente al problema, puede ser muy satisfactorio, pero si no resuelve los problemas de rendimiento de sus usuarios, entonces realmente no lo ha entendido en cualquier sitio.
Estos también pueden ser útiles para leer sobre compilación / recompilación y planificar la reutilización de caché. Algunos de estos se centran en 2008 (particularmente los relacionados con la configuración de cargas de trabajo ad hoc), pero gran parte de la información sigue siendo útil para 2005 y / o para comprender mejor los beneficios de la actualización (pista, pista).