Monday Morning Mistakes: Not Setting Memory Limits

Welcome back to another addition of Monday Morning Mistakes series. Today’s issue is one I tend to run into quite often with clients and is an important topic to know about as a database administrator. Without further ado, let’s get to our issue

Issue

You have SQL Server database engine installed on a system with other services such as Analysis Services, Reporting Services and/ or Integration Services and you constantly seem to run out of memory. Restarting service seems to fix the issue temporarily but some time later the same problem returns.

Solution

Always ALWAYS set max memory options for your SQL Server-related services! Setting a hard set maximum keeps your systems from “running away” with memory and causing unexpected performance issues in your environment. This becomes especially important in environments where you’re running multiple services on the same server. In a nutshell here is a breakdown of the different SQL Server services and how they utilize memory by default (read also: running with default settings in relation to memory). The two biggest problem children, in regards to memory configuration, are the database engine service and Analysis Service. Although those two are the most commonly misconfigured, I’ve outlined all four services below.

Database Engine (aka SQL Server service)

By default, the Max Server Memory (MB) setting is set to 2147483647. This is one of the first things you want to change upon a new install of SQL Server! In layman’s terms this default setting tells SQL Server it can essentially take up all of the physical memory on the server for use by the SQL Server buffer pool. Notice I said buffer pool and not SQL Server in total? Pre SQL Server 2012, this setting really is setting max memory for the buffer pool but folks have come across instance where they set the max memory setting and yet SQL Server shows it’s actually using more memory than that. Starting with SQL Server 2012, this setting actually dictates how much SQL Server (buffer pool + everything else) can use so it’s less confusing. See this post by Jonathan Kehayias (Blog | Twitter) for more details on what the max memory setting truly means: http://sqlblog.com/blogs/jonathan_kehayias/archive/2009/08/24/troubleshooting-the-sql-server-memory-leak-or-understanding-sql-server-memory-usage.aspx

Best practice suggests setting this value instead to 80% of physical memory on a server that only has the database engine running. You will need to use smaller percentage if box is sharing resources with other services. Please note this 80% rule is flexible as systems with larger amounts of memory you can increase that percentage. As an example, in the figure below you can an example where I’ve set the max memory for a system with 8GB of RAM and running only the SQL Server database engine on the box. For a great guide on setting max server memory for the engine service see Glenn Berry’s (Blog | Twitter) post on the matter: http://sqlserverperformance.wordpress.com/2009/10/29/suggested-max-memory-settings-for-sql-server-20052008/

Analysis Services (SSAS)

This one is really interesting as many folks install SQL Server Analysis Services (SSAS) without realizing what the configurations involved are/do. In a default installation of Analysis Services, the service’s value for LowMemoryLimit is set to take 65% of physical memory by default. Now granted this service does not suck up this much at startup (that value is controlled by PreAllocate property) but if you were to use Analysis Services while running the engine on the same box, Analysis Service will not start freeing up memory until this minimum is reached. Up until that point, any memory used by Analysis Service is exclusive to it. If you’re installing multiple services on the same server, you’ll want to not only set the minimum memory setting here, but you’ll also want to set the TotalMemoryLimit and HardMemoryLimit. Your HardMemoryLimit is really the important one you want to configure as that is the percentage at which SSAS will start denying user and system requests due to memory pressure (essentially an out of memory error). For administrators, a must-read guide for Analysis Services is the SQL Server 2008 R2 Analysis Services Operations Guide. It’s lengthy at 108 pages but you can jump to section 2.3 (Memory Configuration) to get the full details on these settings and how they function.

Reporting Services (SSRS)

SQL Server Reporting Services (SSRS) memory settings can be configured but it’s not as straight forward as the other services are. In order to configure SSRS you need to modify an XML configuration file (rsreportserver.config). In a default installation, this file is located at C:Program FilesMicrosoft SQL ServerMSRS10_50.MSSQLSERVERReporting ServicesReportServer. Please note that path could change depending on what version of SQL Server you’re running, if you’re running 64 or 32 bit installation, and what drive/folder path you’ve installed your services on. If you have trouble locating it, simply do a search on your file system for the rsreportserver.config file.

SSRS, like Integration Services, is typically benign in regards to memory usage. However if you have an environment where it gets utilized heavily, especially on a system that is sharing resources with multiple services, then you may want to tweak these settings. For best practices regarding Reporting Services configurations I suggest you look at the whitepaper from SQLCAT team on Scale-Out Deployments for Reporting Services Best Practices.

Integration Services (SSIS)

Unfortunately this service’s memory usage actually can’t be configured like the other services can. Instead optimization needs to occur at the package level. Having the SSIS service installed alongside the database engine service is quite common and usually doesn’t cause too much issue so long as all the other services are configured optimally. You can read more about SSIS Design and Performance Tuning http://sqlcat.com/sqlcat/b/presentations/archive/2009/05/02/designing-and-tuning-for-performance-your-ssis-packages-in-the-enterprise-sql-video-series.aspx or watch a free webinar from Pragmatic Works on SSIS Performance Tuning: http://pragmaticworks.com/resources/webinars/WebinarSummary.aspx?ResourceID=265

Conclusion

Remember this post is to help those who have multiple services (or even all the services) running on the same server. Best practice dictates that for best performance you’d want to segregate one or all services to their own servers, but make sure you do what makes sense for your environments. Best practices aren’t necessarily one size fits all* so make sure you do your homework!

*Unless that best practice dictates not to auto-shrink your databases. Seriously, don’t shrink your databases, please think of the kittens.