Best Practices for Deploying Full-Text Indexing

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Published: August 1, 2000 | Updated : June 14, 2001

For the latest information, see https://www.microsoft.com/exchange

On This Page

Introduction
Preparing Your Exchange Environment
Launching Full-Text Indexing
Managing Full-Text Indexing
Monitoring Full-Text Indexing
Troubleshooting

Introduction

Full-text indexing enables powerful and fast searches by indexing every word in a specified database. This article contains best practices for deploying full-text indexing with Microsoft® Exchange 2000 Server.

Preparing Your Exchange Environment

Prepare your Exchange environment for full-text indexing by properly configuring your server and ensuring that your Exchange organization is stable.

Server Preparation

Before enabling full-text indexing, you should configure your server for optimal performance by adding sufficient memory and distributing large and frequently accessed files across disks.

Server Configuration

Use a mirrored redundant array of independent disks (RAID) configuration. Microsoft recommends using a RAID-0+1 configuration. This configuration allows for the highest performance while ensuring redundancy. RAID-5 is not recommended for full-text indexing.

Disk Space Requirements

The Microsoft Search service (MSSearch) requires that the disk containing the index, also called a catalog, have 15% free disk space at all times. Depending on the types of files you store, the size of your catalog can range from 10 percent to 30 percent of the size of your database. Consider database growth rate if you plan to retain large amounts of data.

Memory Requirements

Add an additional 256 megabytes (MB) of RAM to the recommended configuration for an Exchange 2000 server. Microsoft does not recommend running full-text indexing with less than 512 MB.

File Placement

There are four major categories of full-text indexing files. You can optimize the performance of full-text indexing by arranging the disk location of these files as follows:

• Catalogs Catalogs are the main indexes. There can be one catalog for each Exchange information store.

  Place your catalog on a RAID-0+1 array. You can specify the catalog location inSystem Manager when you create the catalog.

• Property store This is the database containing various properties of items indexed in the catalog. There is only one property store per server.

  Place the full-text property store on the RAID array. By default, the files are installed on the same drive as Exchange Server. To move the property store, use the PSTOREUTL utility located in the Program Files\Common Files\System\MSSearch\Bin directory. The procedure for moving the property store is described in "Launching Full-Text Indexing," later in this article.

• Temporary files These files contain temporary information used by the Microsoft Search service.

  Place the full-text index temporary directory on the RAID array. By default, these files are installed on the system drive, which typically does not have the I/O throughput of the RAID array. To move the temporary directory, use the Settmppath.vbs utility located in the Program Files\Common Files\System\MSSearch\Bin directory. The procedure for moving the tempory files is described in "Launching Full-Text Indexing," later in this article.

  Note: On a cluster, this temporary directory must be on a local drive.

• Gatherer logs These files contain log information for the indexing service. One set of logs exists for each catalog.

  The gatherer logs can remain in their default location, or you can move them if you choose. You can specify your preferred location for gatherer logs by using the following registry key: HKLM\Software\Microsoft\Search\1.0\gather\ExchangeServer_<instance>\<catalog name>\StreamLogsDirectory

  Be sure to specify a valid directory. Full-text indexing does not function if you specify an invalid directory.

Preparing Your Exchange 2000 Organization

Before you install full-text indexing, verify that your Exchange 2000 server or topology is correctly configured and running. If you change your Exchange organization after full-text installation, the index could require a full re-population. In addition, verify the following:

• Simple Mail Transfer Protocol (SMTP) address configuration is stable and functioning. This configuration affects the URL by which objects are indexed.

• The server language is set correctly. Verify the language by opening Control Panel, clicking Regional Settings, and checking the language settings for the system. Full-text indexing references the server language specified when breaking words and stemming—a process by which a search for "travel" returns "travels," "traveled," and "traveling." Full-text indexing works best when the query language matches the language of the files being indexed, and because the server language is sometimes used for the query language when the client's language is unknown, it's best for the server language to match most of the documents on the server.

• All servers are properly functioning and connectivity throughout the organization is stable. Sufficient tests should be performed to ensure that all servers are configured correctly within the organization.

Launching Full-Text Indexing

Deploy full-text indexing by using Exchange System Manager. Deployment involves the following tasks:

• Creating a full-text index

• Optimizing full-text indexing

• Performing a full population

• Establishing a schedule for incremental populations

• Enabling full-text indexing queries

• Notifying users

Creating a Full-Text Index

Before you can use full-text indexing, you must create an initial index. In System Manager, navigate to the information store that you want to index, right-click it, and then click Create Full-Text Index. A dialog box prompts you to select the location of the catalog—the index. Specify a place on the RAID array for the catalog.

Optimizing Full-Text Indexing

Use the following steps to optimize full-text indexing on your Exchange server. As stated earlier, by distributing frequently accessed files across a RAID array, you can enhance system performance.

1. Move the property store.

   When the first index is created on your server, Exchange creates a new property store database on your Exchange system drive. Perform each of the following steps to move the property store database files to your RAID array for improved performance. You need to do this only once for each server because all indexes on a server use the same property store:

   • Stop the Microsoft Search service and disable it.

   • Use the PSTOREUTL utility from a command prompt to move the database to the new drive (see the following example).

   • Re-enable and restart the Microsoft Search service.

   Example:

"C:\Program Files\Common Files\System\MSSearch\Bin\pstoreutl.exe" exchangeserver_<servername> –M "d:\exchsrvr\ExchangeServer_<servername>\ExchangeServer_<servername>.edb" -L "d:\exchsrvr\ExchangeServer_<servername>"

In the preceding example, the C drive is the current location of the property store. The D drive is the location to which you want to move the property store.

2. Move the temporary (/temp) directory.

   From a command prompt, move the Microsoft Search temp directory (see the following example for syntax).

   As stated earlier, by default, the gatherer and filter temporary files (also known as temp files) are located on the Exchange system drive, which typically does not have the I/O throughput of the RAID array. To move the temporary directory, use the Settmppath.vbs utility located in the Program Files\Common Files\System\MSSearch\Bin directory. You need only do this once for each server because all indexes on a server use the same temporary directory.

   Example:

cscript "c:\Program Files\Common Files\System\MSSearch\Bin\settemppath.vbs" d:\temp

**Note**: On a cluster, this temporary directory must be on a local drive.

Performing a Full Population

After you create the index, you must run a full population (also called a crawl) to fill it with data. The resource usage setting for full-text indexing is on the Full-Text Indexing tab of the server Properties. By default, it is set to Low. Microsoft recommends that you use the default setting. A higher setting yields little benefit and could slow down client access to the Exchange server.

With a low resource usage setting, the population process runs in the background and can be performed during business hours. Threads used during the population use idle processing time. User activities receive priority on the system. Because full-text indexing uses only cycles that would otherwise be idle, it should not significantly slow down client access to the server. Expect CPU usage to approach 100 percent as a normal effect of the population process.

To start a full population:

• In Exchange System Manager, navigate to the information store that you want to index, right-click it, and then click Start Full Population.

The initial full population can take a very long time. With a typical Exchange 2000 configuration, population performance typically ranges from 10 to 20 messages per second. Performance varies based on the hardware configuration, the type and size of messages, and available server resources. As a result, the total time required for a full population can range from just a few minutes for a small database, to several days for a very large database. The content language of documents on your server also affects the time the population takes. For example, populating a server containing documents that are written mostly in East Asian languages can take more than five times longer than for documents that are written in Western languages.

You can view the status of the population by expanding the public folder or mailbox store and clicking Full-Text Indexing. During the initial population, the status is Crawling. You can determine that the population has finished by either looking at this status or looking in Event Viewer for "Microsoft Search" messages.

Note: Don't top a full population while it is in progress. If you must stop a full population, but intend to re-run it at another time, click Pause Population, instead of Stop Population.

To pause a full population:

• In System Manager, navigate to the mailbox or public folder store that you want to index, right-click it, and then click Pause Population.

Setting a Schedule for Incremental Populations

Determine how often you want to run incremental population to update the index. Because an incremental population runs in the background in the same way a full population does, frequent updates do not significantly affect user response time. A typical schedule sets incremental updates at the beginning of each hour. In this case, if an update lasts more than an hour, the next incremental crawl begins at the start of the next hour.

To set the incremental population schedule:

1. In System Manager, navigate to the mailbox or public folder store that you want to index, right-click it, click Properties, and then click the Full-Text Indexing tab.

2. In Update Interval, select an interval schedule. Typically, you do not need to set the Rebuild Interval. It is sufficient to set the Update Interval.

Enabling Full-Text Indexing Queries

After the initial population and at least one incremental population is complete, enable the use of the index for queries:

1. In System Manager, navigate to the information store that you want to enable, right-click it, and then click Properties.

2. Click Full-Text Indexing, and then click This index is currently available for searching by clients.

Notifying Users

After installing full-text indexing on a mailbox server, notify users and educate them about what they can expect when they run full-text index searches.

Here's a sample e-mail message that you might choose to send to your users:

Dear User:

Full-text indexing (FTI) has been enabled for all mailboxes on your server. When using the Advanced Find option in Outlook, you might notice some differences—the biggest of which should be speed!

Please note that Outlook executes FTI searches only when you use the Advanced Find option on the Tools menu. Using the Find option yields a traditional character-based search. It does not use full-text indexing.

To verify that FTI is turned on, search against a "noise*"* word, such as "the." Because FTI excludes noise words, you should immediately get zero results (assuming all network connections are working properly). A noise word is an article or word fragment. Full-text indexing filters out these words.

The following list describes other differences between FTI and character-based searches in Outlook 2000:

• You get matches for attachments, as well as messages.

• You get matches for related words, as determined by the word stemmer for your language. The word stemmer uses the language setting to determine related words for the search word. For example, an English word stemmer considers "tester," "tested," and "tests" equivalent, but "testament" is equivalent only to "testaments."

• You will not get matches for messages received since the last population was done (hourly or daily).

• Pattern-matching isn't supported. FTI searches only for whole words. A search for "test" won't match "testament;" a search for "mod" won't match "model." Wild cards are not supported.

• Noise words are removed from queries. This means that a query for "michael p" searches only for "michael" because "p" is a noise word; a search for "the truth" searches only for "truth".

Other functions do not change:

• To perform an AND query to search for a combination of words, simply separate the words with a space. To perform an OR query that returns either search word, separate the words in the query with a comma.

• You can search for an entire phrase by enclosing the phrase in quotation marks. For example, a search for " "asp files" " matches against only those two words in succession.

• Without quotation marks, a search for two words returns items that contain both words. A search for "asp files" (without quotation marks) returns items that have both the word "asp" and also the word "file" or stemming variants thereof.

Thanks,

E-mail Support Team

Accessing Full-Text Searches

With Outlook clients, users can access full-text indexing on the Advanced Find option on the Tools menu. Using the Find option executes a character-based search.

Full-Text Indexing Behaviors

Users accustomed to character-based searches will notice some differences when they use full-text searches. In particular, recently received mails do not appear in

searches, and full-text indexing does not search for partial-word matches. Other differences between character-based searches and full-text searches are:

• Searches over large scopes are much faster than character-based searches.

• Searches for words that are commonly used are slower than searches for rare words. However, in almost every case the searches are much faster and vastly less costly to the server than the old "grep" style search.

• The search returns attachments in addition to messages.

• The search returns related words, as determined by the word-stemmer for the language. For example, word-stemmer considers "tester," "tested," and "tests" equivalent, but it considers "testament" equivalent only to "testaments".

• The search does not return messages received since the last population was performed.

• Pattern-matching does not work; only whole words are searched for. So a search for "test" won't match against "testament"; a search for "mod" won't match against "model". Wildcards do not work.

• Noise words are removed from queries. This means that a query for "michael p" searches only for "michael" because "p" is a noise word; a search for "the truth" searches only for "truth."

  Search results that use full-text indexing are not dynamic. This manifests itself in two ways.

  1. A view of search results does not get updated if a new message arrives that matches the query. This is because the new message has not yet been indexed. It will be indexed on the next incremental crawl or population.

  2. If the user deletes a message from a folder that is showing in search results, the actual message is deleted, but this view of the folder still shows the deleted message. Repeating the query removes the deleted message from the query results.

• When Outlook encounters a comma, it executes an OR query. For example, a search for "section, particularly" (without quotation marks) finds all documents with either "section'" or "particularly" in the document. To search for the word "section" followed by the word "particularly," add quotation marks around the phrase: " "section particularly" ."

Managing Full-Text Indexing

Moving Catalogs (Indexes)

To move a catalog, use the Catutil utility (catutil.exe) located on the Exchange server in the Program Files\Common Files\System\MSSearch\Bin directory. Before running the utility, stop any active full-text indexing, and then stop and disable the search service (MSSearch). For help using this utility, go to the command prompt and type catutil movecat /?.

Note: If you move the catalog by using this method, the Index Location displayed in Exchange System Manager might not be updated. The catalog is successfully moved and functions correctly, but Exchange System Manager might incorrectly display the original location of the catalog. This is only a display error, and does not affect the normal operation of full-text indexing.

Adding Users to an Indexed Server

When you add users to an indexed server, perform an incremental population to add the new mailbox to the index immediately.

Setting a Schedule for Incremental Populations

Determine how often you want to run incremental population to update the index. Because an incremental population runs in the background in the same way a full population does, frequent updates do not significantly impact user response time. A typical schedule sets incremental updates at the beginning of each hour. If an update lasts more than an hour, the next incremental crawl will begin at the start of the next hour.

When is a New Full Population Required?

You must fully populate the index in the following cases:

• When a "word-breaker" is changed (a word-breaker is used by full-text indexing to identify where individual words begin and end in a given text)

• When noise words are changed

• When new document format filters are added

• When the schema file is changed

• When the SMTP address of the store changes

• For disaster recovery

During the population process, the index is still available for full-text queries. The index is unavailable for queries only when you must delete an old catalog before recreating it and perform a new full population. This should be necessary only if the old catalog is corrupt.

Population Process Found in a Paused State

The Microsoft Search service (MSSearch) pauses a population process if it cannot continue. To verify whether MSSearch, rather than an Administrator, paused the population, check the event log. MSSearch should always log an event when it must pause or stop the population. For example, MSSearch pauses a population if the disks are too full to add to the catalogs or the log files. Usually you can fix the problem (for example, by freeing space on a full drive) and resume the population. New documents added during the pause are not added to the index until the next population.

Note: Space on the disk drive could easily be the problem even if it appears that there is plenty of free space. MSSearch uses disk space liberally to temporarily unpack large sections of the catalog to merge new results before recompressing.

Monitoring Full-Text Indexing

Use System Monitor, and Performance Logs and Alerts to monitor full-text indexing.

Performance Objects to Monitor

There are five objects with counters that can be monitored to evaluate full-text indexing:

1. Microsoft Gatherer

2. Microsoft Gatherer Projects

3. Microsoft Search

4. Microsoft Search Catalogs

5. Microsoft Search Indexer Catalogs

Some useful counters from these objects are described in the following section.

Population-Related Counters

Use the following counters with the Microsoft Gatherer and Microsoft Gatherer Projects objects to monitor index population:

• Microsoft Gatherer: Documents Filtered This is the number of documents that have been filtered and the number that have been indexed.

• Microsoft Gatherer: Performance Level The performance level varies from 1 to 4 as set by Exchange System Manager. (1=minimum, 2=low, 3=high, 4=maximum)

• Microsoft Gatherer: System IO traffic rate This shows the I/O rate used to determine whether to reduce crawl processing. See physical disk counters for more detailed I/O diagnostic information.

• Microsoft Gatherer: Reason to back off This counter shows the code describing why the gathering service halted the population.

0 - Up and running 1 - High IO rate 4 - Back off on user activity (by default this is disabled in server install) 5 - Battery low (currently, if running on battery, not on AC power) 6 - Memory low (less than 5 MB left in paging file)

• Microsoft Gatherer Projects: Crawl in Progress Flag This flag contains 0 or 1 and indicates whether a crawl is running: 0=crawl is running, 1=crawl is not running.

• Microsoft Gatherer Projects: Current Crawl is Incremental This flag contains 0 or 1 and indicates whether the crawl is incremental: 0=incremental crawl, 1=full crawl.

• Microsoft Gatherer Projects: Gatherer Paused Flag This flag contains 0 or 1 and indicates a paused crawl: 0=not paused, 1=paused.

• Microsoft Gatherer Projects: URLs in History This flag shows the total number of URLs (folders and documents) known to full-text indexing.

• Microsoft Gatherer Projects: Waiting Documents This flag shows the number of documents waiting to be crawled. This number increases at the start of a crawl as new URLs are identified, then decreases as the crawl progresses.

• Microsoft Search Indexer Catalogs: Merge Progress This flag shows the completion percentage of an index merge.

Query-Related Counters

The following counters for Microsoft Search Catalogs contain information about full-text indexing queries. Use them to monitor queries executed against the full-text index.

The Microsoft Search object contains the total of the values found in four separate catalogs in the Microsoft Search Catalogs object.

• Microsoft Search Catalogs: Queries This counter shows the total number of queries performed.

• Microsoft Search Catalogs: Successful Queries This counter shows the number of successful queries.

• Microsoft Search Catalogs: Results This counter shows the number of rows returned, after trimming, to the scope of the query.

• Microsoft Search Catalogs: Failed Queries This counter shows the number of failed queries (for example, those containing noise words).

General Performance-Related Counters

Use the following counters to monitor general performance.

CPU Usage

Use the following counters to monitor CPU usage. Remember that during a full population, CPU usage usually reaches 100 percent.

• Processor: % Processor Time This counter ranges from 0 to 100 percent.

• Process: % Processor Time This counter ranges from 0 to 100*N processors %. Select from the following instances: "store" is the Exchange Information Store process, "mssearch" is the search process, and "mssdmn" is the indexing process.

Disk Usage

Use the following counters to monitor disk usage. It is essential to have a sufficient amount of free disk space while running full-text indexing. Serious problems can result from running out of disk space. The catalog (index) can become corrupted and other system problems can occur.

• Physical Disk: Current Disk Queue Length This number should not exceed more than 1 or 2 per spindle in the disk system. A higher disk queue length can indicate a bottleneck. This number should frequently return to zero. A disk queue length that rarely or never returns to zero can also indicate a bottleneck.

• Physical Disk: Avg. Disk sec./read This counter shows the time it takes per disk read. This time is typically about 10 milliseconds. A very busy disk has noticeably longer times.

• Physical Disk: Avg. Disk sec./write This counter shows the time it takes per disk write. Typically, this is also about 10 milliseconds; however, a RAID array with a write-back cache has a write time of approximately 1 millisecond, because the information is held in the controller's cache. Again, as the disk gets busier, this number increases.

• Physical Disk: Disk Transfers/sec This counter shows the sum of disk writes and reads per second. Most single spindles have a maximum range of 100 to 150 transfers per second.

Memory Usage

Use the following counters to monitor memory usage:

• Memory: Available Mbytes This counter lists free memory on the machine.

• Process: Virtual Address Space This counter shows reserved memory (includes virtual allocations).

• Process: Private Bytes This counter shows the total allocated memory that is private to this process; for example, the database cache. The counter does not include handles and shared memory.

• Process: Working Set This counter shows the allocated memory actually in RAM (equivalent to Task Manager's Memory Usage). Pausing a full-text indexing crawl causes its working set to shrink to approximately 2 MB.

Paging

Use the following counters to monitor paging:

• Memory: Pages/sec This counter displays the number of hard pages (to disk) per second. However, more than one page can be processed in a single disk read/write.

• Memory: Page Writes/sec This counter displays the number of disk writes per second for paging.

• Memory: Page Reads/sec This counter displays the number of disk reads per second for paging.

• Process: Page Faults/sec This counter displays hard (to disk) and soft (in memory) page faults per second.

If the Pages/sec counter is high (for example, over 100), look at the process generating the most page faults, because a correlation is likely. If it is the information store, check:

• Database: Database Cache Size This counter shows the size of the database's cache. A small cache can produce high paging because the database's cache is swapped back to disk more frequently.

Troubleshooting

Gatherer Logs

Gatherer log files are generated during a population. These files contain log information for the indexing service. The files are located in the \Exchsrvr\ExchangeServer\GatherLogs directory. The files have a .gthr extension.

If a particular document fails to be indexed, for any reason, an entry is logged into the gatherer log file. Each entry lists the file name and error number. To decode this error number, use the Gthrlog.vbs utility found in the \Program Files\Common Files\System\MSSearch\Bin directory. The syntax for this utility is as follows:

cscript gthrlog.vbs <filename>

where filename is the name of the .gthr file. Use the Gthrlog.vbs utility from the command prompt. Results from the utility are displayed at the command prompt.

Full-Text Indexing Rules for Mixed Language

The rules that govern full-text indexing in mixed-language scenarios are complex. The following scenarios explain how various language settings affect indexing behaviors. Administrators use these guidelines to determine the cause of user-reported search problems.

Language Setting of Individual Messages

The language setting of individual messages affects indexing behavior in the following ways:

• If a message is a MAPI message, it has a Locale ID property and full-text indexing uses this value to determine which word-breaker to use. This property value comes from the Office Language setting on the client machine. If full-text indexing cannot find a word-breaker to match the Locale ID property, then it uses the Neutral <0> property.

• If a message is created with Distributed Authoring and Versioning (DAV), it uses the "Accept-Language" header to determine the correct locale.

• If a message has no locale identified (which is often the case with messages from the Internet), then the server's System Locale is used. The server is the Exchange 2000 server that stores the message where the full-text indexing is being performed.

Language Setting of Attachments

The language setting of an attachment affects indexing behavior in the following way:

• If an attachment is a Microsoft Office document, then full-text indexing uses the language setting that was used to generate the document.

Language Setting of the Server Running Microsoft Windows® 2000

The language setting of the server affects indexing behavior in the following way:

• If the message is non-MAPI (in other words, Internet), its Locale ID property is not set and full-text indexing uses the System Locale setting of the server to determine which word-breaker to use.

Language Setting of the Client

The language setting of the client affects indexing behavior in the following way:

• When a query is sent from Outlook, the Locale ID of the client is also sent. If the Locale ID of the message does not match the Locale ID of the query, the search results are unpredictable.

Note: The language of the Exchange server is irrelevant in the preceding scenario. The client setting takes priority.

Full-Text Indexing Behavior in Mixed Language Scenario

The following examples show query behavior of content indexing with various language settings.

All USA Language Settings

If you use USA Outlook running on a USA client machine to compose and submit a message to Exchange 2000 running on a Windows 2000 server with USA settings, the following process occurs:

• Full-text indexing indexes the message by using the USA word-breaker.

• Queries from the USA client are processed as expected.

Hebrew Client, USA Office Settings, Hebrew Windows 2000

If you use Hebrew Outlook, running on a Hebrew client machine with Office settings set to USA, to compose and submit a message to Exchange 2000 running on a server with its System Locale set to USA, the following process occurs:

• Full-text indexing uses the USA word-breaker to index the message. The Locale ID property of the message defaults to USA because of the Office settings.

• Queries from the Hebrew client fail because the Hebrew document does not have the proper word-breaker applied.

Japanese Client, Japanese Office Settings, USA Windows 2000

If you use Japanese Outlook, running on a Japanese client with Office settings set to USA, to compose and submit a message to Exchange 2000 running on a server with its System Locale set to USA, the following process occurs:

• Full-text indexes use the Japanese word-breaker to index the message.

• Queries from the Japanese client succeed because the message was indexed and queried with the same Locale ID.

Queries During Initialization

During initialization, in the first few minutes of starting an Exchange server with full-text indexing, users might get their mail but not get results from queries. This is because the search service, MSSearch, is loading the index and Exchange is loading the property store. Queries do not return results until these processes are complete.

Missing Performance Counters

Event messages similar to the following indicate that the counters used by System Monitor and Performance Logs and Alerts are missing. If you receive one of these messages, restore the counters by restarting MSSearch.

• Performance monitoring for the Gatherer service cannot be initialized because the counters are not loaded or the shared memory object cannot be opened. This only affects availability of the performance counters. Rebooting the system may fix the problem.

• Performance monitoring cannot be initialized for the Gatherer object because the counters are not loaded or the shared memory object cannot be opened. This only affects availability of the performance counters. Rebooting the system may fix the problem.

• Performance monitoring for the Indexer object cannot be initialized because the counters are not loaded or the shared memory object cannot be opened. Stop and restart the Search service. If this error continues, reinstall the application.

Disk Bottlenecks

To avoid disk bottlenecks, use the following guidelines:

Note: For more information, see the preceding section, "Performance Objects to Monitor."

1. Monitor the disk queue length.

   • The queue length is expected to average more than the number of spindles in the RAID array.

   • The length should occasionally drop to zero.

   • The queue should be empty occasionally. If there is always something in the queue, this indicates a problem.

2. Average time per disk write and per disk read should be close to expected latency. The system should take roughly 10 milliseconds for a disk read/write. If configuration has a hardware cache or a RAID controller, the time could be even less.

Memory Bottlenecks

High paging can indicate a memory bottleneck. Check the performance counters listed earlier and monitor them for warning signs. In particular, check Memory: Page writes/sec and Memory: Page reads/sec.