SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

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

We've identified I/O latency on SQL Server portion of our farm. We see tempdb and CrawlDB are biggest offenders. We have 2 extra Raid 1 disks available to us. Let's call them X: and Z:. The question is, will we see more bang for the buck by doing which of the following:

Option 1: X: tempdb.mdf Z: tempdb.ldf

Option 2: X: tempdb .mdf + .ldf Z: CrawlDB .mdf + .ldf

I know general best practices dictate that you separate .ldf and .mdf, but wondering if we can expect to see a bigger bang for the buck if we move crawldb off to separate hardware too. I know we'll need to monitor/test/etc to be sure...

The guidance from MS is a little fuzzy on this (my emphasis added):

Testing and customer data show that SharePoint Server 2010 farm performance can be significantly impeded by insufficient disk I/O for tempdb. To avoid this issue, allocate dedicated disks for tempdb. If a high workload is projected or monitored — that is, the average read operation or the average write operation requires more than 20 ms — you might have to ease the bottleneck by either separating the files across disks or by replacing the disks with faster disks.

share|improve this question
If it helps, I checked sys.dm_io_virtual_file_stats (, and CrawlDB is BY FAR the most latent in io_stall (>50% of all dbs), io_stall_write_ms (>75% of all dbs), and io_stall_read_ms (>50% of all dbs). – Brian Jul 8 '11 at 14:30
Do you see high latency all the time, or only during search crawls? – Chris O'Brien - MVP Jul 8 '11 at 14:46

As ever, many factors to consider in something like this. I'd be inclined to prioritise TempDB over the crawlDB stuff, unless you have very specific requirements around search. If I understand correctly, the crawl database is primarily used around the crawl process, index propagation, and some bits which support querying. So it may be useful to start considering how you use search:

  • Do you have a large corpus which takes a long time to crawl?
  • Do you do full crawls often?
  • How important is it to have the utmost efficiency in crawling? Do you have custom code built on the search API which means that you need to push boundaries in terms of keeping the search index up-to-date? (In which case, FAST would be a better idea :))

If the answer to these questions are "no", you might be able to reduce load on the crawl database by adding crawler impact rules to throttle crawling back somewhat.

On the other hand, TempDB is used by just about every write operation across the farm, amongst other things.

Of course, there may well be other factors and testing in your environment will always provide a better answer than generic guidance - but those should be some food for thought.

share|improve this answer
We don't have high search utilization. We do have a fairly large (i.e. spread out) amount of content to be searched (8 web applications x approximately 200+ site collections per web app x 2 document libraries per site collection x 25+ docs per library). After further analysis we ended up prioritizing the .mdf files for both Search and TempDB (now each are on different disks than the primary content dbs and are on different disks from each other). We've seen some minor improvements to disk I/O perf counters using the PAL tool. – Brian Aug 17 '11 at 15:02

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.