How to resolve RESOURCE_SEMAPHORE and RESOURCE_SEMAPHORE_QUERY_COMPILE wait types

Question

We are trying to figure out root cause of slow running sql server queries hitting/fetching data from one of the database , size 300 GB, hosted on server with below configuration:
Windows server 2003 R2, SP2, Enterprise Edition, 16 GB RAM , 12 CPU'S 32 Bit
SQL server 2005, SP4, Enterprise Edition, 32 Bit.
We have already informed business on the upgrade to 64 bit which would take over a month.
But for the current issue, we are trying to gather the data if we can resolve the memory pressure or finally come to a conclusion to increase RAM.
Action Completed: Re-indexing and update stats are proper for this DB.
As shown below, we have been noticing the semaphore waittype for past 5 days, ran during the load hours:
Few info after below queries: size of buffer= 137272
SELECT SUM(virtual_memory_committed_kb)
FROM sys.dm_os_memory_clerks
WHERE type='MEMORYCLERK_SQLBUFFERPOOL'
and semaphore memory= 644024 per below query
SELECT SUM(total_memory_kb)
FROM sys.dm_exec_query_resource_semaphores
Below is some more info gathered from dm_exec_query_resource_semaphores and sys.dm_exec_query_memory_grants dmv's
So from above info gathered and per SP_Blitz data Resource semaphore seems to be the problem.
Is memory 'target_memory_kb' assigned for resource semaphore id's too low, as compared to 16 GB RAM available.
Note* per analysis on 8 hours run 'target_memory_kb' is always under 1 GB, compared to 16 GB available?
what could be the issue here and how to resolve, please suggest
Thanks

Answer 1

I've performed index tuning for those queries, like missing index , rebuilds and stats update.
So is it going to be more worst, after that change of MAXDOP ?
Index and query tuning goes hand-in-hand.  Proper indexes with updated stats alone won't improve performance if queries contain non-sargable expressions or are coded in a suboptimal way.  You need to examine the problem queries and execution
plans in detail to see if performance opportunities exist.  Be aware that SQL Server may throw parallelism to address an issue like a non-sargable query predicate.  The query may run faster as a result but at the cost of more CPU utilization
for the duration of the query that may impact other users.  I suggest changing MAXDOP after query tuning.  You may need to experiment for the most optimal value for your workload.
However, concern would be this one query, which as per developer is just a part of filter in ssrs reports, i.e. small query for the larger query has multiple sessions open for almost a day now.
By smaller query, are you referring to the number of rows returned?  Perhaps the reason is the number of rows actually touched.  Post the query, DDL and execution plan.
Dan Guzman, SQL Server MVP, http://www.dbdelta.com