Cómo resolver los tipos de espera RESOURCE_SEMAPHORE y RESOURCE_SEMAPHORE_QUERY_COMPILE

Estamos tratando de descubrir la causa raíz de las consultas lentas del servidor sql que golpean / obtienen datos de una de la base de datos, tamaño 300 GB, alojada en el servidor con la siguiente configuración:

Windows server 2003 R2, SP2, Enterprise Edition, 16 GB RAM, 12 CPU'S 32 Bit

SQL Server 2005, SP4, Enterprise Edition, 32 bits.

Ya hemos informado a las empresas sobre la actualización a 64 bits, lo que llevaría más de un mes.

Pero para el problema actual, estamos tratando de recopilar los datos si podemos resolver la presión de la memoria o finalmente llegar a una conclusión para aumentar la RAM.

Acción completada: las estadísticas de reindexación y actualización son adecuadas para esta base de datos.

Como se muestra a continuación, hemos notado el tipo de espera de semáforo durante los últimos 5 días, que se ejecutó durante las horas de carga:

Poca información después de las siguientes consultas: tamaño del búfer = 137272

SELECT SUM(virtual_memory_committed_kb)
FROM sys.dm_os_memory_clerks
WHERE type='MEMORYCLERK_SQLBUFFERPOOL'

y memoria de semáforo = 644024 por consulta a continuación

 SELECT SUM(total_memory_kb)
FROM sys.dm_exec_query_resource_semaphores

A continuación hay más información recopilada de dm_exec_query_resource_semaphoresy sys.dm_exec_query_memory_grantsdmv

Entonces, de la información anterior recopilada y según los datos de SP_Blitz, el semáforo de recursos parece ser el problema.

¿La memoria 'target_memory_kb' está asignada para la identificación del semáforo de recursos es demasiado baja, en comparación con 16 GB de RAM disponibles?

Nota * por análisis en 8 horas de ejecución 'target_memory_kb' siempre es inferior a 1 GB, en comparación con los 16 GB disponibles?

cuál podría ser el problema aquí y cómo resolverlo, sugiera

Gracias

Oh, Dios mío, tengo algunas malas noticias aquí.

En un sistema operativo de 32 bits, SQL Server solo usa los primeros 4 GB de memoria para cosas como el espacio de trabajo de consulta. (Y también está luchando contra el sistema operativo por esos 4 GB; cualquier otra aplicación en ejecución también competirá por esa memoria).

4 GB puede parecer mucho, pero es relativamente fácil escribir una consulta que necesita varios GB de memoria para ejecutarse. Cuando suficientes consultas exigen suficiente memoria, SQL Server arroja RESOURCE_SEMAPHORE en espera porque las consultas no pueden obtener suficiente memoria para comenzar. RESOURCE_SEMAPHORE_QUERY_COMPILE significa que ni siquiera pueden obtener suficiente memoria para compilar un plan de ejecución, y sí, eso es bastante malo.

Entonces, ¿cómo lo arreglas?

• Cambie a un sistema operativo de 64 bits (el sistema operativo que está ejecutando está fuera de soporte de todos modos)
• Cambie a una compilación de 64 bits de SQL Server
• Reduzca las demandas de memoria en el servidor (no ejecute ninguna otra aplicación en este cuadro, y eso es especialmente crítico en los cuadros de 32 bits ya que tenemos un límite de solo 4 GB)
• Use más memoria con los conmutadores AWE / PAE, excepto que no funciona para RESOURCE_SEMAPHORE espera porque SQL Server solo puede usar esos primeros 4 GB para el espacio de trabajo de consulta
• Ajuste las consultas y los índices para que necesiten menos memoria

Incluso dudo en decir eso último, porque el problema de 32 bits es muy malo y es realmente difícil en las versiones anteriores de SQL Server. Si estaba en uno actual, podría revisar el caché del plan y ordenar las consultas por concesión de memoria, encontrar los destinatarios de la mayor concesión y ajustarlos. Sin embargo, no es una opción en esta antigua antigüedad.