Улучшение производительности полнотекстовых индексов

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

В этом разделе

• Распространенные причины проблем с производительностью

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

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

• Устранение неполадок со снижением производительности индексации, связанных с фильтрами

Распространенные причины проблем с производительностью

Основной причиной снижения производительности полнотекстового индексирования являются ограничения ресурсов оборудования.

• Если загрузка ЦП узлом управляющей программы полнотекстовой фильтрации (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 process могут возникнуть проблемы с недостатком памяти и сбои при выделении общей памяти.

  Примечание
  Во время проведения полнотекстового заполнения на многопроцессорном компьютере может возникнуть конфликт между процессами 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	F = Number of crawl ranges * 50	M = minimum(T, 2000) – F – 500
x64	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-SQL RECONFIGURE используются для установки параметра max server memory в значение, которое было вычислено для M в предыдущем примере: 7052.

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

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

• Параметры конфигурации сервера «Server Memory»

[В НАЧАЛО]

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

Производительность полного заполнения считается неоптимальной, если уровень загруженности ЦП ниже 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).

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

[В НАЧАЛО]

Устранение неполадок со снижением производительности индексации, связанных с фильтрами

При заполнении полнотекстового индекса средство полнотекстового поиска использует два типа фильтров: многопоточные и однопоточные. Некоторые документы, например документы Microsoft Word, фильтруются с помощью многопоточного фильтра. Другие, например документы формата Adobe Acrobat Portable Document Format (PDF), фильтруются с помощью однопоточного фильтра.

Из соображений безопасности фильтры загружаются процессами узла управляющей программы фильтрации. Экземпляр сервера использует многопоточный процесс для всех многопоточных фильтров и однопоточный процесс для всех однопоточных фильтров. Если документ, использующий многопоточный фильтр, содержит внедренный документ, использующий однопоточный фильтр, то средство полнотекстового поиска запускает однопоточный процесс для внедренного документа. Например, если документ Word содержит PDF-документ, средство полнотекстового поиска использует многопоточный процесс для содержимого Word и запускает однопоточный процесс для PDF-содержимого. Однако однопоточный фильтр может неправильно работать в такой среде, дестабилизируя процесс фильтрации. В некоторых обстоятельствах, когда часто встречаются такие внедрения, дестабилизация может привести к сбою процесса фильтрации. В этом случае средство полнотекстового поиска перенаправляет сбойный документ (например, документ Word, содержащий внедренный PDF-документ) в однопоточный процесс фильтрации. Если перенаправление происходит достаточно часто, производительность полнотекстового индексирования снижается.

Для устранения этой проблемы необходимо пометить фильтр для документа-контейнера (в данном случае Microsoft Word) как однопоточный фильтр. Чтобы пометить фильтр как однопоточный, можно изменить значение для этого фильтра в реестре. Для этого необходимо присвоить ключу реестра ThreadingModel для этого фильтра значение Apartment Threaded. Сведения об однопоточных подразделениях см. в техническом документе Understanding and Using COM Threading Models.

[В НАЧАЛО]

См. также

Задания

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

Справочник

sys.dm_fts_memory_buffers (Transact-SQL)

sys.dm_fts_memory_pools (Transact-SQL)

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

Параметры конфигурации сервера «Server Memory»

Параметр конфигурации сервера «max full-text crawl range»

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

Создание и управление полнотекстовыми индексами