Articles

SQL: ESPERANZA DE VIDA DE LA PÁGINA

Posted by admin

Síntomas: SQL ha detectado una caída en la esperanza de vida de la página, produciendo respuestas más lentas.

Impacto: Medio

Las respuestas SQL lentas degradarán la experiencia del usuario, lo que resultará en una eficiencia deficiente de las operaciones de su organización.

Comportamiento esperado:

Cuanto más tiempo pueda permanecer una página en el grupo de búferes y se pueda leer de la memoria, mejor será el rendimiento del sistema. Recomendamos establecer el valor de umbral en 300 segundos por cada 4 GB de memoria de grupo de búferes (BP).

Posibles causas de baja Esperanza de Vida de página (PLE) persistente

Baja prioridad de potencia de CPU: Media
Acción recomendada :
El uso continuamente alto asociado con una PLE baja puede indicar la necesidad de una actualización de CPU o la adición de varios procesadores. Vea nuestra explicación del uso de CPU aquí
Alternativamente, una tasa de uso de CPU alta puede indicar una aplicación o código SQL mal ajustado. La optimización de la aplicación puede reducir la utilización de la CPU.

Prioridad de RAM Insuficiente: Medio
Revise la cantidad de RAM total asignada a SQL (mientras mantiene suficiente RAM para las necesidades del sistema operativo). Compare la proporción de memoria SQL con el tamaño de la base de datos: según nuestra experiencia, una proporción de RAM total superior al 20% de la base de datos más grande es óptima.
Acción recomendada:
Si es posible, asigne más memoria a SQL o, alternativamente, agregue RAM física al servidor y aumente la asignación de memoria SQL.

Prioridad de ocupado/lento del archivo de página: Baja
Compruebe qué más se está ejecutando que podría ralentizar la velocidad de acceso al disco. El grupo de búfer intercambia páginas al disco cuando se necesita espacio de memoria. Este proceso depende en gran medida de la eficiencia de las acciones de lectura/escritura de datos en el disco duro y del nivel de demanda.
Acción recomendada:
Para acelerar la E/S del disco y reducir la latencia, localice el archivo de página en la unidad más rápida disponible (o actualice a un hardware más eficiente). Además, reduzca la competencia por este recurso de otras operaciones. AimBetter resource monitor proporciona estadísticas completas sobre el espacio total en disco, el espacio libre y la actividad de los archivos de página.

Prioridad de asignación incorrecta del Grupo de búfer: Bajo
En SQL Server, los datos se almacenan en páginas de 8 KB. Cuando se requieren datos para la entrada / salida, la página se lee por primera vez desde el disco y se almacena en la memoria. El área asignada se denomina Grupo de búferes. Una vez que se carga una página en el grupo, todo el acceso posterior es muy rápido y eficiente, mientras que la E/S del disco es relativamente lenta. Se debe asignar la mayor cantidad de memoria posible al grupo de búferes, sin que el sistema operativo muera de hambre.
Acción recomendada:
Asigne la proporción óptima de RAM física a BP, pero deje suficiente RAM para operaciones de SO. Establezca un valor en la opción de Memoria máxima del servidor de la página ‘Opciones de memoria del servidor’, que deje suficiente memoria para el sistema operativo en sí. Recomendamos alrededor de 4 GB menos que la cantidad total de RAM instalada

Posibles causas o baja Esperanza de vida de página (PLE) transitoria

Prioridad de índice faltante o corrupto: Índices faltantes altos
significa que SQL Server sugiere que su consulta podría ejecutarse más rápido con un índice. el 99% de las veces, la corrupción está relacionada con el disco o el controlador de disco/firmware.
Acción recomendada:
En caso de que falte un índice, consulte a su equipo de diseño del sistema.
En caso de índices dañados, consulte a su equipo de administración de almacenamiento o a nuestros expertos de soporte para obtener ayuda. Un posible remedio en los casos en que la corrupción se repite es clonar la base de datos en una nueva configuración de hardware.

Problemas de codificación Prioridad: Baja
Puede ser el resultado de problemas como planes de consulta ineficientes o estándares de codificación inadecuados.
Acción recomendada:
Inspeccionar el plan que estaba utilizando SQL para determinar si era óptimo.
Investigue las consultas de la base de datos para ver si las consultas de datos requeridas están dañadas o son incorrectas.
Investigue la codificación, para ver si se puede mejorar la eficiencia.

Consultas que saturan la prioridad del grupo de búfer: Baja
Estas causas no persisten durante largos períodos de tiempo. Las causas principales son:

  • obtener grandes concesiones de memoria
  • desplazar un gran número de páginas en memoria con otras nuevas
  • modificar muchas páginas, forzándolas a vaciarlas al disco
  • muchas consultas simultáneas (o algunas muy grandes)

Acción recomendada :
En los casos en que se repitan o muestran una tendencia a aumentar de magnitud (menor PLE), investigue las otras posibles causas a continuación.

DBCC CHECKDB prioridad de ejecución: Baja
CHECKDB consume muchos recursos, probablemente una de las tareas que SQL Server realiza con más recursos. La introducción de este proceso como una carga de E / S adicional a la carga normal de SQL Server significa que los cabezales de disco se moverán constantemente.
acción Recomendada :
Sugerimos ejecutar cualquier proceso esencial de CHECKDB en un momento de carga mínima de SQL Server, o alternativamente en copias de seguridad de las bases de datos sin conexión.

Reconstrucción de índices con prioridad en ejecución: Baja
Una operación de reconstrucción de índices siempre creará un nuevo índice, lo que significa que se requiere espacio adicional para crear el nuevo índice antes de eliminar el anterior; se requieren muchos recursos de CPU y E/S, lo que puede sobrecargar el sistema.
acción Recomendada :
Si ocurre con frecuencia, puede corregirse mediante cambios en el procedimiento de indexación, por ejemplo, cambiando a una estrategia en la que la fragmentación se analiza cada noche y solo se procesan los índices fragmentados. Nuestros expertos consultores del Equipo de Soporte están disponibles para analizar y ayudar.

Fondo

La métrica de esperanza de vida de página mide el número promedio de segundos que permanecen las páginas en el grupo de búferes. Está estrechamente relacionado con el uso de archivos de página – ver aquí.
Para un rendimiento óptimo, los datos deben leerse desde la memoria en lugar del disco, que es mucho más lento. SQL logra esto utilizando páginas de memoria que almacenan los datos a los que se ha accedido más recientemente. Un área reservada de memoria (el grupo de búferes) está disponible para el almacenamiento de estas páginas. Cuando el grupo de búfer está lleno y SQL requiere espacio nuevo, el servidor intercambia la página más antigua con el archivo de página en el disco y lee los nuevos datos. Los aumentos en el número de intercambios entre memoria y disco afectan directamente al rendimiento.
Niveles bajos sostenidos de PLE es un indicador confiable de la presión de memoria de SQL Server. Esta presión puede ser el resultado de una alta demanda o de una organización de datos ineficiente, tanto física como lógica
Recomendamos establecer el valor de umbral en 300 segundos por cada 4 GB de memoria del Grupo de Búferes (BP) en su servidor, lo que significa que el servidor debe retener cualquier página en la memoria (después de que un proceso haga referencia a la página) en el grupo de búfer durante un mínimo de 5 minutos antes de que se vacíe al disco. Si el grupo de búfer está vaciando páginas en menos de 300 segundos, probablemente haya un problema.
Cuanta más memoria tenga su servidor, más lecturas y escrituras de disco en caché podrá realizar. La falta de memoria del sistema puede causar altas lecturas y escrituras de discos no almacenados en caché. Agregar memoria a su servidor puede ayudar a reducir el acceso al disco físico.

Related Post

Leave A Comment