Adhering
to the SQL Server requirements will improve your chances of a
successful deployment of SharePoint. However, if you choose to adhere
to the recommendations and not just the requirements, you can also
improve the performance of SharePoint. Making changes within SQL Server
can improve your SharePoint performance significantly.
After successfully installing a
SQL Server instance to host your SharePoint content, you can make
several configuration changes to optimize the SQL Server instance.
These changes will ultimately improve performance for both SQL Server
and SharePoint 2010. This section discusses the following types of
changes in SQL Server.
SQL Server memory settings
Database file locations
Model database default settings
Database recovery model
Tempdb fast drives and 10 percent size of total content database size
Each of these SQL
Server settings can affect your SharePoint 2010 experience and make a
positive impact on your users’ SharePoint interaction.
1. SQL Server Memory Settings
SQL Server is a
memory-intensive application, and by default it is selfish when it
comes to memory utilization. In fact, SQL Server has two primary uses
of memory: buffer cache (sometimes called data cache) and procedure cache.
Buffer cache holds
data pages in memory so that frequently accessed data can be retrieved
from it. Otherwise, you would have to retrieve the data pages from
disk, slowing performance. Reading data pages from the cache optimizes
performance by minimizing the number of required input/output (I/O)
operations, which are inherently slower than retrieving data from
memory.
Procedure cache holds the
stored procedure and query execution plans to minimize the number of
times the query plans have to be generated.
Both of these caches are
important, but as you allocate more memory for SQL Server, most of it
goes to the buffer cache, helping reduce the round trips to the disk
for data.
To determine if you have the appropriate amount of random-access memory (RAM) allocated to your SQL Server instance, you can monitor the following two SQL Server performance counters.
SQL Server:Buffer Manager – Buffer Cache Hit Ratio Percentage of pages found in the DATA buffer without having to read from disk (good > 95%)
SQL Server:Cache Manager – Cache Hit Ratio Percentage of pages found in the PROCEDURE cache without having to read from disk (good > 85%).
By default,
each SQL Server instance changes its memory requirements dynamically
based on available system resources. This default setting can have a
major impact on the operating system and on other applications,
including other instances of SQL Server running on the same server.
When SQL Server is using memory dynamically, it queries the system
periodically to determine the amount of free physical memory and takes
as much as needed to complete the task at hand. However, you can
control how SQL Server uses memory after you install SQL Server by
configuring two SQL Server server memory configuration options: min
server memory and max server memory.
1.1. Default Memory Settings
The min server memory option
is used to define how much memory to release back to the operating
system when it is not being used. The SQL Server default setting for
min server memory is 0 MB, which means it releases all requested memory
back to the operating system if it is no longer needed. SQL Server does
not immediately allocate the amount of memory specified in min server
memory on startup. Use min server memory to guarantee a minimum amount
of memory available to the buffer pool of an instance of SQL Server.
Note:
When memory usage has
reached this value due to client load, SQL Server cannot free memory
from the allocated buffer pool until the value of min server memory is
reduced.
The max server memory option
is used to define the maximum amount of memory a specific SQL Server
instance can access if needed. The default setting for max server
memory is 2147483647 MB, which means it will request as much memory for
the buffer pool as needed without regard to the performance of the
server. Although allowing SQL Server to use memory dynamically is
recommended, you should configure these memory options manually and
restrict the amount of memory that SQL Server can access.
|
Before you set the amount of memory for SQL
Server, you need to determine the appropriate memory setting. You do
this by determining the total available physical memory and then
subtracting the memory required for the operating system, any other
instances of SQL Server, and other system uses, if the computer is not
wholly dedicated to SQL Server.
There are two principal methods for setting the SQL Server memory options manually.
Set the min server memory and max
server memory options to the same value, which corresponds to a fixed
amount of memory allocated to the SQL Server buffer pool after the
value is reached. Set
the min server memory and max server memory options to create a memory
range. This is useful when system or database administrators configure
an instance of SQL Server that is running in conjunction with other
applications on the same computer like Exchange or any other line of
business applications.
|
1.2. Running Multiple Instances of SQL Server
When running multiple instances
of the SQL Server on one server, there are three approaches you can use
to manage your physical memory.
Use the max server
memory option to control memory usage. Establish maximum settings for
each instance, being careful to ensure that the total allowance is not
more than the total physical memory on your server. Try to give each
instance an amount of memory that is proportional to its expected
workload or database size.
Use the min
server memory option to control memory usage. Establish minimum
settings for each instance so that the sum of these minimums is 1 to 2
GB less than the total physical memory on your server. Again, try to
establish these minimums proportionately to the expected load of the
instance. Using this approach has the advantage of allowing instances
that are running to use the remaining free memory if all of the
instances are not running at the same time.
Do
nothing. This approach is not recommended, however, because the first
instances presented with a workload will tend to allocate all the
memory. Instances started later or that are idle may run with only a
minimal amount of memory available. SQL Server makes no attempt to
balance memory usage across instances.
Note:
You can change these
settings without restarting the instances, so you can easily experiment
to find the best settings for your usage pattern.
After you decide what the new min server memory and max server memory settings should be, you can use the Memory page of the SQL Server Instance properties as shown in Figure 1 to modify the default settings to reflect your calculated settings. These two options can also be configured using the sp_configure stored procedure.
