During a full-text population, it is possible for fdhost.exe or sqlservr.exe to run low on memory or to run out of memory. If the full-text crawl log shows that fdhost.exe is being restarted often or that error code 8007008 is being returned it means one of these processes is running out of memory. If fdhost.exe is producing dumps, particularly on large, multi-CPU computers, it might be running out of memory.

Note:
To obtain information about memory buffers used by a full-text crawl, see sys.dm_fts_memory_buffers (Transact-SQL).

The possible causes are as follows:

• If amount of physical memory that is available during a full population is zero, the SQL Server buffer pool might be consuming most of the physical memory on the system.
  The sqlservr.exe process tries to grab all available memory for the buffer pool, up to the configured maximum server memory. If the max server memory allocation is too large, out-of-memory conditions and failure to allocate shared memory can occur for the fdhost.exe process.
  

  Note:
  During a full-text population on a multi-CPU computer, such as a 64-way IA64 computer, contention for the buffer pool memory can occur between fdhost.exe or sqlservr.exe. The resulting lack of shared memory causes batch retries, memory thrashing, and dumps by the fdhost.exe process.

  You can solve this problem by setting the max server memory value of the SQL Server buffer pool appropriately. For more information, see "Estimating the Memory Requirements of the Filter Daemon Host Process (fdhost.exe)," later in this topic. Reducing the batch size used for full-text indexing may also help.
  
• A paging issue
  Insufficient page-file size, such as on a system that has a small page file with restricted growth, can also cause the fdhost.exe or sqlservr.exe to run out of memory.
  If the crawl logs do not indicate any memory-related failures, it is likely that performance is slow due to excessive paging.
  

Estimating the Memory Requirements of the Filter Daemon Host Process (fdhost.exe)

The amount of memory required by the fdhost.exe process for a population depends mainly on the number of full-text crawl ranges it uses, the size of inbound shared memory (ISM), and the maximum number of ISM instances.

The amount of memory (in bytes) consumed by the filter daemon host can be roughly estimated by using the following formula:

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

The default values of the variables in the preceding formula are as follows:

Variable	Default value
number_of_crawl_ranges	The number of CPUs
ism_size	1 MB for x86 computers 4 MB, 8 MB, or 16MB for x64 computers, depending on the total physical memory
max_outstanding_isms	25 for x86 computers 5 for x64 computers

The following table presents guidelines about how to estimate the memory requirements of fdhost.exe. The formulas in this table use the following values:

• F, which is an estimate of memory needed by fdhost.exe (in MB).
  
• T, which is the total physical memory available on the system (in MB).
  
• M, which is the optimal max server memory setting.
  

Important:
For essential information about the formulas, see 1, 2, and 3, below.

Platform	Estimating fdhost.exe memory requirements in MB—F1	Formula for calculating max server memory—M2
x86 with AWE disabled	F = Number of crawl ranges * 50	M = minimum(T, 2000) – F – 500
x86 with AWE enabled	F = Number of crawl ranges * 50	M = T – F – 500
x64 or IA643	F = Number of crawl ranges * 10 * 8	M = T – F – 500

1 If multiple full populations are in progress, calculate the fdhost.exe memory requirements of each separately, as F1, F2, and so forth. Then calculate M as T – sigma(Fi).

2 500 MB is an estimate of the memory required by other processes in the system. If the system is doing additional work, increase this value accordingly.

3 .ism_size is assumed to be 8 MB for x64 platforms.

Example: Estimating the Memory Requirements of fdhost.exe

This example is for an AMD64 computer that has 8GM of RAM and 4 dual core processors. The first calculation estimates of memory needed by fdhost.exe—F. The number of crawl ranges is 8.

F = 8*10*8=640

The next calculation obtains the optimal value for max server memory—M. The total physical memory available on this system in MB—T—is 8192.

M = 8192-640-500=7052

Example: Setting max server memory

This example uses the sp_configure and RECONFIGURE Transact-SQL statements to set max server memory to the value calculated for M in the preceding example, 7052:

USE master;
GO
EXEC sp_configure 'max server memory', 7052;
GO
RECONFIGURE;
GO

To set the max server memory configuration option

• Server Memory Options
  
• How to: View or Change Server Properties (SQL Server Configuration Manager)
  
• How to: Set a Fixed Amount of Memory (SQL Server Management Studio)
  

We expect that the performance of full populations is not optimal when the average CPU consumption is lower than about 30 percent. This section discusses some factors that affect CPU consumption.

• High wait for pages
  To find out whether a page wait time is high, execute the following Transact-SQL statement:
  
  Execute SELECT TOP 10 * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC;

  The following table describes the wait types of interest here.
  

  Wait type	Description	Possible resolution
  PAGEIO_LATCH_SH (_EX or _UP)	This could indicate an IO bottleneck, in which case you would typically also see a high average disk-queue length.	Moving the full-text index to a different filegroup on a different disk could help reduce the IO bottleneck.
  PAGELATCH_EX (or _UP)	This could indicate a lot of contention among threads that are trying to write to the same database file.	Adding files to the filegroup on which the fulltext index resides could help alleviate such contention.

  For more information, see sys.dm_os_wait_stats (Transact-SQL).
  
• Inefficiencies in scanning the base table
  A full population scans the base table to produce batches. This table scanning could be inefficient in the following scenarios:
  
  • If the base table has a high percentage of out-of-row columns that are being full-text indexed, scanning the base table to produce batches might be the bottleneck. In this case, moving the smaller data in-row using varchar(max) or nvarchar(max) might help.
    
  • If the base table is very fragmented, scanning might be inefficient. For information about computing out-of-row data and index fragmentation, see sys.dm_db_partition_stats (Transact-SQL) and sys.dm_db_index_physical_stats (Transact-SQL).
    To reduce fragmentation, you can reorganize or rebuild the clustered index. For more information, see Reorganizing and Rebuilding Indexes.