Sign In
 
 
Go Search
 
Jason Cahill's SharePoint Blog > Categories
SharePoint 101: It’s log… it’s log… it’s better than bad… it’s good!

I must admit, I was never much of a Ren and Stimpy fan, but if you haven’t seen their ridiculous “fake commercial” for “Log!!”, then you owe it to yourself to head over to YouTube and do a quick search for “it’s log ren stimpy”… It’s a takeoff on the 70’s ads for Slinky, but taken to a new level of absurdity. Sadly, this was the first thing that popped in my mind when I sat down to write this post.

So, logs. We love ‘em, but as I mentioned in my last post on partitioning hard drives for your SharePoint servers, you want to have a single, consistent location on every machine where your log files can be placed. Additionally, this should be a separate logical partition from your OS and swap files so that when it gets too big, you don’t lose your system.

So, what should you do? Here’s what we do: First, let’s assume your logical log drive is E:. The first thing to do is to create two folders: E:\logs\iis and E:\logs\uls. Then you will redirect your IIS and ULS (SharePoint Trace Logs) into these folders. Here’s how: Open up Internet Information Services (IIS) Manager (these instructions assume IIS 7) and click on your server name (you must do this for each and every server in your farm). In the main body of the dialog, select Logging:

IIS 7 configuration options

When the Logging page appears, you’ll want to configure it as follows:

IIS 7 logging options

Then, using the drop downs set:

  • One log file per: Site
  • Format: IIS
  • Directory: E:\logs\iis

Next you’ll want to redirect the SharePoint Trace Logs (ULS Logs). To do this, go to Central Administration > Operations > Diagnostic Logging:

SharePoint 2007 Diagnostic Logging

Here, at the bottom of the page, click in the Path: edit box and change it to:

  • E:\logs\uls

Click OK.

Because this is set once in Central Admin, there are two consequences: It doesn’t propagate instantly to every server, it will instead kick off as a job in a short time. Secondly, the path that you specify must exist and be the same on every machine in the farm. Failure to do this will result in problems.

SharePoint 101: Setting up your local disks for optimal performance

How much up front thought did you give to the local disks in your SharePoint web front-ends (WFE) and application servers (APP)? It turns out that it matters quite a bit, particularly if you are trying to offer high availability.

One of my colleagues, Mark Harmsworth on our product team, is responsible for running our internal SharePoint deployments for the Office, SharePoint, and Exchange product teams and has spent quite a bit of time trying different options. I thought I'd share what we've learned and you can consider implementing it (or sharing with us, if you have an option that you think is even better).

Before I go into details, I want to be clear that this post is not about the disks that you use for your SQL storage, as there are separate considerations for those disks, based on the tempdb, temp db logs, and the content, which I will share in a later post. This post is really about how many disks you should have in each of your WFE and APP servers and I'll assume you are putting your SQL storage elsewhere.

The bottom line best practice that we've found is that you should have at least 3 logical drives and at least four physical disks in each server. In an ideal config, you would have 3 logical drives and 6 physical drives.

SharePoint 2007 hard drive configuration

The set up is such that you want to separate where your software is installed (your OS / Program Files disk) from your OS Swap File (which is where your system turns to under memory pressure) from the place where IIS and SharePoint's log files are written. The reason for this separation is pretty simple: under heavy loads, you want to have separate physical hardware handling the three separate places that can receive pressure. If one of your servers gets under memory pressure (because of lots of concurrent users or large requests), the OS will need to start paging out to virtual memory (the OS Swap File). If this is on the same physical disks as where your OS / Program Files are installed, then you've introduced latency when the system needs to (for any reason) load any system file into memory. Separating these places relieves that issue and makes your system more responsive. Similarly, log files can get very large, very fast and the last thing you want is for your logs to accidentally take up all remaining space on your drives with the OS or the Swap file, because that will kill the system. Regardless of how many physical disks you can afford, you want to have the three logical partitions, because then your logs filling up will not prevent normal system operation.

If you must "go cheap", then consider using the physical disks for your OS / Program Files also for your Logs (but still on separate logical drives). If at all possible, you should have separate physical disks for your OS Swap file. The picture I've shown here recommends RAID 1 and this is because you can afford to lose a disk without having to rebuild your entire system. You should also consider the speed of the drives that you are buying. Standard off-the-shelf, cheap commodity SATA drives are typically large and slow (7200 RPM). If you want to stay with SATA, you should consider bumping up your OS Swap disks to 10,000 RPM drives. Still better, though much more pricy would be to consider 15,000 RPM SAS (Serial Attached SCSI) drives. These configuration choices will make a big difference in the overall performance and reliability of your systems.