Pregunta

Durante meses, el PLEO en uno de nuestros servidores se ha movido alrededor de los 2 millones de segundos. Si varía ligeramente de día a día, pero era bastante estable allí.

Este último fin de semana, agregamos 12 GB de RAM virtual y 1 núcleo de CPU virtual al servidor. No cambiamos la RAM máxima usada en SQL Server para que coincidamos con la nueva RAM ni asignamos el nuevo núcleo de CPU a SQL Server.

Dado que esto se hizo, nuestro PLE ha fluctuado salvajemente, yendo entre 50 y 4 millones de segundos cada 10-30 minutos. Los cambios no son un aumento lento o caída. Las métricas van directamente desde muy bajo a muy alto y viceversa en menos de un minuto.

Nuestros tiempos de espera general para el servidor están bien. Los pestillos son normales. Los tamaños de almacenamiento en el búfer y el plan de caché no han cambiado. No parece haber ningún patrón consistente de una consulta específica o tipo de consulta que drena los recursos.

Nunca he visto hacer esto antes. ¿Puede alguien apuntarme a lo que me puede perder o necesitar profundizar en?


Información adicional de comentarios:

  • Estamos en 5 CPUT TOTAL, pero solo usando 3 (estábamos en 4 usando 3).
  • Nuestra memoria total es de 49 GB y el máximo de SQL es de 28 GB.
  • Estamos usando VMware con un OS X64 (Windows 2008).
  • Hay 14 bases de datos de usuarios en el servidor con el principal que es alrededor de 250 GB.
  • La proporción de éxito en caché de tampón se ha mantenido alrededor de 98 +%, ya que todo esto comenzó.
  • El plan de energía del servidor está configurado en equilibrado (no alto rendimiento); Sin embargo, eso no ha cambiado en varios años. Dicho esto, estoy completamente de acuerdo en que debería ser un alto rendimiento.
  • Ni el error de SQL Server ni los registros de eventos de Windows están mostrando nada fuera de lo común.
  • La actividad en el servidor no ha cambiado en las últimas semanas.
  • El servidor es consciente de Numa. El MAXDOP es 4, con un umbral de costo de 10.
¿Fue útil?

Solución

Tomamos la memoria de 28 GB (la cantidad original) a 40 GB, dejando 8 GB de memoria para el sistema operativo y otros procesos.Inmediatamente después, todo volvió a la normalidad y se ha mantenido estable.Uno de nuestros DBA especuló que SQL Server se confuso sobre cuánta memoria realmente tenía disponible.Había revisado la memoria total del servidor antes y después, y los números eran consistentes con los que veo en las propiedades del servidor, pero encuentro que la afirmación es difícil de discutir en contra de

Licenciado bajo: CC-BY-SA con atribución
No afiliado a dba.stackexchange
scroll top