Dm_exec_query_memory_grants, Is_next_candidate, wait_order whilst is under memory pressure question

Question

I have several spids which are in resource_semaphore wait state as there is an active query consuming a lot of memory.
When I check dm_exec_query_memory_grants I can see that is_next_candidate=1 spid is requesting more memory than is available (hence resource semaphore) but there are spids that are also waiting who are requesting an amount of memory that is less than the
available amount and these should be able to run but (I assume) because they are not is_next_candidate that they have to wait in a resource_semaphore state.
Is there anything we can do to ensure that queries that can run will run before queries so that queries that are waiting on resource_semaphore do not block them?
example - the spid's in wait order position 2 and 3 below are stuck in resource_semaphore despite 700000 kb of memory available

Answer 1

Resource Semaphore checks for waiting query in its queue. If it finds one, it puts the new query into a wait queue for fairness, because the wait queue is designed as first-come-first-served basis with small weight to favor small queries.
Do you happen to know if the weighting is configurable or what this weighting is called so I can further investigate? 
That is internal mechanism and I dont think there is option to control it but I am not sure. Even if it is there I would not recommend to use it. The whole problem of memory grant can arise because of two condition
1. Insufficient memory
2 Poor query with outdated stats forcing optimizer to build a plan which sees more memory requirement.
I would still say find out queries(s) taking huge memory grants. Generally outdated stats and poorly written query causes semaphore waits. look at query plan on extreme left side click on first operator and it would show memory grants.
Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it
My Technet Wiki Article
MVP