Share via

Best practices for operational excellence (SharePoint Server 2010)

  • Article

 

Applies to: SharePoint Server 2010, Excel Services

Microsoft SharePoint Server 2010 is used for a broad set of applications and solutions, either stand-alone or in concert with other systems. To achieve this flexibility, the platform supports lots of possible architectures and configurations. Some parts of the system are well-known, but we still see variances to these parts. This article focuses on the top configuration best practices that you should consider, such as front-end Web server configuration, database configuration, servicing, and patching.

This article is one of a series of best practices articles for SharePoint Server 2010. This article describes best practices for operational excellence. For more articles in the series, see Best practices (SharePoint Server 2010). For additional information and resources about Best Practices for SharePoint Server 2010, see the Best Practices Resource Center (https://go.microsoft.com/fwlink/p/?LinkId=221383).

1. Use lots of memory, and fast network adapters

To get the performance you want from an environment, make sure that you use lots of memory on the Web and application servers.

Network speed is also important for performance of the environment. Take the following actions to make network traffic move quickly:

  • Use gigabit network adapters for all server roles.

  • For front-end Web servers and application servers, use dual network adapters in production environments. Use one network adapter for users and one for Microsoft SQL Server communication.

  • Use private network adapters for inter-server communications for tasks such as management and backups so that this traffic does not affect the overall farm performance.

  • Under heavy load, consider using virtual local area networks (VLANs) to reduce network traffic.

For more information, see Hardware and software requirements (SharePoint Server 2010) and Performance and capacity management (SharePoint Server 2010).

2. Stay close: Do not put too much network distance between front-end Web servers, application servers, and database servers

No front-end Web server or application server should have more than one millisecond (ms) of latency between it and the database server. In practice, this generally means that you should keep all the servers in a farm in the same data center. All servers in a farm must be in the same time zone.

For more information, see Global solutions for SharePoint 2010 Products (model).

3. Consider performance and availability when you configure Web servers and application servers

The way that you configure Web servers and application servers can have a big effect on throughput and availability. Follow the following recommendations for best results:

  • Separate system components into logical drives and use RAID for redundancy.

    Components on drive Recommended RAID level

    Windows and program files drive

    RAID 1

    Operating system swap drive and temp directory

    RAID 1

    Log files

    RAID 1

    Boot disk for imaging and Windows Desktop Search (optional)

    RAID 1

  • Use at least four physical disks and use separate disks to keep the log files and swap drive separate from the Windows and program files drive.

  • In most production environments, we recommend that you allocate at least 200 GB of disk space for the operating system and temporary files and 150 GB of disk space for logs.

  • Be sure to test the Web server capacity and provide sufficient servers for the number of users and requests that are in the farm. For high availability, make sure that you allocate an additional server so that you can pull one server out of a network load-balancing server farm and recycle it without affecting service availability.

For more information, see the following resources:

4. Consider performance and availability when you configure database servers

As is also the case with Web servers and application servers, the configuration for database servers affects how well SharePoint Server 2010 performs. Certain databases require specific co-location with or separation from other databases. For more information, see Data scale in the Capacity management and sizing overview for SharePoint Server 2010 article and Storage and SQL Server capacity planning and configuration (SharePoint Server 2010).

The databases listed in the following table should be kept separate from other databases.

Database name Size Read/write optimization Co-location

TempDB

Medium

Must be on a separate spindle from all other databases.

Secure Store

Small

Host on a separate database instance. Limit access to one administrator.

Search Crawl

Extra large

Optimize for read

This is a large-scale database. Host on a separate server from the Search Property database.

Search Property

Large to extra large

Optimize for write

This is a large-scale database. Host on its own server.

Usage

Extra large

Optimize for write

Must be on a separate spindle.

Note

The usage database can be on a separate server, and does not need performance to be as high as other databases. The speed of the usage database does not affect the performance of the site.

The databases in the following table must be stored in the same location as other databases.

Database name Size Co-location

Configuration

Central Admin content

Small

Must be located together

SQL Server ReportServer

ReportServerTempDB

Small

Varies

Must be on the same database server

More information about database sizing and read/write mix for specific databases is available in the Databases That Support SharePoint 2010 Products model(https://go.microsoft.com/fwlink/p/?LinkId=187970).

5. Keep it clean: Maintain databases in a healthy state

A healthy database server has enough headroom for databases and log files, plus enough capacity to keep up with requests. Use the recommendations in the following list to keep database servers performing optimally.

  • Pre-grow all databases and logs if you can. Be sure to monitor the sizes so that you do not run out of disk space.

  • Do not overload database servers by using too many databases or data. Use the following guidelines:

    • When you use SQL Server mirroring, do not store more than 50 databases on a single physical instance of SQL Server .

    • Limit content databases to 200 GB.

  • Defragment and rebuild indices daily, if you can absorb the downtime required to rebuild.

  • Monitor the database server to make sure that it is responding correctly and is not overloaded. Key performance counters to monitor include the following:

    • Network Wait Queue: at 0 or 1 for good performance

    • Average Disk Queue Length (latency): less than 5 ms

    • Memory used: less than 70 percent

    • Free disk space: more than 25 percent

    • Buffer cache hit ratio: 90 percent or better

For more information, see the following resources:

6. Keep servers current by using the latest updates

It is important to keep current by applying the latest hotfixes, updates, and service packs. These updates contain important product enhancements and improvements. However, make sure that you thoroughly test these updates on the pre-production environments before you apply them to the production environments. Follow the recommended procedure to deploy the updates, including the following:

  • Turn on Windows Update to download updates automatically, but not install automatically.

  • Schedule time to install updates at off-peak hours.

  • For high availability, rotate servers out of service one at a time during the update process.

Make sure that you are patching the BIOS (server computers, controllers, and disks), Windows operating system, Microsoft SharePoint Foundation 2010 and SharePoint Server 2010, and SQL Server.

For more information, see the Updates for SharePoint 2010 Products Resource Center (https://go.microsoft.com/fwlink/p/?LinkID=209614).

7. Use different accounts for different actions

Use appropriate accounts for the Web applications and services. All accounts should be domain accounts. (Reminder: Do not use Network Service.) For best results, use separate accounts for the following:

  • Web applications: Use different accounts based on your security requirements.

  • Search account: Use one account for the farm.

  • Excel Services account: Use one account for external connections.

For more information, see Account permissions and security settings (SharePoint Server 2010).

There are many more accounts that are used by SharePoint Server 2010, such as SQL Server services accounts, the Central Administration application pool identity, the SharePoint Foundation Timer service account, the default content access account, the single sign-on account, and the profile import account. Be sure to follow recommended procedures to keep their passwords current and ensure that the services keep working.

For more information, see Change passwords used for administration accounts (SharePoint Server 2010).

8. Follow recommendations for backing up and restoring data

In general, it is best to use a local disk, not a network drive, for backups, and then copy the data later. Use compression when you can, but when you use compression with backups, be mindful not to overwhelm SQL Server. For example, LiteSpeed for SQL Server compresses during backup, which can disrupt SQL Server performance.

For large databases, rely on incremental backups such as those available with System Center Data Protection Manager (DPM) 2010. Do not rely on full backups as your primary mechanism. They are too large to restore quickly.

For more information, see Backup and recovery best practices (SharePoint Server 2010).

9. Be sure that you back up and truncate the log files

Do not only back up the data. Back up the log files, too. The usage logs, IIS logs, transaction logs, and SMTP e-mail logs all must be backed up if you want to be able to fully recover your environment. For transaction logs, you should back up and truncate the log file every five minutes. However, never shrink the transaction log because you may experience performance issues while the log re-grows.

For more information, see Back up or archive logs in SharePoint Server 2010 and How to stop the transaction log of a SQL Server database from growing unexpectedly (https://go.microsoft.com/fwlink/p/?LinkID=111458).

10. Restore data: Test backups and have a standby environment available for service continuity

Routinely test backups and validate their consistency. Do not assume that the backup will work when you want it to. Make sure that it will. Practice recovery to learn what else you must do to bring back the whole environment. For geographically dispersed environments, prepare for disaster recovery by setting up a remote farm. Then you can restore the environment by using the database attach command to upload a copy of the database to the remote farm and redirect users. Similarly, you can set up a standby environment that runs the same version of software as the production environment so that you can restore the databases and recover documents quickly. Keep databases small to speed recovery.

For more information, see Procedural best practices.

If you are using DPM 2010 for backup and recovery, make sure that you plan for backup and recovery of service applications separately. DPM 2010 does not back up Search or other service applications.

For more information, see Choose what to protect and recover in your environment and How to protect SharePoint with DPM 2010 whitepaper (https://go.microsoft.com/fwlink/p/?LinkId=218153).

Acknowledgments

The SharePoint Server 2010 Content Publishing team thanks the following contributors to this article:

  • Aaron Saikovski, Microsoft Consulting Services

  • Ali Mazaheri, Microsoft Consulting Services

  • Bryan Porter, Microsoft Consulting Services

  • Chris Holder, Microsoft SharePoint Customer Engineering

  • Dan Winter, Microsoft SharePoint Customer Engineering

  • Eric Charran, Microsoft Consulting Services

  • Gus Apostol, Microsoft SQL Server Customer Programs

  • John S. Moh, Microsoft Consulting Services

  • Luca Bandinelli, Microsoft SharePoint Customer Engineering

  • Rahim Dossa, Microsoft Consulting Services

  • Steve Peschka, Microsoft Consulting Services

  • Steve Walker, Microsoft SharePoint Customer Engineering

  • Tajeshwar Singh, Microsoft Consulting Services

See Also

Concepts

Health monitoring (SharePoint Server 2010)

Other Resources

Health monitoring (SharePoint Foundation 2010)