I know it's not good practice to do this, but my company cannot afford me trying to find a proper solution to our problem. I've read this and I could do the same with SQL Server 2005, but I was hoping there could be a better (quicker?) way.
The problem is as follows:
We have an ASP.net website (ASP2) running on Windows Server 2003 which also hosts our SQL Server 2005 database and install.
Lately we've noticed the VM Committed memory space for our SQL Server 2005 instance grows and it's almost at the point of VM Reserved space which we've set at 1.7 GB (hmm too much?).
The PC server our SQL Server is running on has 4 GB of RAM and up to 3.5 GB of free disc space for the SQL Server 2005 installation. The database itself is on a 350 GB share (there are two partitions for this: C and D drive respectively).
So in terms of VM space, I would have thought we have enough space and having set our VM limit to 1.7 GB (ideally 2 GB) would have sufficed.
The database itself is under 500 MB in size.
The service slows down considerably when our VM Committed value gets close to the VM Reserved value. The only way I know to bring this down is to stop all SQL Service services and re-start them again. But within 24 hours, the VM Committed still creeps up!
Is there a way I can just bugger trying to find the cause of the problem, but simply do a re-start of all the services overnight automatically? Or should I really be trying to find the cause of our problem?
I did some investigation (but as I said we're time poor at the moment), and found this SQL query (see below), which tells me what actual query seems to hog the CPU the most (not sure if this has anything to do with my original VM problem above).
It shows one query that just so happens to run overnight, and it could be that this query is simply hogging memory and not releasing it back to the pool?
Is there a way to "close" threads/memory allocation etc in SQL Server so that memory is freed back?
Here is the CPU "hog search" query (courtesy of this)
select
highest_cpu_queries.plan_handle,
highest_cpu_queries.total_worker_time,
q.dbid,
q.objectid,
q.number,
q.encrypted,
q.[text]
from
(select top 50
qs.plan_handle,
qs.total_worker_time
from
sys.dm_exec_query_stats qs
order by qs.total_worker_time desc) as highest_cpu_queries
cross apply sys.dm_exec_sql_text(plan_handle) as q
order by highest_cpu_queries.total_worker_time desc
Edit, answers to Pathum's questions:
Results from running the query:
----------------------------------------------------------------------------------------------------
Memory usage details for SQL Server instance SERVER9 (9.00.4053.00 - X86) - Standard Edition)
----------------------------------------------------------------------------------------------------
Memory visible to the Operating System
Physical Memory_MB|Physical Memory_GB|Virtual Memory GB 4091|4|2
Buffer Pool Usage at the Moment
BPool_Committed_MB|BPool_Commit_Tgt_MB|BPool_Visible_MB
519.250000|1599.875000|1599.875000
Total Memory used by SQL Server Buffer Pool as reported by Perfmon counters
Mem_KB|Mem_MB|Mem_GB 531712|519.250000|0.507080078
Memory needed as per current Workload for SQL Server instance
Mem_KB|Mem_MB|Mem_GB 1638272|1599.875000|1.562377929
Total amount of dynamic memory the server is using for maintaining connections
Mem_KB|Mem_MB|Mem_GB 560|0.546875|0.000534057
Total amount of dynamic memory the server is using for locks
Mem_KB|Mem_MB|Mem_GB 968|0.945312|0.000923156
Total amount of dynamic memory the server is using for the dynamic SQL cache
Mem_KB|Mem_MB|Mem_GB 1120|1.093750|0.001068115
Total amount of dynamic memory the server is using for query optimization
Mem_KB|Mem_MB|Mem_GB 552|0.539062|0.000526428
Total amount of dynamic memory used for hash, sort and create index operations.
Mem_KB|Mem_MB|Mem_GB 0|0.000000|0.000000000
Total Amount of memory consumed by cursors
Mem_KB|Mem_MB|Mem_GB 480|0.468750|0.000457763
Number of pages in the buffer pool (includes database, free, and stolen).
8KB_Pages|Pages_in_KB|Pages_in_MB 66464|531712.000000|519.250000000
Number of Data pages in the buffer pool
8KB_Pages|Pages_in_KB|Pages_in_MB 50135|401080.000000|391.679687500
Number of Free pages in the buffer pool
8KB_Pages|Pages_in_KB|Pages_in_MB 895|7160.000000|6.992187500
Number of Reserved pages in the buffer pool
8KB_Pages|Pages_in_KB|Pages_in_MB 0|0.000000|0.000000000
Number of Stolen pages in the buffer pool
8KB_Pages|Pages_in_KB|Pages_in_MB 15434|123472.000000|120.578125000
Number of Plan Cache pages in the buffer pool
8KB_Pages|Pages_in_KB|Pages_in_MB 11953|95624.000000|93.382812500
Page Life Expectancy - Number of seconds a page will stay in the buffer pool without references
Page Life in seconds|PLE Status 47011|PLE is Healthy
Number of requests per second that had to wait for a free page
Free list stalls/sec 0
Number of pages flushed to disk/sec by a checkpoint or other operation that require all dirty pages to be flushed
Checkpoint pages/sec 572
Number of buffers written per second by the buffer manager"s lazy writer
Lazy writes/sec 0
Total number of processes waiting for a workspace memory grant
Memory Grants Pending 0
Total number of processes that have successfully acquired a workspace memory grant
Memory Grants Outstanding 0
Second query, checking for memory pressure:
SELECT object_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE counter_name IN ('Total Server Memory (KB)', 'Target Server Memory (KB)');
Results:
object_name|cntr_value
SQLServer:Memory Manager |1638272
SQLServer:Memory Manager |531712
(2 row(s) affected)
My server is 32 bit. We will not be moving to 64 bit for any reason.
Values from
sp_configur
e information cannot be provide, that's confidential. :)