Contadores de rendimiento

Los contadores de rendimiento son una herramienta indispensable para una correcta monitorización  de nuestros aplicativos, a la hora de llevar nuestras aplicaciones a producción se hace necesario un conjunto de pruebas para verificar el correcto funcionamiento de nuestras aplicaciones, ya sean a nivel Web o a nivel de escritorio. En esta sección hablaremos de los contadores de rendimiento de SQL.

Lo primero es añadir los contadores de rendimiento, esto se realiza desde el Panel de Control>Registro y alertas de rendimiento. Los contadores más importantes son y segun la MSDN:

Los siguientes son algunos de los contadores de uso más extendido, intentando hacer un barrido por lo más significativo para conseguir una monitorización básica:

• SQLServer: Access Methods: Page split/sec. Si está por encima de 100, viene acompañado de problemas de disco. Un aumento en el fill factor puede resolver la situación.

• SQLServer: Buffer Manager: Cache Hit Ratio. Indica el porcentaje de veces que el motor usa la caché frente al disco. Es un valor medio desde el último reinicio. Este valor debe permanecer por encima del 99%, casi en 100, para servidores OLTP. En servidores OLAP, debe estar por encima del 80%.

Los siguientes 5 contadores sirven para afinar problemas de caché y memoria:

• SQLServer: Buffer Manager: Page Life Expectancy. Tiempo en segundos que permanece una página en memoria sin tener ninguna referencia que la retenga allí. Cuanto más tiempo, mejor. Un valor de referencia, por encima de 300, es decir 5 minutos.

• SQLServer: Buffer Manager: Lazy Write/sec. Páginas que salen de la caché por segundo. Al contrario que el anterior, cuanto más alto, peor. Por debajo de 20.

• SQLServer: Buffer Manager: Checkpoint Pages/sec. Un checkpoint obliga a bajar a disco todas las páginas que se tengan en memoria. Sólo debe ejecutarse en determinadas circunstancias, la mayoría de ellas, tareas administrativas, por lo que si se ejecuta con mucha frecuencia, estaremos mal utilizando la memoria.

• SQLServer: Buffer Manager: Procedure Cache Pages. Este contador indica las páginas de memoria dedicadas a almacenar planes de ejecución de procedimientos almacenados. Un descenso brusco en este contador puede venir acompañado de un descenso del rendimiento, causado por la recompilación de procedimientos almacenados.

• SQLServer: Databases: Log Flushes/sec. Indica las veces por segundo que las páginas pasan de caché al fichero de log. Funciona muy en paralelo al número de transacciones, y como el número de transacciones, cuanto menor sea, mayor rendimiento.

Para tener una idea del número de usuarios que manejamos, los siguientes 3 contadores son muy útiles:

• SQLServer: General Statistics: User connections. Indica el número de conexiones. Sirve para saber identificar horas de alta y baja actividad y para saber si un pico en otras áreas puede estar relacionado con un mayor número de usuarios en ese momento.

• SQLServer: Databases: Transaction/sec. Además de un uso similar al contador anterior, nos permite determinar qué bases de datos tienen más carga de transacciones. Un caso a tratar de forma particular es el de tempdb, ya que es muy común que sea ésta una de las bases de datos que más transacciones por segundo soporta. Es necesario vigilar y optimizar en lo posible este hecho. Su reducción puede venir de muchas formas, siendo algunas tan obvias como la revisión de los procesos que usan tablas temporales, pero no sólo eso, también hay que observar las consultas muy pesadas y complejas, que usan tempdb para completarse.

• SQLServer: SQL Statistics: SQL Compilations/sec. Da una idea de la carga real del servidor, en cuanto a compilaciones se refiere. Si está entorno a 100, es buena señal. Si pasa de ahí, se estarán consumiendo muchos recursos en la preparación de planes de ejecución.

Por lo general, la detección de bloqueos no se observa de una forma fácil con contadores, salvo que la situación sea realmente caótica. Los siguientes contadores aportan datos que si destacan, es mejor estudiar con profiler:

• SQLServer: Access Methods: Full scans/sec. Este contador nos da una idea de las veces en las que se realizan recorridos de índice, mucho peor que realización de búsquedas en los mismos. Si arroja cifras relevantes, es mejor capturar con profiler y estudiar planes de ejecución de las consultas con más lecturas lógicas.

• SQLServer: Locks: Number of Deadlocks. El número de interbloqueos debe ser 0. Si se detecta alguno, hay que revisar y erradicar las sentencias que estén provocando ese problema. En ocasiones, el negocio obliga a que se den con más frecuencia, será cuando más cuidado haya que tener con el nivel de aislamiento.

• SQLServer: Locks: Avg. Wait Time (ms). Indica la media de milisegundos que hay que esperar para la liberación de un bloqueo.

• SQLServer: Latches: Average Latch Wait Time (ms) , Latch Waits/sec y Total Latch Wait Time (ms). Estos tres contadores nos hablan de los minibloqueos, es decir, bloqueos que son tan cortos que no llegan ni a serlo. Pero eso no significa que no estén ahí. Un elevado número de latches suele venir acompañado de un importante número de bloqueos. Así que estos contadores son de gran ayuda para anticiparse a problemas de este tipo, ya que lo que hoy son latches, en el futuro pueden ser bloqueos. La forma de gestionar estos valores es obtener una línea base durante un periodo de tiempo que consideremos normal, y que luego usemos como referencia, para poder saber si la situación se degrada. Si nos alejamos de esa línea base (por arriba), además de la revisión de las consultas y el nivel de aislamiento, es frecuente que el problema esté en la memoria o en el disco. Otros contadores, ya mencionados, nos ayudarán en este sentido.

Para más imformación puedes visitar el enlace de la MSDN en http://msdn.microsoft.com/es-es/library/bb972264.aspx#EBAA

Etiquetas
Contadores de rendimiento de sql servers analisis de Servidor sql server registros de cotadores Web asp.net