Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

One of the servers I have been performance monitoring started throwing the following warnings from the Resource-Exhaustion-Detector:

Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: sqlservr.exe (1560) consumed 14960812032 bytes, ReportingServicesService.exe (1936) consumed 506359808 bytes, and w3wp.exe (7376) consumed 273764352 bytes.

SystemCommitLimit 38068215808 SystemCommitCharge 37800669184 ProcessCommitCharge 16727490560 PagedPoolUsage 359088128 PhysicalMemorySize 17098584064 PhysicalMemoryUsage 16881131520 NonPagedPoolUsage 221425664 Processes 48

This server is windows server 2008, running MSSQL 2008 R2, has 16GB of RAM, and 24 processors. It runs SQL, and a web service that accesses SQL for Data.

The numbers that I included in the quote are from the details section of the event viewer. I have not been able to identify a root cause. I already know SQL needs a lot of memory to function, and it was using a lot of memory at the time, but I also had the cap set to 14000MB.

SQL began getting the Out of Memory error in addition to the Resource-Exhaustion-Detector warnings.

What would the best approach to finding the root cause of this be? I haven't seen anything that looks out of the ordinary in the logs. After a few hours of this error repeating over and over, the memory finally ran out and services started to fail until the service had to restart.

Isn't SQL smart enough to relinquish some of it's memory when there is pressure? The Page File (Virtual Memory) was 20GB, and SQL was only using 16GB of physical memory. What was filling up the rest of the Virtual Memory? Was SQL actually using all of that page file?

Should I be looking for a memory leak? Log file growth?
The .mdf used the most on the server grows about 100mb every day. The Log file has been growing by 3gb at a time as is now 40gb.

Usually when there is memory pressure, we've never gotten to the point where the server just crashes. It usually just runs painfully slow until the pressure is gone.

Is there a way to effectively stop this issue from occurring?

share|improve this question
What is the SQL server maximum memory setting configured for? – Greg Askew Jul 17 '13 at 19:02
Yeah. Smells like the root cause is a configuration error. If you use other things than SQL on the same machine, limit the amount of memory SQL uses as buffer cache to a sensible value. Failure to hire someone with basic knowledge is the root cause. – TomTom Jul 17 '13 at 19:11
@Greg, Max memory was 14000MB at the time of the crash. Increased to 24000MB afterwards. – meltdownmonk Jul 17 '13 at 20:39
@TomTom can you explicitly reference the buffer cache size? – meltdownmonk Jul 17 '13 at 20:40
@meltdownmonk: if you have 16 GB memory, why would you configure the setting for 24GB? – Greg Askew Jul 17 '13 at 23:38
up vote 1 down vote accepted

To properly diagnose this, we need more information.

SQL server is like any other Windows process; it's virtual address space can be far larger than physical RAM. It can even be larger than RAM + paging files, if any part of it uses memory mapped files.

The tuning parameter in SQL server is a way to tell it to never use more than 'x' MB. You have to look at the peak commit charge of all other services on the box, subtract this from your physical RAM figure, and then give the remainder to SQL Server. As far as I'm aware, the memory cap only applies to the RDBMS, not the menagerie of related SQL server services. I could be wrong here.

So, we'd need more figures for the remaining processes. For example, you've got an IIS worker process consuming 273MB; is there just one worker process? Do you have anti-virus or backup software installed?

You could use WSRM to profile what's going on, and then consider applying memory caps. Alternatively, and it'd be my recommendation, install more RAM.

To get a graphical view of where your memory is going, have a nose at Microsoft SysInternals' RAMMap utility.

share|improve this answer
Virtual address space is always larger than physical on windows 64. You need to look at the working set to see what's actually being used – Jim B May 8 '15 at 17:05

Is there a way to effectively stop this issue from occurring?

The glib answer would be to suggest you buy more memory. That might not solve your problem, but it probably wouldn't hurt.

SQL Server likes memory. SQL Server likes to cache your database, or chunks of your databases, in memory so they'll be accessed faster. If you want to see what's in your memory right now, you can get that information out of the DMV: One of my coworkers once received a vendor recommendation that database size for their product's DB never exceed the size of the server's memory. That's impractical for most people, but if you're trying to serve up a heavily queried 10TB database with 16GB of RAM, that might be a problem.

Try running sp_blitz on your server--it's a stored procedure that checks your server for problems.

Also try perfmon:

That should help you track down the cause.

share|improve this answer

You may need to increase your Pagefile size, to be able to handle intermittent spikes in the memory commit size. We have this issue often in Azure compute where Pagefile is set WAY too low by default for memory-intensive apps.

You can read more here:

This will not solve the problem if your SQL instance needs a lot more memory than you have, but it could help weather the temporary spikes better.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.