This post has been republished via RSS; it originally appeared at: Azure Database Support Blog articles.
Today, we got a service request that our customer reported that they query are taking too much for their execution. The main wait stats found was RESOURCE_SEMAPHORE and I would like to share with you my lessons learned here.
We executed this query to find out the queries and check the resource semaphore wait type.
We found that 4 processes are waiting for memory available to perform the operation.
During the execution of the queries to verify that the issue is regarding about memory resource, I executed the following query to check if the 4 request that are waiting for memory.
- As Azure SQL DB and MI is working use resource governor, I used the query resource semaphore with union of resource pools to determine if the pool of the user.
- So, it is SloSharedPool1 that represents the resources assigned to my database and resource_semaphore_id=0 represent memory for large queries.
- So, all points to that our customer is running queries that are involved many resources, like sorts, and many of them are waiting for a high amount of memory, as you could see in the below picture in the memory grant option of the execution plan.
So, my lessons learned is RESOURCE_SEMAPHORE wait type is a memory related wait type that shows when a query memory request cannot be assigned/granted immediately. This occurs on databases that are under memory pressure either great number of queries that are running concurrent or few queries for large tables with expensive operations like sort or joins, for example.
To lower this RESOURCE_SEMAPHORE obviusly increasing the number of vCores will allow us to have memory memory, but, other topics that we applied to reduce this was:
- Review the execution plan for the queries that are using large sorts and joins to reduce the number needed.
- Add an index to the table where the sort is performing.
- Review the value of MAXDOP.
- Review the option to use an Indexed View.