Настройка и оптимизация производительности полнотекстовых индексов

Производительность полнотекстового индекса и полнотекстовых запросов зависит от архитектуры компьютера, а также от объема памяти, скорости работы ЦП и жесткого диска и других ресурсов оборудования. Основной причиной снижения производительности полнотекстового индексирования являются ограничения ресурсов оборудования.

• Если загрузка ЦП узлом управляющей программы полнотекстовой фильтрации (fdhost.exe) или процессом SQL Server (sqlservr.exe) приближается к 100%, то самым узким местом системы является процессор.

• Если средняя длина очереди ожидания обращения к жесткому диску в два или больше раз превышает количество головок диска, то узким местом является жесткий диск. Как правило, эта проблема решается путем создания полнотекстовых каталогов, размещенных отдельно от файлов баз данных и журналов SQL Server. Разместите журналы, файлы баз данных и полнотекстовые каталоги на разных дисках. Кроме того, для повышения производительности индексирования можно приобрести более быстрый жесткий диск или диск с поддержкой RAID.

• Если не хватает физической памяти (пороговое значение в 3 ГБ), то наиболее узким местом может оказаться память. Ограничения, связанные с физической памятью, могут возникнуть на любых системах. На 32-разрядных системах к замедлению полнотекстового индексирования может привести нехватка виртуальной памяти.

  Примечание
  Начиная с версии SQL Server 2008, механизм полнотекстового поиска может использовать память AWE, поскольку механизм является частью sqlservr.exe.

Если в системе нет узких мест, связанных с оборудованием, то производительность индексирования полнотекстового поиска в большей степени будет зависеть от следующих аспектов.

• Время, необходимое SQL Server для создания полнотекстовых пакетов.

• Скорость, с которой управляющая программа фильтрации может обрабатывать эти пакеты.

Примечание
Добавочное, ручное и автоматическое заполнение отслеживания изменений (в отличие от полного заполнения) не рассчитаны на максимальную загрузку ресурсов оборудования ради повышения скорости работы. Поэтому данные предложения по настройке могут не дать результата в виде повышения производительности полнотекстового индексирования.

После завершения операции заполнения инициируется заключительный процесс слияния фрагментов индекса в один главный полнотекстовый индекс. Это повышает производительность запросов за счет использования одного главного индекса вместо нескольких фрагментов индексов и позволяет использовать более точные количественные оценки для ранжирования данных по релевантности. Обратите внимание, что слияние в единый файл может сильно нагружать подсистему ввода-вывода вследствие записи и чтения больших объемов данных, но не приводит к блокировке входящих запросов.

Важно!

При слиянии больших объемов данных в единый файл может создаваться транзакция с большим временем выполнения, в результате чего усечение журнала транзакций по достижении контрольной точки будет отложено. В этом случае размер журнала транзакций в модели полного восстановления может значительно увеличиться. Перед реорганизацией большого полнотекстового индекса в базе данных, использующей модель полного восстановления, убедитесь, что в журнале транзакций достаточно свободного места для транзакций с большим временем выполнения. Дополнительные сведения см. в разделе Управление размером файла журнала транзакций.

Настройка производительности полнотекстовых индексов

Чтобы получить максимальную производительность полнотекстовых индексов, воспользуйтесь следующими рекомендациями.

• Чтобы в максимальной степени задействовать все процессоры или ядра, при помощи хранимой процедуры sp_configure присвойте параметру max full-text crawl ranges значение, равное числу ЦП в системе. Дополнительные сведения об этом параметре конфигурации см. в разделе Параметр max full-text crawl range.

• Убедитесь, что для базовой таблицы установлен кластеризованный индекс. Первый столбец кластеризованного индекса должен иметь целочисленный тип данных. Старайтесь не использовать идентификатор GUID в качестве первого столбца кластеризованного индекса. Многодиапазонное заполнение кластеризованного индекса может обеспечить наивысшую скорость заполнения. Рекомендуется, чтобы столбец, служащий в качестве полнотекстового ключа, имел целочисленный тип данных.

• Обновите статистику базовой таблицы с помощью инструкции UPDATE STATISTICS. Еще важнее обновить статистику кластеризованного индекса или полнотекстового ключа для полного заполнения. Это позволит при многодиапазонном заполнении сформировать для таблицы хорошие секции.

• Создайте вторичный индекс по столбцу timestamp, если нужно повысить производительность добавочного заполнения.

• Перед выполнением полного заполнения на мощном многопроцессорном компьютере рекомендуется временно ограничить размер буферного пула, задав для параметра max server memory значение, оставляющее достаточно памяти для процесса fdhost.exe и для использования операционной системой. Дополнительные сведения см. в подразделе «Оценка требований к памяти для хост-процесса управляющей программы полнотекстовой фильтрации (fdhost.exe)» далее в этом разделе.

Устранение неполадок с производительностью полного заполнения

Для диагностики проблем производительности следует изучить журналы полнотекстового сканирования. Дополнительные сведения о журналах сканирования см. в разделе Устранение ошибок в заполнении средства полнотекстового поиска (сканирование)).

Если производительность полного заполнения неудовлетворительна, то следует выполнить следующие шаги по устранению неполадок.

Использование физической памяти

Во время полнотекстового заполнения существует вероятность того, что у процесса fdhost.exe или sqlservr.exe произойдет нехватка или переполнение памяти. Если журнал полнотекстового сканирования показывает, что fdhost.exe часто перезапускается или возвращает код ошибки 8007008, то это значит, что одному из этих процессов не хватает памяти. Если процесс fdhost.exe создает дампы (особенно на мощных, многопроцессорных компьютерах), то ему может не хватать памяти.

Примечание
Сведения о буферах памяти, используемых полнотекстовым сканированием, см. в разделе sys.dm_fts_memory_buffers (Transact-SQL).

Возможны следующие причины.

• Если объем физической памяти, доступный во время полного заполнения, равен нулю, то большая часть физической памяти системы может использоваться буферным пулом SQL Server.

  Процесс sqlservr.exe пытается захватить всю доступную память для буферного пула, ограничиваясь установленным максимумом памяти сервера. Если выделенный размер max server memory слишком велик, это может привести к исчерпанию памяти процессом fdhost.exe, а также к ошибкам выделения общей памяти.

  Примечание
  Во время проведения полнотекстового заполнения на многопроцессорном компьютере (например, 64-way IA64) может возникнуть конфликт между процессами fdhost.exe и sqlservr.exe за память буферного пула. Возникающая в результате этого нехватка общей памяти вызывает повторы пакетов, пробуксовку памяти и создание дампов процессом fdhost.exe.

  Чтобы решить эту проблему, можно задать правильное значение для параметра max server memory буферного пула SQL Server. Дополнительные сведения см. в подразделе «Оценка требований к памяти для хост-процесса управляющей программы полнотекстовой фильтрации (fdhost.exe)» далее в этом разделе. Разрешить проблему можно, уменьшив размер пакета, используемого для полнотекстового индексирования.

• Проблема с подкачкой.

  Недостаточный размер файла подкачки (например, если в системе задан небольшой файл подкачки с ограниченным ростом) также может вызвать переполнение памяти для процессов fdhost.exe и sqlservr.exe.

  Если в журналах сканирования не зарегистрированы сбои, связанные с памятью, то, скорее всего, проблемы с производительностью вызваны излишней подкачкой.

Оценка требований к памяти процесса узла управляющей программы фильтрации (fdhost.exe)

Объем памяти, необходимый процессу fdhost.exe для заполнения, зависит в основном от числа используемых диапазонов полнотекстового сканирования, размера входящей общей памяти (ISM) и максимального числа экземпляров ISM.

Объем памяти (в байтах), занимаемый узлом управляющей программы фильтрации, может быть примерно рассчитан с использованием следующей формулы:

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

Ниже приводятся значения по умолчанию для переменных в приведенной выше формуле.

Переменное	Значение по умолчанию
number_of_crawl_ranges	Число процессоров
ism_size	1 МБ для компьютеров x86 4, 8 и 16 МБ для компьютеров для компьютеров x64 (в зависимости от общего объема физической памяти)
max_outstanding_isms	25 МБ для компьютеров x86 5 для компьютеров x64

В следующей таблице представлены рекомендации по оценке требований к памяти fdhost.exe. В формулах данной таблицы используются следующие значения.

• F: оценка объема памяти, необходимого для fdhost.exe (в МБ).

• T: общий объем физической памяти, доступной в системе (в МБ).

• M: оптимальное значение для параметра max server memory.

Важно!
Дополнительные сведения о формулах см. ниже, в пунктах 1, 2 и 3.

Платформа	Оценка потребностей в памяти для fdhost.exe в МБ: F1	Формула для вычисления значения параметра max server memory: M2
x86 с отключенной памятью AWE	F=Number of crawl ranges* 50	M=minimum(T, 2000)–F– 500
x86 с включенной памятью AWE	F=Number of crawl ranges* 50	M=T–F– 500
x64 или IA643	F=Number of crawl ranges* 10 * 8	M=T–F– 500

1Если параллельно выполняется несколько полных заполнений, то требования к памяти fdhost.exe для каждого из них следует вычислять отдельно, как F1, F2 и т. д. Затем следует вычислить M как T**–** sigma**(Fi)**.

2 500 МБ: ориентировочный объем памяти, необходимый другим процессам в системе. Если система выполняет дополнительную работу, то это значение следует соответствующим образом увеличить.

3Предполагается, что значение ism_size равно 8 МБ для платформ x64.

Пример. Оценка требований к памяти fdhost.exe

В данном примере используется компьютер AMD64 с 8 ГБ ОЗУ и четырьмя двухъядерными процессорами. Первое вычисление оценивает объем памяти, необходимый для fdhost.exe: F. Число диапазонов сканирования: 8.

F = 8*10*8=640

Следующее вычисление получает оптимальное значение для параметра max server memory—M. T. Общий объем физической памяти, доступный в данной системе в МБ: T = 8192.

M = 8192-640-500=7052

Пример. Задание значения параметра max server memory

В данном примере хранимая процедура sp_configure и инструкции Transact-SQLRECONFIGURE используются для установки параметра max server memory в значение, которое было вычислено для M в предыдущем примере: 7052.

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

Установка значения параметра конфигурации max server memory.

• Параметры памяти сервера

• Как просмотреть или изменить свойства сервера (диспетчер конфигурации SQL Server)

• Как установить фиксированный размер памяти (среда SQL Server Management Studio)

Факторы, которые могут снизить нагрузку на ЦП

Производительность полного заполнения считается неоптимальной, если уровень загруженности ЦП ниже 30%. В данном разделе обсуждаются некоторые факторы, которые влияют на уровень загруженности ЦП.

• Высокие значения ожиданий для страниц.

  Чтобы определить, является ли значение времени ожидания страницы высоким, выполните следующую инструкцию Transact-SQL.

  Execute SELECT TOP 10 * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC;
  

  В следующей таблице описаны типы значений ожидания, представляющие интерес.

  Тип ожидания	Описание	Возможное решение
  PAGEIO_LATCH_SH (_EX или _UP)	Это может свидетельствовать о наличии узкого места в подсистеме ввода-вывода. В этом случае средняя длина очереди диска обычно велика.	Перемещение полнотекстового индекса в другую файловую группу на другом диске может помочь снизить влияние узкого места в операциях ввода-вывода.
  PAGELATCH_EX (или _UP)	Это может свидетельствовать о высокой конкуренции между потоками, которые пытаются выполнить запись в один и тот же файл базы данных.	Уровень конкуренции можно снизить, добавив файлы в файловую группу, в которой расположен полнотекстовый индекс.

  Дополнительные сведения см. в разделе sys.dm_os_wait_stats (Transact-SQL).

• Неэффективное сканирование базовой таблицы.

  Во время создания пакетов при полном заполнении производится просмотр базовой таблицы. Ее сканирование может оказаться неэффективным в следующих случаях.

  • Если в базовой таблице присутствует высокий процент столбцов, значения в которых хранятся вне строк, для которых выполняется полнотекстовое индексирование, то узким местом может оказаться сканирование базовой таблицы для создания пакетов. В этом случае можно попробовать решить проблему, переместив значения данных с небольшими длинами в строки, используя типы varchar(max) и nvarchar(max).

  • Сканирование может выполняться неэффективно в том случае, если базовая таблица имеет высокую степень фрагментации. Сведения о вычислении данных, хранящихся вне строк, и фрагментации индексов см. в разделах, посвященных представлениям sys.dm_db_partition_stats (Transact-SQL) и sys.dm_db_index_physical_stats (Transact-SQL).

    Чтобы снизить уровень фрагментации, можно выполнить реорганизацию или перестроение кластеризованного индекса. Дополнительные сведения см. в разделе Реорганизация и перестроение индексов.

См. также

Задания

Устранение неполадок. Снижение производительности полнотекстового индексирования из-за фильтрации

Ошибки полнотекстового индексирования

Справочник

sys.dm_fts_memory_buffers (Transact-SQL)

sys.dm_fts_memory_pools

Основные понятия

Параметры настройки min server memory и max server memory

Параметр max full-text crawl range

Заполнение полнотекстового индекса

Общие сведения о полнотекстовом индексировании

Процесс полнотекстового индексирования и обработки запросов

Устранение неполадок компонента Full-Text Search

Структура полнотекстового индекса

Другие ресурсы

Администрирование компонента Full-Text Search