Resource_semaphore wait type not matching sys.dm_exec_query_memory_grants

Question

We are using Red Gate's SQL Monitor to alert (every 5 minutes) when memory grants pending are greater than zero. Several times a day we are alerted on our Devel and Prod servers.
However, when querying the resource_semaphore wait type using sys.dm_os_wait_stats, it used to register non-zero amounts several months ago, but now is always equal to zero.
The Devel server is version 11.0.3128 standard on Windows 2008 R2 Standard 64-bit, and the Prod server is version 10.0.5500 on Windows 2008 Standard 64-bit.
We are storing wait stats for each server in a database, collected every half hour. The Prod resource semaphore was 569 early August 11, then after a reboot at 3:30 AM was equal to zero and is the same today. I have confirmed the current value using the following
query.
SELECT * FROM sys.dm_os_wait_stats
WHERE wait_type = 'RESOURCE_SEMAPHORE';
Similarly, the Devel resource semaphore was 167 early October 23, then after a reboot at 7:03 AM was equal to zero and has not changed from zero since then. Again, I confirmed the current value using the above query.
The custom alert code for Red Gate SQL Monitor is:
SELECT COUNT(*) FROM sys.dm_exec_query_memory_grants;
Also, running a perfmon counter against SQL Server: Memory Manager: Memory Grants Pending for
several days yields a flat line equal to zero, with maximum value zero.
Looks to me like something in SQL Server's internal stats collection system has broken. Or possibly, I am misunderstanding that these three counters measure the same thing.
Thanks for your help.

Answer 1

We are using Red Gate's SQL Monitor to alert (every 5 minutes) when memory grants pending are greater than zero. Several times a day we are alerted on our Devel and
Prod servers. However, when querying the resource_semaphore wait type using sys.dm_os_wait_stats, it used to register non-zero amounts several months ago, but now is always equal to zero.
The Devel server is version 11.0.3128 standard on Windows 2008 R2 Standard 64-bit, and the Prod server is version 10.0.5500 on Windows 2008 Standard 64-bit.
We are storing wait stats for each server in a database, collected every half hour. The Prod resource semaphore was 569 early August 11, then after a reboot at 3:30 AM was equal to zero and is the same today. I have confirmed the current value using
the following query.
SELECT * FROM sys.dm_os_wait_stats
WHERE wait_type = 'RESOURCE_SEMAPHORE';
Similarly, the Devel resource semaphore was 167 early October 23, then after a reboot at 7:03 AM was equal to zero and has not changed from zero since then. Again, I confirmed the current value using the above query.
The custom alert code for Red Gate SQL Monitor is:
SELECT COUNT(*) FROM sys.dm_exec_query_memory_grants;
Also, running a perfmon counter against SQL Server: Memory Manager: Memory Grants Pending for
several days yields a flat line equal to zero, with maximum value zero.
Looks to me like something in SQL Server's internal stats collection system has broken. Or possibly, I am misunderstanding that these three counters measure the same thing.
Thanks for your help.
Hello,
SQL server internal stats collection is fine it is not broken what you are doing is after restart SQL server cache is cleared and this is area from where you get all your DMV result so before restart you are seeing some value for resource semaphore wait
and after restart it is gone.
For query memory grants pending value as non zero it clearly points to fact that there is memory crunch and you need to increase more RAM.
resource semaphore waits point to fact that your query which is running is costly one and is involving lots of sort and hash you need to tune it.Read below article for resource semaphore wait
http://blogs.msdn.com/b/sqlqueryprocessing/archive/2010/02/16/understanding-sql-server-memory-grant.aspx
If you want to find out cumulative waits stats i suggest you to use below query by Jonathan Kehayias.
Can you post output for this query
SELECT TOP 10
wait_type ,
max_wait_time_ms wait_time_ms ,
signal_wait_time_ms ,
wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms ,
100.0 * wait_time_ms / SUM(wait_time_ms) OVER ( )
AS percent_total_waits ,
100.0 * signal_wait_time_ms / SUM(signal_wait_time_ms) OVER ( )
AS percent_total_signal_waits ,
100.0 * ( wait_time_ms - signal_wait_time_ms )
/ SUM(wait_time_ms) OVER ( ) AS percent_total_resource_waits
FROM sys.dm_os_wait_stats
WHERE wait_time_ms > 0 -- remove zero wait_time
AND wait_type NOT IN -- filter out additional irrelevant waits
( 'SLEEP_TASK', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH',
'SQLTRACE_BUFFER_FLUSH','CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT',
'LAZYWRITER_SLEEP', 'SLEEP_SYSTEMTASK', 'SLEEP_BPOOL_FLUSH',
'BROKER_EVENTHANDLER', 'XE_DISPATCHER_WAIT', 'FT_IFTSHC_MUTEX',
'CHECKPOINT_QUEUE', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
'BROKER_TRANSMITTER', 'FT_IFTSHC_MUTEX', 'KSOURCE_WAKEUP',
'LOGMGR_QUEUE', 'ONDEMAND_TASK_QUEUE',
'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BAD_PAGE_PROCESS',
'DBMIRROR_EVENTS_QUEUE', 'BROKER_RECEIVE_WAITFOR',
'PREEMPTIVE_OS_GETPROCADDRESS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS',
'WAITFOR', 'DISPATCHER_QUEUE_SEMAPHORE', 'XE_DISPATCHER_JOIN',
'RESOURCE_QUEUE' )
ORDER BY wait_time_ms DESC
Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers