SQLServer RESOURCE_SEMAPHORE 等待状态
2015-03-06 14:39
169 查看
原文:
SQLServer RESOURCE_SEMAPHORE 等待状态
当检查事务的所有等待类型后,可能会发现Resource_semaphore这个等待类型出现非常多,这会增加一些页面的IO等待。因为这些事务没有足够的内存来处理它们的操作,所以到这了页面的IO等待。
请求内存是运行排序和hash连接的所需最少内存,之所谓成为“请求”,是因为查询不需要在一开始就申请这部分的内存。而额外内存是存放临时数据到内存中所需的那部分内存。如果没有足够的内存,查询所需的数据将会存到硬盘当中。
首先,服务器会计算运行特定查询所需要的内存。这部分通常等于请求内存和额外内存的总和。但当实例使用并行执行时,所需的内存为(请求内存*并行度)加上额外内存的总和。服务器会检查是否有足够的内存来运行每个查询,然后会降低额外内存的量,知道所有总内存需求量刚好达到内存的限制量。这部分修改后的内存成为需求内存(requested memory)。在SQLServer内不能,有一个叫Resource Semaphore的设置,用于授予需求内存用于查询。当查询没有得到足够的内存,就会把等待状态改为:Resource_Semaphore。可以从sysprocesses系统表或者sys.dm_exec_request
DMV中查询。
当Resource_semaphore接受一个新的请求时,首先检查是否有查询还在等待中,如果发现有,那么会把这个新请求放到先进先出的队列中,Resource Semaphore会尝试对未等待的查询授予内存,这部分内存可能是之前的查询执行完毕后返回的内存。如果发现有足够的内存,那么就会把内存赋予给处于Resource Semaphore等待状态的查询,让其开始运行。如果不够,那么会把查询放入等待队列并标记为Resource_Semaphore等待。因此,看这个等待状态可以发现内存存在压力。
由于这种情况不好模拟出来,所以没有截图。
我们要关注的是下面3列:
![](http://img.my.csdn.net/uploads/201301/06/1357485358_5959.png)
注意替换括号中的sql_handle。然后查看其执行计划。
SQLServer RESOURCE_SEMAPHORE 等待状态
概述:
当一个SQLServer实例运行得很慢的时候,应该做一些检查,如检查等待状态。最好的方法是一开始就建立一个性能基线,以便做性能对比。当发现与性能基线对比后,存在内存压力的话,就要找出是什么原因导致的。可以检查事务的等待状态,其中Resource_semaphore等待可能出现最多。下面是如何去处理这个问题:当检查事务的所有等待类型后,可能会发现Resource_semaphore这个等待类型出现非常多,这会增加一些页面的IO等待。因为这些事务没有足够的内存来处理它们的操作,所以到这了页面的IO等待。
Resource_semaphore等待:
首先我们来弄清楚一下什么是Resource_semaphore等待。当SQLServer收到一个用户请求(或者查询时)。首先会创建一个编译后的计划,然后在这个基础上创建一个执行计划。当SQLServer创建一个编译后的计划时,它会计算两个内存授予参数,成为:请求内存(required memory)和额外内存(additional memory)请求内存是运行排序和hash连接的所需最少内存,之所谓成为“请求”,是因为查询不需要在一开始就申请这部分的内存。而额外内存是存放临时数据到内存中所需的那部分内存。如果没有足够的内存,查询所需的数据将会存到硬盘当中。
首先,服务器会计算运行特定查询所需要的内存。这部分通常等于请求内存和额外内存的总和。但当实例使用并行执行时,所需的内存为(请求内存*并行度)加上额外内存的总和。服务器会检查是否有足够的内存来运行每个查询,然后会降低额外内存的量,知道所有总内存需求量刚好达到内存的限制量。这部分修改后的内存成为需求内存(requested memory)。在SQLServer内不能,有一个叫Resource Semaphore的设置,用于授予需求内存用于查询。当查询没有得到足够的内存,就会把等待状态改为:Resource_Semaphore。可以从sysprocesses系统表或者sys.dm_exec_request
DMV中查询。
当Resource_semaphore接受一个新的请求时,首先检查是否有查询还在等待中,如果发现有,那么会把这个新请求放到先进先出的队列中,Resource Semaphore会尝试对未等待的查询授予内存,这部分内存可能是之前的查询执行完毕后返回的内存。如果发现有足够的内存,那么就会把内存赋予给处于Resource Semaphore等待状态的查询,让其开始运行。如果不够,那么会把查询放入等待队列并标记为Resource_Semaphore等待。因此,看这个等待状态可以发现内存存在压力。
识别Resource_Semaphore等待:
步骤1:
执行以下语句,并筛选Resource_Semaphore等待的数据:SELECT * FROM sys.SYSPROCESSES WHERE lastwaittype = 'RESOURCE_SEMAPHORE' ORDER BY lastwaittype
由于这种情况不好模拟出来,所以没有截图。
步骤2:
从步骤1中得到的结果,可能会看到很多的事务处于ResourceSemaphore 等待状态,现在可以运行下面语句来查看已分配到内存的查询的目前状态,和未被分配内存的查询的数量。这个DMV会返回两行,一行是resource_semaphore_id为0的大查询,另外一些是为1的小查询,这里的小是内存小于5M。在这里可以获得总授予内存和实例上总可用内存。可以查看grantee_count和waiter_count,grantee_count是已经分配了内存的总查询数量,而waiter_count是在队列中等待授予内存的总查询数量:SELECT * FROM sys.dm_exec_query_resource_semaphores
步骤3:
然后使用DMV:sys.dm_exec_query_memory_grants来获得在等待队列中的查询所需要内存的详细信息。这些查询的grant_time和granted_memory_kb可能为null。也可以从这个DMV中得到plan_handle和sql_handle:SELECT * FROM sys.dm_exec_query_memory_grants
我们要关注的是下面3列:
![](http://img.my.csdn.net/uploads/201301/06/1357485358_5959.png)
步骤4:
现在将要找到集中消耗内存的查询,可以查看所有等待查询中的需求内存。当看到这部分内存太大的时候,然后找到这些查询的plan_handle,并查看它们的执行计划:SELECT TOP 10 * FROM sys.dm_exec_query_memory_grants
步骤5:
把步骤4中查询的plan_handle的数据复制,然后执行:SELECT * FROM sys.dm_exec_sql_text(sql_handle)
注意替换括号中的sql_handle。然后查看其执行计划。
总结:
通过上面的步骤找到耗费内存的查询后,应该调整语句,使其占用更少的资源。以便解决内存压力。相关文章推荐
- SQLServer RESOURCE_SEMAPHORE 等待状态
- SQLServer RESOURCE_SEMAPHORE 等待状态
- SQLServer RESOURCE_SEMAPHORE 等待状态
- Troubleshooting SQL Server RESOURCE_SEMAPHORE Waittype Memory Issues
- MS SQL SERVER SUSPECT数据库置疑/可疑状态后处理办法
- Handling workloads on SQL Server 2008 with Resource Governor
- Restricting IO Using SQL Server 2014 Resource Governor
- DBCC大全集之(适用版本MS SQLServer 2008 R2)----DBCC TRACESTATUS显示跟踪标志的状态
- 存储session状态在SQL 服务器的数据库中Storing Session State in a SQL Server Database)
- MS SQL Server 查询数据库最近一次备份状态
- 【SQL Server DBA】日常巡检1:数据库空间、状态、使用的监控
- SQL 2005 Report Server 请求因 HTTP 状态 400 失败: Bad Request 处理方法 的解决方法
- Sql server 日记 (查看Sql server JOB 运行状态)
- 关于SQL SERVER 2008从suspect状态…
- Unable to load SQL Server OLEDB provide resource DLL错误
- 配制SQL Server Session状态,发生ASP帐户无法登录的解决方案.
- 将MS SQL SERVER数据库运行在普通用户(独立用户)状态下的设置方法终结篇
- vc 判断SQLServer/Ftp/IIS服务器状态
- (WSFC) resource control API returned error code 5057 & Microsoft SQL Server, Error: 41009
- Sql Server之旅——第七站 为什么都说状态少的字段不能建索引