RESOURCE_SEMAPHORE Waittype

1， 查看今天的Package执行情况，发现一个Package运行时间过长，为了查看当前DB中正在运行的SQL 语句，使用以下脚本

select    r.session_id,r.blocking_session_id,
r.request_id,r.start_time,r.status,r.command,
st.dbid,st.objectid,st.text as SqlStatement,
SUBSTRING (st.text,
r.statement_start_offset/2,
(CASE WHEN r.statement_end_offset = -1
THEN LEN(CONVERT(NVARCHAR(MAX), st.text)) * 2
ELSE r.statement_end_offset END
- r.statement_start_offset)/2
) as IndividualQueryStatement,
r.database_id,r.user_id,r.connection_id,
r.wait_type,r.wait_time,r.last_wait_type,r.wait_resource,r.open_transaction_count,
r.percent_complete,r.estimated_completion_time,
r.cpu_time,r.total_elapsed_time,r.reads,r.writes,r.logical_reads,
r.transaction_isolation_level,r.lock_timeout,r.deadlock_priority,r.row_count,
r.granted_query_memory,p.query_plan
from sys.dm_exec_requests r
outer APPLY sys.dm_exec_sql_text(r.sql_handle) as st
outer apply sys.dm_exec_query_plan(r.plan_handle) as p
where r.last_wait_type<>'MISCELLANEOUS'
and r.session_id>50

发现一个SPID运行时间非常长，其last_wait_type = RESOURCE_SEMAPHORE

RESOURCE_SEMAPHORE Wait的含义是：Used to indicate a worker is waiting to be allowed to perform an operation requiring "query memory" such as hashes and sorts .
High wait times indicate too many queries are running concurrently that require query memory. Operations requiring query memory are hashes and sorts. Use DMVs such as dm_exec_query_resource_semaphores and dm_exec_query_memory_grants

process 出现 RESOURCE_SEMAPHORE wait的原因是请求的memory没有得到满足，process不能start running。出现RESOURCE_SEMAPHORE Waittype的原因是不能得到请求的内存，导致查询语句没有执行下去，表明server存在内存压力。在sql server中，sort和hash join是非常消耗资源的两个操作，优化这两个查询可以缓解内存压力。

在数据库中有一个选项，Min Memory Per Query, when a query requires additional memory resources, the number of pages that it gets is determinded partly by the this option. this configuration option allows to specify a minimum amunt of memory that any of these operations should be granted before they are executed.

引用：Troubleshooting SQL Server RESOURCE_SEMAPHORE Waittype Memory Issues
https://www.mssqltips.com/sqlservertip/2827/troubleshooting-sql-server-resourcesemaphore-waittype-memory-issues/

Resource Semaphore Wait

Before moving on, I would like to shed some light on the Resource Semaphore wait so you can better understand how memory is granted to SQL Server queries.

When SQL Server receives a user query, it first creates a complied plan, then an execution plan is created based on the complied plan. When SQL Server creates a complied plan it calculates two memory grant parameters called "required memory" and "additional memory". Required memory is the minimum memory needed to run a sort and hash join. It is known as required because a query would not start without this memory available. Additional memory is the amount of memory needed to store temporary rows in memory. This is known as additional because a query can be stored on disk if there is not enough memory available.

First, the server calculates how much memory is needed for any given query to execute. This is generally the sum of required memory and additional memory, but if your instance is using parallelism then the needed memory would be (required memory * DOP) + additional memory. The server checks if the needed memory exceeds the per query limit, then the server reduces additional memory until the total fits within the limit. This revised size is called requested memory. There is an internal facility within SQL Server known as RESOURCE SEMAPHORE which is used to grant this requested memory to a query. If query is not able to be granted this requested memory by a Resource Semaphore, then that query will be in a waiting state with a RESOURCE_SEMAPHORE wait type if you query the sysprocesses system table or sys.dm_exec_request DMV.

When a Resource Semaphore receives a new request, it first checks if any query is waiting or not. If it finds one, it puts the new query in the queue because the wait queue is designed on a first-come-first-served basis with a small weighting to favor small queries. Resource Semaphore attempts to grant memory when there is no waiting query or when a query returns reserved memory. If it finds enough memory, then the requested memory is granted and the query can start running and if it does not find enough free memory to grant the requested memory then it puts the current query into the waiting queue with a RESOURCE_SEMAPHORE wait type and your server starts facing memory pressure.

2，使用sys.dm_exec_query_memory_grants 和 sys.dm_exec_query_resource_semaphores 查看memory grant更详细的信息

DMV:sys.dm_exec_query_memory_grants

Returns information about the queries that have acquired a memory grant or that still require a memory grant to execute. Queries that do not have to wait on a memory grant will not appear in this view.

DMV:sys.dm_exec_query_resource_semaphores

Returns the information about the current query-resource semaphore status in SQL Server. sys.dm_exec_query_resource_semaphores provides general query-execution memory status and allows you to determine whether the system can access enough memory. This view complements memory information obtained from sys.dm_os_memory_clerks to provide a complete picture of server memory status. sys.dm_exec_query_resource_semaphores returns one row for the regular resource semaphore and another row for the small-query resource semaphore.

A typical debugging scenario for query time-out may look like the following:

• Check overall system memory status using sys.dm_os_memory_clerks, sys.dm_os_sys_info, and various performance counters.

• Check for query-execution memory reservations in sys.dm_os_memory_clerks where type = 'MEMORYCLERK_SQLQERESERVATIONS'.

• Check for queries waiting for grants using sys.dm_exec_query_memory_grants.

• Further examine memory-intensive queries using sys.dm_exec_requests.

• If a runaway query is suspected, examine the Showplan from sys.dm_exec_query_plan and batch text from sys.dm_exec_sql_text.

Queries that use dynamic management views that include ORDER BY or aggregates may increase memory consumption and thus contribute to the problem they are troubleshooting.

The Resource Governor feature enables a database administrator to distribute server resources among resource pools, up to a maximum of 64 pools. Beginning with SQL Server 2008, each pool behaves like a small independent server instance and requires 2 semaphores. The number of rows that are returned from sys.dm_exec_query_resource_semaphores can be up to 20 times more than the rows that are returned in SQL Server 2005.

DMV:sys.dm_os_memory_clerks

Returns the set of all memory clerks that are currently active in the instance of SQL Server.

The SQL Server memory manager consists of a three-layer hierarchy. At the bottom of the hierarchy are memory nodes. The middle level consists of memory clerks, memory caches, and memory pools. The top layer consists of memory objects. These objects are generally used to allocate memory in an instance of SQL Server.

Memory nodes provide the interface and the implementation for low-level allocators. Inside SQL Server, only memory clerks have access to memory nodes. Memory clerks access memory node interfaces to allocate memory. Memory nodes also track the memory allocated by using the clerk for diagnostics. Every component that allocates a significant amount of memory must create its own memory clerk and allocate all its memory by using the clerk interfaces. Frequently, components create their corresponding clerks at the time SQL Server is started.

参考文档：
https://www.mssqltips.com/sqlservertip/2827/troubleshooting-sql-server-resourcesemaphore-waittype-memory-issues/ https://msdn.microsoft.com/en-us/library/ms365393.aspx https://msdn.microsoft.com/zh-cn/library/ms366321(v=sql.120).aspx
http://blog.csdn.net/dba_huangzj/article/details/8475044