Skip to main content

Contadores de rendimiento SQL Server

Una de las mejores formas que tenemos para obtener estadísticas de nuestros servidores de bases de datos SQL Server, es ocupar el Monitor de rendimiento de Windows (Perfmon). Sin embargo, al utilizarlo nos daremos cuenta de que es un poco tedioso encontrar los contadores o items que necesitamos, o que nos ayudarán a obtener información realmente relevante respecto a nuestro servidor.
Es por esto que a continuación elaboraremos una lista de los puntos más importantes a rescatar, y los valores que estos deberían contener para asegurar un buen rendimiento:
1 - Memoria
  • Memory: Pages/sec. Indica el número de páginas que entran y salen de la caché en cada segundo. Su valor debe situarse muy cercano a 0. Si es mayor a 20 de forma continuada, tal vez no tengamos un problema de rendimiento; pero lo que es seguro es que la memoria no está siendo gestionada adecuadamente.
  • Memory: Availability Mb (ó Kb ó Bytes , lo que más cómodo resulte). En general, debemos contar con 5 Mb de memoria libres (y disponibles) como mínimo.
  • SQL Server: Memory Manager: Total Server Memory y Target Server Memory. Estos dos contadores del mismo objeto nos dicen el total de memoria que tenemos y la memoria que necesitamos. "Total" debe ser igual que "Target". Si esto no es así, y "Total" es menor que "Target", es un indicio claro de un problema en la memoria, ya que tenemos menos de la que necesitamos.
2 - Procesador
  • Processor: % CPU Usage (instancia _Total si se cuenta con más de un procesador y si todos ellos están desempeñando el mismo rol): Mantener por debajo del 80%.
  • System: Processor queue length. Es la cola de procesador, debe permanecer por debajo de 2 por CPU.
3 - Disco
  • PhysicalDisk: Avg. Disk Queue Length. Debe estar por debajo de 2 en cada unidad (tras ponderar el número de discos del RAID, si procede). La instancia común puede sernos de ayuda para calibrar el estado general.
  • PhysicalDisk: % Disk Time. Indica qué porcentaje de tiempo se emplea en el disco. Si está por encima del 55%, puede que haya un problema, habría que mirar también PhysicalDisk: Disk Read Time y PhysicalDisk: Disk Write Time para ver si hay un importante desequilibrio no esperado entre las lecturas y las escrituras, que podría regularse variando el fill factor de los índices (si estamos hablando de una base de datos de sólo lectura o eminentemente de lectura, es lógico que haya un desequilibrio). Si las lecturas están muy por encima de las escrituras, el fill factor puede que sea muy alto. Si es al contrario y las escrituras llevan la mayor parte del peso, aumentar el fill factor podría paliar el problema. Es más una cuestión de afinar y probar hasta encontrar un equilibrio.
4 - Red
  • Network Interface: Bytes Total/sec. Depende esencialmente de la red, con lo que es difícil dar una cifra que pueda ser usada de forma general. Se puede aplicar una sencilla regla, en combinación con el contador Current Bandwidth, del mismo objeto. Bytes Total/sec dividido entre Current Bandwidth debe ser menor que 6.
  • Network Segment: % Network Utilization. Permite verificar el uso de cada tarjeta de red que podamos tener en el servidor.
  • Server: Bytes Received/sec y Server: Bytes Transmitted/sec. Permite comprobar si es el servidor de base de datos el que está saturando la red, perjudicando sus otros usos.
  • SQLServer: SQL Statistics: Batch Request/sec. Una tarjeta de red de 100Mbs soporta, aproximadamente, unos 3000 comandos por segundo. Si este contador está por encima, se precisa una segunda tarjeta o una de mayor capacidad.
5 - SQL Server
  • 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.
Por último, un contador para medir el rendimiento de los backup. Cuando se lanza un backup, lo más normal es que se produzca un importante pico en la cola de disco. Si contamos con varias bases de datos, es típico lanzarlos todos a la vez (además, justo a las doce de la noche). Podemos tener un problema de rendimiento que es preciso vigilar, que podríamos evitar lanzando los backup uno a continuación del anterior. Un contador al que podemos acudir es SQLServer: Backup Device: Device Throughput Bytes/sec. Este contador mide el rendimiento de los backup, y con una regla de tres simple también lo podemos usar para saber cuánto nos queda para que un backup finalice, por ejemplo. Tiene la pega de que sólo se puede arrancar para los backup que estén realizándose en ese momento. Pero si se dispone de una utilidad de monitorización es posible explotarlo sin problema.











Labels:

Comments

Post a Comment

Popular posts from this blog

How to "safely" truncate history tables in Zabbix 6 before enabling timescale.

The script was tested against Zabbix 6.0 and 6.2. I'll add a proper introduction soon. If you don't fully understand every single line better don't run it in production. --RECREATING HISTORY TABLES WITH DATA. INSTEAD OF "WHERE FALSE" YOU CAN USE "WHERE CLOCK > X" IF YOU WANT TO PRESERVE SOME DATA ALTER TABLE history RENAME TO history_big; CREATE TABLE history as SELECT * FROM history_big where false; ALTER TABLE history_uint RENAME TO history_uint_big; CREATE TABLE history_uint as SELECT * FROM history_uint_big where false; ALTER TABLE history_str RENAME TO history_str_big; CREATE TABLE history_str as SELECT * FROM history_str_big where false; ALTER TABLE history_log RENAME TO history_log_big; CREATE TABLE history_log as SELECT * FROM history_log_big where false; ALTER TABLE history_text RENAME TO history_text_big; CREATE TABLE history_text as SELECT * FROM history_text_big where false; ALTER TABLE history_text RENAME TO history_text_big; CREATE TABLE...
Post a Comment
Read more

Consulta de espacio ocupado de logs SQL SERVER

SQLPERF Pese a que en SQL SERVER disponemos de funciones simples que nos devuelven información relevante sobre el uso de la base de datos, muchas veces necesitamos especificar campos específicos sobre una funcion predeterminada. En el ejemplo siguiente, se muestra la consulta equivalente a realizar una de las DMF más usadas: DBCC sqlperf(logspace) La consulta anterior es exactamente igual a la siguiente: SELECT instance_name AS DatabaseName,        [Data File(s) Size (KB)],        [LOG File(s) Size (KB)],        [Log File(s) Used Size (KB)],        [Percent Log Used] FROM (    SELECT *    FROM sys.dm_os_performance_counters    WHERE counter_name IN    (        'Data File(s) Size (KB)',        'Log File(s) Size (KB)',        'Log File(s) Used Size (KB)',        'Per...
Post a Comment
Read more

Uso de memoria en SQL Server

Configuración de memoria Muchas veces, nos encontramos con que un servidor SQL Server está consumiendo demasiada memoria. Las causas de esto pueden ser muchas; Demasiados usuarios conectados o un exceso de carga de trabajo pueden ser las causantes. Sin embargo, una de las características que mas destacan de SQL Server , es que una vez que le asignamos memoria , la instancia es la encargada de administrarla, me explico. Cuando miramos el administrador de tareas de Windows (Task manager) nos daremos cuenta de que en la pestaña de rendimiento se observa muy poca memoria disponible. Esto no quiere decir que sea esa la memoria utilizada (aunque explícitamente lo diga), debido a que la instancia administra su propia memoria libre dentro de su memoria utilizada. Por ejemplo, si tenemos un servidor con 100GB de memoria RAM, y Task manager nos indica que tenemos 2 GB libres, y además, SQL Server está ocupando 90GB de RAM, tenemos que tomar en cuenta que dentro de esos 90GB ocupados por la i...
Post a Comment
Read more