Home Dashboard Directory Help
Search

(SSMS) SQL Server Management Studio does not release memory by Chris Leonard


Status: 

Closed
 as Won't Fix Help for as Won't Fix


4
1
Sign in
to vote
Type: Bug
ID: 531283
Opened: 2/5/2010 8:47:40 AM
Access Restriction: Public
0
Workaround(s)
view
3
User(s) can reproduce this bug

Description

After working in SSMS all day, task manager reported about 250MB of memory in use ("Mem Usage") by the program. At the time I had 10 query windows open, none of which had overly large scripts (total size of the scripts was about 45k) or large result sets. There were no connections open in the Object Explorer tree.

My system was under memory pressure, so I wanted to reclaim memory. I saved all of my scripts as I was ready to move on to other projects and closed all the query windows. Task manager reported no change in memory usage by SSMS. I waited several minutes, but no memory was released. I started a new query window, and about 20MB of memory was released.

At this point I restarted SSMS, and it has been sitting idle for over 10 minutes now with memory usage reported at 80 MB. So my first question is, why didn't memory usage go back down to 80 MB when I closed all those query windows?

This happens to me every day - I've just never asked about it before. Every day I have to restart SSMS to get it to release memory that it holds onto even if I close all my query windows. It looks like something might be wrong with SSMS memory management.

I am running SSMS 2008 (10.0.2531.0) on Windows XP Pro Version 2002 Service Pack 3.
Details
Sign in to post a comment.
Posted by Microsoft on 6/10/2011 at 1:52 AM
Hi:

We took a look at this bug along with several others recently. Unfortunately, triaging it against other critical bugs, I do not think we would get to investigating this in the near future. However, we have taken note of this internally, and when we revisit this functionality in the future, we will try and get this resolved.

Thanks for writing in to Microsoft.

Cheers,

Chandramouli | Program Manager | SQL Server Manageability
Posted by AaronBertrand on 2/6/2010 at 8:40 AM
As an aside, I did some experimenting with this. I opened SSMS, and Task Manager showed 44MB.

Then I opened a query window, and it jumped to 62MB.

When I closed the query window, it dropped to 60MB.

I opened three new query windows, and it jumped to 66MB.

When I closed these query windows, it dropped back to 61MB.

I opened 10 new query windows, it jumped to 72MB.

When I closed these query windows, it dropped back to 64MB.

So clearly, while some of the memory is not being released, some of it is...
Posted by AaronBertrand on 2/6/2010 at 8:33 AM
Not all of the memory is used just by query windows. Think about things you have on the clipboard, undo/redo stack, IntelliSense, any memory used by add-ins, Object Explorer trees, basically everything you do in SSMS requires some memory usage that isn't just going to disappear by closing a query window. Some of this stuff stays resident in memory intentionally, so that you're not constantly pulling these things in and out of memory (the goal being a smoother and quicker user experience). At the cost of a little RAM? Sure.

What you're complaining about is kind of like shrinking a file that you know is going to grow to re-use the space anyway. If you peak at 250 MB, what is the advantage of reducing memory usage to 80 MB, if it is just going to grow back to 250 MB again? What are you going to do with "all that memory" in the meantime? If you're not going to be using it for SSMS work, then I agree with what you call a workaround: close SSMS. This is not a huge delta in memory IMHO, and at the price of RAM these days, I'd say you'd get a much quicker "fix" by adding a stick or two to your machine if this "hogging" of memory is really having an impact on your experience. My guess is that it is not affecting your work but you are just annoyed when looking in Task Manager. I get much more annoyed when I look in Task Manager and I see 40 different copies of svchost.exe, a lot of them using more memory than SSMS ever will.
Sign in to post a workaround.