Оценка требований загрузки и производительности для системы поиска SharePoint Server 2010

Статья
03/05/2017

Применимо к: SharePoint Server 2010

Последнее изменение раздела: 2016-11-30

Обзор. В этой статье приводятся рекомендации по планированию загрузки для разных развертываний систем поиска Microsoft SharePoint Server 2010, включая малые, средние и крупные фермы SharePoint Server 2010.

В этой статье приводятся рекомендации по планированию загрузки для сред совместной работы в развертываниях систем поиска SharePoint Server 2010. В ней представлены следующие сведения для трех примеров конфигурации ферм поиска:

Спецификации тестовой среды, например, оборудование, топология фермы и конфигурация
Нагрузки, используемые для формирования данных, включая число и класс пользователей и характеристики использования фермы
Набор данных тестовой фермы, включая контент и размер баз данных
Данные о работоспособности и производительности, характерные для тестируемой среды

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

Система поиска SharePoint Server 2010 предоставляет расширенный набор компонентов и более гибкую модель топологии в сравнении с предыдущими версиями. Перед использованием этой архитектуры для предоставления пользователям более эффективных компонентов и функций необходимо внимательно изучить их воздействие на загрузку и производительность фермы.

После изучения этого документа вы узнаете, как выполнять следующие процедуры:

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

Прежде чем приступать к чтению этой статьи, необходимо ознакомиться со следующими концепциями:

Capacity management and sizing for SharePoint Server 2010
Управление мощностью SharePoint Server 2010 Ограничения, связанные с программным обеспечением
Доступность
Избыточность
Характерный для баз данных контент

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

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

Репозитории для обхода содержат преимущественно контент SharePoint Server.
Большинство пользовательских запросов принадлежит одной трети индекса. Это означает, что большинство пользователей выполняют поиск одних и тех же терминов.
Используются параметры метаданных по умолчанию, что позволяет поддерживать приемлемый уровень роста базы данных свойств.
В средних и крупных фермах существуют выделенные целевые серверы для обхода (интерфейсные веб-серверы), которые могут обслуживать контент обхода этих ферм поиска.
Точность измерений в фермах зависит от состояния сети и среды; допускается погрешность до 10%.

Выбор сценария

При выборе подходящего сценария рекомендуется руководствоваться следующими вопросами:

Размер собрания Каков объем доступного для поиска контента? В общее число следует включать все объекты, в том числе документы, веб-страницы элементы списка и людей.
Доступность Каковы требования к доступности? Требуется ли решение, способное сохранить работоспособность в случае отказа отдельного сервера?
Актуальность контента Какова требуемая степень актуальности результатов поиска? Как долго после внесения изменений должен отображаться в результатах обновленный пользователем контент? Как часто предполагается изменение контента?
Пропускная способность Как много пользователей будут одновременно выполнять поиск контента? В их число входят пользователи, вводящие запросы в поле поиска, скрытые запросы веб-частей на автоматический поиск данных, а также компоненты Microsoft Outlook 2010 Social Connector, запрашивающие в системе поиска веб-каналы активности, URL-адреса которых требуют фильтрации по ролям безопасности.

Основываясь на ответах на эти вопросы, выберите один из следующих сценариев:

Малая ферма Содержит одно приложение-службу поиска, которое использует некоторые общие ресурсы в одной ферме SharePoint Server. Для малых развертываний объем контента, включаемого в индекс, обычно ограничен (менее 10 миллионов элементов). В зависимости от установленных показателей актуальности добавочный обход контента может выполняться в рабочие часы.
Средняя ферма Содержит одно или несколько приложений-служб поиска в выделенной ферме, которая предоставляет услуги поиска другим фермам. В индекс включается умеренный объем контента (до 40 миллионов элементов). В зависимости от установленных показателей актуальности добавочный обход контента вероятнее всего будет выполняться в рабочие часы.
Крупная ферма Содержит одно или несколько приложений-служб поиска в выделенной ферме, которая предоставляет услуги поиска другим фермам. В индекс включается большой объем контента (до 100 миллионов элементов). В зависимости от установленных показателей актуальности добавочный обход контента вероятнее всего будет выполняться в рабочие часы.

Жизненный цикл поиска

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

Получение индекса Первый этап процесса наполнения данными. Длительность этого этапа зависит от размера источников контента. Характеризуется следующим образом:
- Полный обход контента (по-возможности выполняется параллельно).
- Тщательный мониторинг системы обхода контента в целях определения узлов, которые потенциально могут ограничивать общую производительность обхода контента.
- Частый процедуры объединения с главной копией, которые запускаются для каждого компонента при изменении определенной части индекса.
Обслуживание индекса Основной этап жизненного цикла фермы. Характеризуется следующим образом:
- Периодически выполняется добавочный обход всего контента.
- При обходе контента SharePoint Server большинство изменений связаны с изменениями в системе безопасности.
- Относительно редкие процедуры объединения с главной копией, которые запускаются для каждого компонента при изменении определенной части индекса.
Очистка индекса Этот этап реализуется в тех случаях, когда в результате изменения контента ферма выходит за рамки этапа обслуживания индекса. Например, очистка осуществляется при перемещении базы данных контента или сайта из одного приложения-службы поиска в другое. Этот этап запускается при наступлении одного из следующих событий:
- Программе-обходчику в течение длительного времени не удается найти узел, предоставляющий контент.
- Источник контента или начальный адрес удаляется из приложения-службы поиска.

Сценарии

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

Малая ферма

Из-за небольшого размера фермы некоторые серверы выполняют одновременно несколько ролей. Рекомендуется объединять компонент запросов с интерфейсным веб-сервером. Это позволит избежать размещения на одном сервере компонентов обхода контента и запросов. В этой конфигурации используется три сервера приложений и один сервер базы данных:

Поскольку в системах поиска в корпоративной среде обычно рекомендуется развертывать избыточные серверы запросов, компоненты запросов реализованы на двух серверах приложений, что дает следующую конфигурацию:
- На одном сервере приложений размещается центр поиска. Если малая ферма используется в качестве служебной фермы, и центры поиска создаются в дочерних фермах контента, которые используют приложение-службу поиска из этой родительской служебной фермы, такую конфигурацию можно не применять.
- В соответствии с рекомендациями, индекс, содержащий менее 10 миллионов элементов, должен иметь один раздел. На каждом сервере развернут один основной компонент запросов из раздела индекса. Такая конфигурация компонента запросов в режиме "активный/активный" позволяет обеспечить работоспособность даже в случае отказа одного из компонентов поиска, когда нагрузка по обработке запросов переносится на оставшийся компонент. При отказе одного из компонентов система поиска пересылает запросы на следующий доступный компонент запросов (используется алгоритм циклического перебора).
Один сервер приложений используется для обхода контента и администрирования. На нем создаются центр администрирования (обеспечивает управление системой поиска) и компонент обхода контента.
Отдельный сервер базы данных, обеспечивающий работу фермы. На этом сервере должно быть зарезервировано определенное число операций операций ввода-вывода в секунду для баз данных обхода контента, свойств и администрирования (например, могут использоваться разные массивы запоминающих устройств).

Спецификации

В этом разделе приведены подробные сведения об оборудовании, программном обеспечении, топологии и конфигурации этой тестовой среды.

Топология

Топология поиска для малой фермы

Аппаратное обеспечение

Примечание

Поскольку в тестовой ферме были развернуты предварительные выпуски SharePoint Server 2010, чтобы избежать потенциальных проблем, на серверах использовалось оборудование большей, чем обычно требуется, производительности.

Веб-серверы

Веб-сервер	Интерфейсный веб-сервер/сервер запросов (1)
Процессор	1 четырехъядерный процессор с тактовой частотой 3 ГГц
ОЗУ	16 ГБ
Операционная система	Windows Server 2008 R2 64-разрядная
Хранилище	2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ОС 2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:БД1 2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:БД2
Число сетевых адаптеров	2
Скорость передачи данных сетевого адаптера	1 гигабит
Проверка подлинности	NTLM
Тип службы балансировки нагрузки	Нет
Версия программного обеспечения	SharePoint Server 2010 (предварительная версия)
Службы, запущенные локально	Все службы, включая службу параметров сайтов и запросов поиска

Серверы приложений

Сервер	Сервер запросов (1)	Сервер обхода контента/администрирования (1)
Процессор	1 четырехъядерный процессор с тактовой частотой 3 ГГц	1 четырехъядерный процессор с тактовой частотой 3 ГГц
ОЗУ	16 ГБ	16 ГБ
Операционная система	Windows Server 2008 R2 64-разрядная	Windows Server 2008 R2 64-разрядная
Хранилище	2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ОС 2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:БД1 2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:БД2	2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ОС 2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ВРЕМЕННАЯ БД 2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID0:БД
Число сетевых адаптеров	1	1
Скорость передачи данных сетевого адаптера	1 гигабит	1 гигабит
Проверка подлинности	NTLM	NTLM
Тип службы балансировки нагрузки	Нет	Нет
Версия программного обеспечения	SharePoint Server 2010 (предварительная версия)	SharePoint Server 2010 (предварительная версия)
Службы, запущенные локально	Служба поиска SharePoint Server; служба параметров сайтов и запросов поиска	Служба поиска SharePoint Server

Серверы баз данных

База данных	Общая (1)
Процессор	2 четырехъядерных процессора с тактовой частотой 3 ГГц
ОЗУ	16 ГБ
Операционная система	Windows Server 2008 R2 64-разрядная
Хранилище	2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ОС 2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID0:БД 2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID0:ЖУРНАЛЫ Примечание В связи с уменьшением числа дисков, рекомендация по разделению баз данных по различным каналам ввода-вывода не применима.
Число сетевых адаптеров	2
Скорость передачи данных сетевого адаптера	1 гигабит
Проверка подлинности	NTLM
Версия программного обеспечения	Microsoft SQL Server 2008 Enterprise

Рабочая нагрузка

В этом разделе описывается нагрузка, используемая для формирования данных, включая число пользователей и характеристики использования фермы.

Характеристики рабочей нагрузки	Значение
Высокоуровневое описание рабочей нагрузки	Фермы поиска
Среднее число запросов в минуту	6
Среднее число параллельных пользователей	1
Общее число запросов в день	8640

Набор данных

В этом разделе описывается набор данных тестовой фермы, включая контент и размер баз данных, индексы поиска и внешние источники данных.

Объект	Значение
Размер индекса поиска (число элементов)	9 миллионов
Размер базы данных обхода	52 ГБ
Размер файла журнала базы данных обхода	11 ГБ
Размер базы данных свойств	68 ГБ
Размер файла журнала базы данных свойств	1 ГБ
Размер базы данных администрирования поиска	2 ГБ
Размер активных разделов индекса	38,4 ГБ (всего 76,8 ГБ в связи с применением зеркалирования индекса)
Общее число баз данных поиска	3
Другие базы данных	SharePoint_Config; SharePoint_AdminContent; State_Service; Bdc_Service_db; WSS_UsageApplication; WSS_Content

Данные о работоспособности и производительности

В этом разделе описываются данные о работоспособности и производительности для тестовой среды.

Данные по эффективности запросов

Следующие измерения были проведены для индекса, содержащего 9 миллионов элементов. В столбцах приведены результаты отдельных тестов; итоговые результаты приведены в нижней части следующей таблицы. Измерения описываются следующим образом:

Задержка запросов Эти измерения были выполнены в процессе тестирования на задержку запросов. Средством тестирования был отправлен набор стандартных запросов от имени одного пользователя, после чего была определена итоговая задержка. Во время тестирования обход контента не выполнялся.
Пропускная способность запросов Эти измерения были выполнены в процессе тестирования на пропускную способность запросов. Средством тестирования был отправлен стандартный набор запросов к ферме от имени увеличивающегося числа параллельных пользователей (до 80), после чего были определены итоговая задержка и пропускная способность. Во время тестирования обход контента не выполнялся.

	Показатель системы показателей	Задержка запросов	Пропускная способность запросов
Показатели ЦП	Среднее значение использования ЦП SQL Server	3,4%	12%
	Среднее значение использования ЦП интерфейсного веб-сервера	8%	51%
	Среднее значение использования ЦП сервера запросов	13,3%	95%
Надежность	Процент сбоев	0	0
	Сбои интерфейсного веб-сервера	0	0
	Сбои сервера приложений	0	0
SQL Server	Коэффициент попадания в кэш (SQL Server)	99,97%	100%
	Операций блокировки SQL Server: среднее время ожидания (мс)	0,071	0,038
	Операций блокировки SQL Server: время ожидания блокировки (мс)	0,035	0,019
	Операций блокировки SQL Server: взаимных блокировок в секунду	0	0
	Операций кратковременной блокировки SQL Server: среднее время ожидания (мс)	31	0,017
	Компиляций SQL Server в секунду	14,9	10,2
	Статистика SQL Server: повторных компиляций SQL Server в секунду	0,087	0,05
	Средняя длина дисковой очереди (SQL Server)	0,011	0,01
	Длина дисковой очереди: операций записи (SQL Server)	0,01	0,008
	Обращений чтения с диска в секунду (SQL Server)	0,894	0,05
	Обращений записи на диск в секунду (SQL Server)	45	106
Сервер приложений	Средняя длина дисковой очереди (сервер запросов)	0,013	0,001
	Длина дисковой очереди: операций записи (сервер запросов)	0	0,001
	Обращений чтения с диска в секунду (сервер запросов)	11,75	0,06
	Обращений записи на диск в секунду (сервер запросов)	4	5,714
	Средний объем использования памяти (сервер запросов)	8,73%	9%
	Максимальный объем использования памяти (сервер запросов)	8,75%	9%
Интерфейсный веб-сервер	Запросов ASP.NET в очереди (среднее число для всех интерфейсных веб-серверов)	0	0
	Средний объем использования памяти (интерфейсный веб-сервер)	9,67%	95%
	Максимальный объем использования памяти (интерфейсный веб-сервер)	9,74%	100%
Результаты тестирования	Число успешных запросов	1757	13 608
	Число ошибок	0	0
	Задержка пользовательского интерфейса запросов (75 процентиль)	0,331 с	3,68 с
	Задержка пользовательского интерфейса запросов (95 процентиль)	0,424 с	3,93 с
	Пропускная способность запросов	3,29 запроса в секунду	22,4 запроса в секунду

Данные по эффективности обхода контента

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

	Показатель системы показателей	Контент SharePoint (4 млн.)	Общая папка (1 млн.)	HTTP (не SharePoint) (1 млн.)
Показатели ЦП	Среднее значение использования ЦП SQL Server	5,4%	11,7%	23%
	Среднее значение использования ЦП индексатора	41,6%	69%	71%
Надежность	Процент сбоев	0	0	0
	Сбои интерфейсного веб-сервера	0	0	0
	Сбои сервера приложений	0	0	0
SQL Server	Коэффициент попадания в кэш (SQL Server)	Н/д	Н/д	Н/д
	Операций блокировки SQL Server: среднее время ожидания (мс)	436	51,76	84,73
	Операций блокировки SQL Server: время ожидания блокировки (мс)	Н/д	Н/д	Н/д
	Операций блокировки SQL Server: взаимных блокировок в секунду	Н/д	Н/д	Н/д
	Операций кратковременной блокировки SQL Server: среднее время ожидания (мс)	1,05	1,64	3,53
	Компиляций SQL Server в секунду	Н/д	Н/д	Н/д
	Статистика SQL Server: повторных компиляций SQL Server в секунду	Н/д	Н/д	Н/д
	Средняя длина дисковой очереди (SQL Server)	27,124	6,85	45
	Длина дисковой очереди: операций записи (SQL Server)	17,6	6,7	21,57
Сервер приложений	Средняя длина дисковой очереди (сервер обхода контента)	0,008	0,032	0,02
	Длина дисковой очереди: операций записи (сервер обхода контента)	0,006	0,025	0,012
	Средний объем использования памяти (сервер обхода контента)	14,16%	10,4%	11,5%
	Максимальный объем использования памяти (сервер обхода контента)	19,2%	11,13%	12,78%
Интерфейсный веб-сервер	Запросов ASP.NET в очереди (среднее число для всех интерфейсных веб-серверов)	0	0	0
	Средний объем использования памяти (интерфейсный веб-сервер)	Н/д	Н/д	Н/д
	Максимальный объем использования памяти (интерфейсный веб-сервер)	Н/д	Н/д	Н/д
Результаты тестирования	Число успешных запросов	3 934 881	1 247 838	996 982
	Число ошибок	9645	302	2
	Скорость обхода контента портала (элементов в секунду)	46,32	120,436	138,316
	Скорость обхода контента привязки (элементов в секунду)	5197	3466,219	2192,982
	Общая скорость обхода контента (элементов в секунду)	45,91	116,392	130,086

Данные тестов

В этом разделе описываются данные тестов, демонстрирующие производительность фермы. Рекомендации по повышению производительности фермы см. в разделе Оптимизация этой статьи.

Задержка запросов

На следующем графике показаны процентили задержки запросов для этой фермы по мере увеличения нагрузки (данные получены в ходе тестирования пропускной способности запросов). 95 процентиль означает, что 95% измеренных значений задержки запросов были ниже указанного значения.

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

Из этого графика видно, что, благодаря небольшому размеру индекса, в ферме поддерживается величина задержки на уровне долей секунды даже при одновременном выполнении запросов к ферме до 20 пользователями.

Пропускная способность запросов

На следующем графике показана пропускная способность запросов для этой фермы по мере увеличения нагрузки (данные получены в ходе тестирования пропускной способности запросов).

Влияние нагрузки пользователя на пропускную способность запроса

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

Скорость обхода контента

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

Частота полного обхода по типу контента

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

Выводы

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

Для повышения производительности в такой ферме рекомендуется предпринять следующие шаги:

Переместите процессы интерфейсного веб-сервера на собственный сервер (добавьте дополнительный интерфейсный веб-сервер для обеспечения избыточности).
Увеличьте объем ОЗУ на обоих серверах запросов. Рекомендуемый объем ОЗУ для сервера запросов: 33 процента от величины раздела индекса активного компонента запросов плюс 3 ГБ для операционной системы и других процессов.
Добавьте массивы запоминающих устройств, что позволит разделить базы данных на сервере базы данных.

Средняя ферма

В конфигурации средней фермы используется один веб-сервер, шесть серверов приложений и два сервера баз данных:

В этой тестовой конфигурации один веб-сервер используется для размещения центра поиска. Если поиск всегда выполняется из дочерней фермы с помощью прокси приложения-службы поиска (устанавливается в дочерней ферме), этот веб-сервер можно не использовать. В противном случае рекомендуется добавить дополнительный веб-сервер в целях обеспечения резервирования.
Два сервера приложений используются для обхода контента и администрирования. Это означает следующее:
- На одном из серверов приложений создается центр администрирования и компонент администрирования поиска.
- На каждом сервере присутствует два компонента обхода контента. Каждый из этих компонентов присоединен к отдельной базе данных обхода контента в целях обеспечения избыточности.
Оставшиеся четыре сервера приложений используются для обработки запросов. В стандартной конфигурации индекс размером до 40 миллионов элементов должен содержать 4 раздела. Избыточность функций обработки запросов достигается благодаря следующей архитектуре компонентов запросов: для каждого сервера развернут один активный компонент запросов из одного раздела индекса и резервный из другого раздела. Также в этом примере показаны действия, которые следует предпринять, если планируется увеличение размера индекса свыше 40 миллионов элементов. Для начала используется 8 разделов индекса (каждому соответствует один активный компонент и один резервный компонент обхода) на 4 серверах приложений, что позволяет свести к минимуму объем операций по разделению индекса. Предполагается, что каждый сервер приложений соответствует следующим требованиям, обеспечивающим размещение на нем 4 компонентов:
- Достаточные объем ОЗУ и число операций ввода-вывода в секунду.
- На каждом сервере используется более шести ядер ЦП для обработки:
  - Четыре ядра ЦП для двух активных компонентов запросов.
  - Два ядра ЦП для двух резервных компонентов запросов.
Два сервера баз данных обеспечивают работу фермы. На одном сервере размещается две базы данных обхода контента. На другом сервере хранятся базы данных свойств и администрирования, а также другие базы данных SharePoint. На этих серверах должно быть зарезервировано определенное число операций операций ввода-вывода в секунду для баз данных обхода контента, свойств и администрирования (например, могут использоваться разные массивы запоминающих устройств).

Спецификации

Топология

Топология поиска для средней фермы

Аппаратное обеспечение

Примечание

Веб-сервер

Веб-сервер	Интерфейсный веб-сервер (1)
Процессор	2 четырехъядерных процессора с тактовой частотой 2,33 ГГц
ОЗУ	8 ГБ
Операционная система	Windows Server 2008 R2 64-разрядная
Хранилище	2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС
Число сетевых адаптеров	2
Скорость передачи данных сетевого адаптера	1 гигабит
Проверка подлинности	NTLM
Тип службы балансировки нагрузки	Нет
Версия программного обеспечения	Microsoft SharePoint Server (предварительная версия)
Службы, запущенные локально	Все службы

Серверы приложений

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

Сервер (число)	Сервер запросов (4)	Сервер обхода контента (1), сервер обхода контента/администрирования (1)
Процессор	2 четырехъядерных процессора с тактовой частотой 2,33 ГГц	2 четырехъядерных процессора с тактовой частотой 2,33 ГГц
ОЗУ	32 ГБ	8 ГБ
Операционная система	Windows Server 2008 R2 64-разрядная	Windows Server 2008 R2 64-разрядная
Хранилище	2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС 4 жестких диска по 300 ГБ SAS 15000 об/мин: RAID10:БД	2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС/БД
Число сетевых адаптеров	2	2
Скорость передачи данных сетевого адаптера	1 гигабит	1 гигабит
Проверка подлинности	NTLM	NTLM
Тип службы балансировки нагрузки	Нет	Нет
Версия программного обеспечения	SharePoint Server 2010 (предварительная версия)	SharePoint Server 2010 (предварительная версия)
Службы, запущенные локально	Служба поиска SharePoint Server; служба параметров сайтов и запросов поиска	Служба поиска SharePoint

Серверы баз данных

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

Сервер базы данных	Базы данных администрирования поиска, свойств и другие базы данных SharePoint	Базы данных обхода контента
Процессор	2 четырехъядерных процессора с тактовой частотой 3,2 ГГц	4 двухъядерных процессора с тактовой частотой 2,19 ГГц
ОЗУ	32 ГБ	16 ГБ
Операционная система	Windows Server 2008 R2 64-разрядная	Windows Server 2008 R2 64-разрядная
Хранилище	2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС 2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ЖУРНАЛ ВРЕМЕННОЙ БД 2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ВРЕМЕННАЯ БД 6 жестких дисков по 450 ГБ SAS 15000 об/мин: RAID10: БД СВОЙСТВ 2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1: БД АДМИНИСТРИРОВАНИЯ ПОИСКА, БД SharePoint 2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ЖУРНАЛЫ	2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС 2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ЖУРНАЛ ВРЕМЕННОЙ БД 2 жестких диска по 300 ГБ SAS 15000 об/мин: RAID1:ВРЕМЕННАЯ БД 6 жестких дисков по 146 ГБ SAS 15000 об/мин: RAID10: БД1 ОБХОДА КОНТЕНТА 6 жестких дисков по 146 ГБ SAS 15000 об/мин: RAID10: БД2 ОБХОДА КОНТЕНТА 2 жестких диска по 300 ГБ SAS 15000 об/мин: RAID1: ЖУРНАЛ1 БД ОБХОДА КОНТЕНТА 2 жестких диска по 300 ГБ SAS 15000 об/мин: RAID1: ЖУРНАЛ2 БД ОБХОДА КОНТЕНТА
Число сетевых адаптеров	2	2
Скорость передачи данных сетевого адаптера	1 гигабит	1 гигабит
Проверка подлинности	NTLM	NTLM
Версия программного обеспечения	SQL Server 2008 Enterprise	SQL Server 2008 Enterprise

Рабочая нагрузка

Характеристики рабочей нагрузки	Значение
Высокоуровневое описание рабочей нагрузки	Фермы поиска
Среднее число запросов в минуту	12
Среднее число параллельных пользователей	1
Общее число запросов в день	17 280
Задания таймера	Мониторинг работоспособности поиска — трассировка событий; отчет по журналу обхода контента; задание анализа работоспособности; поиск и обработка

Набор данных

Объект	Значение
Размер индекса поиска (число элементов)	46 миллионов
Размер базы данных обхода	356 ГБ
Размер файла журнала базы данных обхода	85 ГБ
Размер базы данных свойств	304 ГБ
Размер файла журнала базы данных свойств	9 ГБ
Размер базы данных администрирования поиска	5 ГБ
Размер активных разделов индекса	316 ГБ (79 ГБ на каждый активный компонент).
Общее число баз данных	4
Другие базы данных	SharePoint_Config; SharePoint_AdminContent; State_Service; Bdc_Service_db; WSS_UsageApplication; WSS_Content

Данные о работоспособности и производительности

В этом разделе описываются данные о работоспособности и производительности для тестовой среды.

Данные по эффективности запросов

Следующие измерения были проведены для индекса поиска, содержащего 49 миллионов элементов. В столбцах приведены результаты отдельных тестов; итоговые результаты приведены в нижней части таблицы. Измерения описываются следующим образом:

Задержка запросов Эти измерения были выполнены в процессе тестирования на задержку запросов. Средством тестирования был отправлен набор стандартных запросов от имени одного пользователя, после чего была определена итоговая задержка. Во время тестирования обход контента не выполнялся.
Пропускная способность запросов Эти измерения были выполнены в процессе тестирования на пропускную способность запросов. Средством тестирования был отправлен стандартный набор запросов к ферме от имени увеличивающегося числа параллельных пользователей (до 80), после чего были определены итоговая задержка и пропускная способность. Во время тестирования обход контента не выполнялся.

	Показатель системы показателей	Задержка запросов	Пропускная способность запросов
Показатели ЦП	Среднее значение использования ЦП SQL Server (сервер базы данных свойств)	5%	98%
	Среднее значение использования ЦП интерфейсного веб-сервера	3%	33%
	Среднее значение использования ЦП сервера запросов	3%	47%
Надежность	Процент сбоев	0,07%	0%
	Сбои интерфейсного веб-сервера	0	0
	Сбои сервера приложений	0	0
SQL Server (сервер базы данных свойств)	Коэффициент попадания в кэш (SQL Server)	100%	99,9%
	Операций блокировки SQL Server: среднее время ожидания (мс)	0,000	0,159
	Операций блокировки SQL Server: время ожидания блокировки (мс)	0,000	0,080
	Операций блокировки SQL Server: взаимных блокировок в секунду	0	0
	Операций кратковременной блокировки SQL Server: среднее время ожидания (мс)	0,041	1,626
	Компиляций SQL Server в секунду	9,776	93,361
	Статистика SQL Server: повторных компиляций SQL Server в секунду	0,059	0,071
	Соотношение чтение/запись (операций ввода/вывода для базы данных)	0,01	0,81
	Средняя длина дисковой очереди (SQL Server)	0,001	0,037
	Длина дисковой очереди: операций записи (SQL Server)	0,000	0,003
	Обращений чтения с диска в секунду (SQL Server)	0,057	14,139
	Обращений записи на диск в секунду (SQL Server)	4,554	17,515
Сервер приложений	Средняя длина дисковой очереди (сервер запросов)	0,000	0,001
	Длина дисковой очереди: операций записи (сервер запросов)	0,000	0,001
	Обращений чтения с диска в секунду (сервер запросов)	0,043	0,266
	Обращений записи на диск в секунду (сервер запросов)	4,132	5,564
	Средний объем использования памяти (сервер запросов)	9%	10%
	Максимальный объем использования памяти (сервер запросов)	9%	10%
Интерфейсный веб-сервер	Запросов ASP.NET в очереди (среднее число для всех интерфейсных веб-серверов)	0	0
	Средний объем использования памяти (интерфейсный веб-сервер)	47%	48%
	Максимальный объем использования памяти (интерфейсный веб-сервер)	47%	49%
Результаты тестирования	Число успешных запросов	1398	14 406
	Число ошибок	1	0
	Задержка пользовательского интерфейса запросов (75 процентиль)	0,47 с	2,57 с
	Задержка пользовательского интерфейса запросов (95 процентиль)	0,65 с	3,85 с
	Пропускная способность запросов	2,38 запроса в секунду	27,05 запроса в секунду

Данные по эффективности обхода контента

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

	Показатель системы показателей	Контент SharePoint (3,5 млн.)	Общая папка (1 млн.)	HTTP (не SharePoint) (1 млн.)
Показатели ЦП	Среднее значение использования ЦП SQL Server (серверы баз данных обхода контента и свойств)	11%, 19%	22%, 7%	23%, 5%
	Максимальное значение использования ЦП SQL Server (сервер базы данных обхода контента и свойств)	96%, 100%	86%, 45%	79%, 28%
	Среднее значение использования ЦП индексатора	41,6%	69%	71%
Надежность	Процент сбоев	0,2%	0,02%	0%
	Сбои интерфейсного веб-сервера	0	0	0
	Сбои сервера приложений	0	0	0
SQL Server (серверы баз данных обхода контента и свойств)	Коэффициент попадания в кэш (SQL Server)	99,5%; 99,8%	Сбор не выполнялся	99,9%; 99,3%
	Операций блокировки SQL Server: среднее время ожидания [мс]	1881,749; 1106,314	1617,980; 2,882	983,137; 0,904
	Операций блокировки SQL Server: максимальное время ожидания [мс]	69 919,500; 1 081 703	55 412,000; 304,500	24 000,500; 47
	Операций блокировки SQL Server: среднее время ожидания блокировки [мс]	339,658; 10 147,012	Сбор не выполнялся	739,232; 0,136
	Операций блокировки SQL Server: максимальное время ожидания блокировки [мс]	598 106,544; 234 708 784	Сбор не выполнялся	52 711,592; 23,511
	Операций блокировки SQL Server: взаимных блокировок в секунду	0,001; 0	Сбор не выполнялся	0,008; 0
	Операций кратковременной блокировки SQL Server: среднее время ожидания [мс]	2,288; 13,684	3,042; 13,516	2,469; 20,093
	Операций кратковременной блокировки SQL Server: максимальное время ожидания [мс]	2636; 1809	928; 858,5	242,929; 938,706
	Компиляций SQL Server в секунду: в среднем	20,384; 5,449	Сбор не выполнялся	76,157; 6,510
	Компиляций SQL Server в секунду: максимум	332,975; 88,992	Сбор не выполнялся	295,076; 42,999
	Статистика SQL Server: повторных компиляций SQL Server в секунду: в среднем	0,560; 0,081	Сбор не выполнялся	0,229; 0,125
	Статистика SQL Server: повторных компиляций SQL Server в секунду: максимум	22,999; 88,492	Сбор не выполнялся	17,999; 15,5
	Соотношение чтение/запись (операций ввода/вывода для базы данных): максимум	2,15; 1,25	Сбор не выполнялся	1,45; 0,364
	Средняя длина дисковой очереди (SQL Server)	66,765; 27,314	129,032; 20,665	182,110; 11,816
	Максимальная длина дисковой очереди (SQL Server)	4201,185; 5497,980	3050,015; 762,542	1833,765; 775,7
	Длина дисковой очереди: операций записи (SQL Server): в среднем	58,023; 13,532	114,197; 19,9	175,621; 10,417
	Длина дисковой очереди: операций записи (SQL Server): максимум	1005,691; 881,892	1551,437; 761,891	1018,642; 768,289
	Обращений чтения с диска в секунду (SQL Server): в среднем	245,945; 94,131	Сбор не выполнялся	137,435; 154,103
	Обращений чтения с диска в секунду (SQL Server): максимум	6420,412; 6450,870	Сбор не выполнялся	3863,283; 1494,805
	Обращений записи на диск в секунду (SQL Server): в среднем	458,144; 286,884	Сбор не выполнялся	984,668; 278,175
	Обращений записи на диск в секунду (SQL Server): максимум	2990,779; 5164,949	Сбор не выполнялся	2666,285; 4105,897
Сервер приложений	Средняя длина дисковой очереди (сервер обхода контента)	0,052	0,043	0,030
	Длина дисковой очереди: операций записи (сервер обхода контента)	0,029	0,031	0,026
	Обращений чтения с диска в секунду (сервер обхода контента)	5,405	Сбор не выполнялся	0,798
	Обращений записи на диск в секунду (сервер обхода контента)	48,052	Сбор не выполнялся	102,235
	Средний объем использования памяти (сервер обхода контента)	68%	45%	52%
	Максимальный объем использования памяти (сервер обхода контента)	76%	47%	59%
Интерфейсный веб-сервер	Запросов ASP.NET в очереди (среднее число для всех интерфейсных веб-серверов)	0	0	0
	Средний объем использования памяти (интерфейсный веб-сервер)	Н/д	Н/д	Н/д
	Максимальный объем использования памяти (интерфейсный веб-сервер)	Н/д	Н/д	Н/д
Результаты тестирования	Число успешных запросов	3 631 080	1 247 838	200 000
	Число ошибок	7930	304	0
	Скорость обхода контента портала (элементов в секунду)	82	148	81
	Скорость обхода контента привязки (элементов в секунду)	1573	1580	1149
	Общая скорость обхода контента (элементов в секунду)	79	136	76

Данные тестов

В этом разделе описываются данные тестов, демонстрирующие производительность фермы под нагрузкой.

Задержка запросов

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

Из этого графика видно, что, благодаря небольшому размеру индекса, в ферме поддерживается величина задержки на уровне долей секунды для 95 процентиля даже при одновременном выполнении запросов к ферме до 22 пользователями.

Пропускная способность запросов

Влияние нагрузки пользователя на пропускную способность запроса

По данным приведенного выше графика видно, что для индекса, содержащего 33 миллиона элементов, в ферме удается поддерживать задержку на уровне долей секунды для 75 процентиля при одновременном выполнении запросов 30 пользователями. При этом возможно увеличение нагрузки за счет роста числа пользователей, что, однако, будет сопровождаться задержками запросов более 1 секунды.

При 46 миллионах элементов в индексе увеличение числа пользователей будет сопровождаться существенных ростом задержки запросов.

Скорость обхода контента

Частота полного обхода по типу контента

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

Выводы

В этой ферме практически максимальная загрузка ОЗУ на серверах обработки запросов.

Для повышения производительности в такой ферме рекомендуется предпринять следующие шаги:

Увеличьте объем ОЗУ на обоих серверах запросов. Рекомендуемый объем ОЗУ для сервера запросов: 33 процента от величины раздела индекса активного компонента запросов плюс 3 ГБ для операционной системы и других процессов.
Увеличьте объем ОЗУ на сервере, на котором размещается база данных свойств. В этой конфигурации размер таблицы ключей составляет около 92 ГБ (с учетом индексов), что предполагает наличие около 30 ГБ ОЗУ. Тем не менее, на сервере базы данных доступно всего 32 ГБ ОЗУ для обслуживания баз данных свойств, администрирования поиска и других баз данных SharePoint Server.
Добавьте массивы запоминающих устройств, что позволит разделить базы данных на сервере базы данных.
Выполните горизонтальное масштабирование, чтобы увеличить пропускную способность или уменьшить задержку.

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

Крупная ферма

В предполагаемой конфигурации используется 1 веб-сервер, 13 серверов приложений и 3 сервера баз данных:

На одном веб-сервере размещается центр поиска. Если поиск всегда выполняется из фермы контента с помощью прокси приложения-службы поиска (устанавливается в ферме контента), этот веб-сервер можно не использовать.
Три сервера приложений используются для обхода контента и администрирования. Это означает следующее:
- На одном из серверов приложений создается центр администрирования и компонент администрирования поиска.
- На каждом сервере присутствует два компонента обход контента. Каждый из этих компонентов присоединен к отдельной базе данных обхода контента.
Оставшиеся 10 серверов приложений используются для обработки запросов. Рекомендуется создать 10 разделов индекса. На каждом сервере развернут один основной компонент запросов из одного из разделов индекса, а также резервный компонент из другого раздела.
Четыре сервера баз данных обеспечивают работу фермы. На одном сервере размещаются базы данных свойств и администрирования поиска. На втором сервере хранится база данных свойств. На третьем сервере размещаются две базы данных обхода контента. На четвертом сервере находятся одна база данных обхода и остальные базы данных SharePoint. На этих серверах должно быть зарезервировано определенное число операций операций ввода-вывода в секунду для баз данных обхода контента, свойств и администрирования (например, могут использоваться разные массивы запоминающих устройств).

Спецификации

Топология

В этом разделе описывается топология тестовой среды.

Топология поиска для большой фермы

Аппаратное обеспечение

В этом разделе описывается используемое при тестировании оборудование.

Примечание

Веб-серверы

Веб-сервер	Интерфейсный веб-сервер (1)
Процессор	2 четырехъядерных процессора с тактовой частотой 2,33 ГГц
ОЗУ	8 ГБ
Операционная система	Windows Server 2008 R2 64-разрядная
Хранилище	2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС
Число сетевых адаптеров	2
Скорость передачи данных сетевого адаптера	1 гигабит
Проверка подлинности	NTLM
Тип службы балансировки нагрузки	Нет
Версия программного обеспечения	SharePoint Server 2010 (предварительная версия)
Службы, запущенные локально	Все службы

Серверы приложений

В ферме развернуты 13 серверов приложений. 10 серверов используются для обработки запросов; 3 сервера обеспечивают обход контента.

Сервер (число)	Сервер запросов (10)	Сервер обхода контента (2), сервер обхода контента/администрирования (1)
Процессор	2 четырехъядерных процессора с тактовой частотой 2,5 ГГц	2 четырехъядерных процессора с тактовой частотой 2,5 ГГц
ОЗУ	32 ГБ	32 ГБ
Операционная система	Windows Server 2008 R2 64-разрядная	Windows Server 2008 R2 64-разрядная
Хранилище	2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС 4 жестких диска по 300 ГБ SAS 15000 об/мин: RAID10:БД	2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС/БД
Число сетевых адаптеров	2	2
Скорость передачи данных сетевого адаптера	1 гигабит	1 гигабит
Проверка подлинности	NTLM	NTLM
Тип службы балансировки нагрузки	Нет	Нет
Версия программного обеспечения	SharePoint Server 2010 (предварительная версия)	SharePoint Server 2010 (предварительная версия)
Службы, запущенные локально	Служба поиска SharePoint Server; служба параметров сайтов и запросов поиска	Служба поиска SharePoint

Серверы баз данных

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

Сервер базы данных	Базы данных администрирования поиска, свойств и другие базы данных SharePoint	Базы данных обхода контента
Процессор	2 четырехъядерных процессора с тактовой частотой 3,2 ГГц	4 двухъядерных процессора с тактовой частотой 2,19 ГГц
ОЗУ	32 ГБ	16 ГБ
Операционная система	Windows Server 2008 R2 64-разрядная	Windows Server 2008 R2 64-разрядная
Хранилище	2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС 2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ЖУРНАЛ ВРЕМЕННОЙ БД 2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ВРЕМЕННАЯ БД 6 жестких дисков по 450 ГБ SAS 15000 об/мин: RAID10: БД СВОЙСТВ 2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1: БД АДМИНИСТРИРОВАНИЯ ПОИСКА, БД SharePoint 2 жестких диска по 450 ГБ SAS 15000 об/мин: RAID1:ЖУРНАЛЫ	2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ОС 2 жестких диска по 148 ГБ SAS 15000 об/мин: RAID1:ЖУРНАЛ ВРЕМЕННОЙ БД 2 жестких диска по 300 ГБ SAS 15000 об/мин: RAID1:ВРЕМЕННАЯ БД 6 жестких дисков по 146 ГБ SAS 15000 об/мин: RAID10: БД1 ОБХОДА КОНТЕНТА 6 жестких дисков по 146 ГБ SAS 15000 об/мин: RAID10: БД2 ОБХОДА КОНТЕНТА 2 жестких диска по 300 ГБ SAS 15000 об/мин: RAID1: ЖУРНАЛ1 БД ОБХОДА КОНТЕНТА 2 жестких диска по 300 ГБ SAS 15000 об/мин: RAID1: ЖУРНАЛ2 БД ОБХОДА КОНТЕНТА
Число сетевых адаптеров	2	2
Скорость передачи данных сетевого адаптера	1 гигабит	1 гигабит
Проверка подлинности	NTLM	NTLM
Версия программного обеспечения	SQL Server 2008 Enterprise	SQL Server 2008 Enterprise

Данные по эффективности запросов

Следующие измерения были проведены для индекса, содержащего 103 миллиона элементов. В столбцах приведены результаты отдельных тестов; итоговые результаты приведены в нижней части таблицы. Измерения описываются следующим образом:

Задержка запросов Эти измерения были выполнены в процессе тестирования на задержку запросов. Средством тестирования был отправлен набор стандартных запросов от имени одного пользователя, после чего была определена итоговая задержка. Во время тестирования обход контента не выполнялся.
Пропускная способность запросов Эти измерения были выполнены в процессе тестирования на пропускную способность запросов. Средством тестирования был отправлен стандартный набор запросов к ферме от имени увеличивающегося числа параллельных пользователей (до 120), после чего были определены итоговая задержка и пропускная способность. Во время тестирования обход контента не выполнялся.

	Показатель системы показателей	Пропускная способность запросов
Показатели ЦП	Среднее значение использования ЦП SQL Server (сервер базы данных свойств)	34%
	Среднее значение использования ЦП интерфейсного веб-сервера	45%
	Среднее значение использования ЦП сервера запросов	20%
Надежность	Процент сбоев	0%
	Сбои интерфейсного веб-сервера	0
	Сбои сервера приложений	0
SQL Server (сервер базы данных свойств)	Коэффициент попадания в кэш (SQL Server)	100%
	Операций блокировки SQL Server: среднее время ожидания (мс)	0
	Операций блокировки SQL Server: время ожидания блокировки (мс)	0
	Операций блокировки SQL Server: взаимных блокировок в секунду	0
	Операций кратковременной блокировки SQL Server: среднее время ожидания (мс)	1,401
	Компиляций SQL Server в секунду	73,349
	Статистика SQL Server: повторных компиляций SQL Server в секунду	0,006
	Соотношение чтение/запись (операций ввода/вывода для базы данных)	0,81
	Средняя длина дисковой очереди (SQL Server)	0,037
	Длина дисковой очереди: операций записи (SQL Server)	0,003
	Обращений чтения с диска в секунду (SQL Server)	9,88
	Обращений записи на диск в секунду (SQL Server)	354,1
Сервер приложений	Средняя длина дисковой очереди (сервер запросов)	0,002
	Длина дисковой очереди: операций записи (сервер запросов)	0,002
	Обращений чтения с диска в секунду (сервер запросов)	0,035
	Обращений записи на диск в секунду (сервер запросов)	6,575
	Средний объем использования памяти (сервер запросов)	6,548%
	Максимальный объем использования памяти (сервер запросов)	6,601%
Интерфейсный веб-сервер	Запросов ASP.NET в очереди (среднее число для всех интерфейсных веб-серверов)	0
	Средний объем использования памяти (интерфейсный веб-сервер)	18,081%
	Максимальный объем использования памяти (интерфейсный веб-сервер)	19,983%
Результаты тестирования	Число успешных запросов	10 925
	Число ошибок	0
	Задержка пользовательского интерфейса запросов (75 процентиль)	3,431 с
	Задержка пользовательского интерфейса запросов (95 процентиль)	3,512 с
	Пропускная способность запросов	36,42 запроса в секунду

Данные по эффективности обхода контента

	Показатель системы показателей	Контент SharePoint (3,5 млн.)	Общая папка (1 млн.)
Показатели ЦП	Среднее значение использования ЦП SQL Server (серверы баз данных обхода контента и свойств)	15,74%, н/д	24%; 6,6%
	Максимальное значение использования ЦП SQL Server (сервер базы данных обхода контента и свойств)	100%, н/д	100%, 45%
	Среднее значение использования ЦП индексатора	44%	49%
Надежность	Процент сбоев	0,0%	0,00%
	Сбои интерфейсного веб-сервера	0	0
	Сбои сервера приложений	0	0
SQL Server (серверы баз данных обхода контента и свойств)	Коэффициент попадания в кэш (SQL Server)	99,8%, н/д	99,797%; 99,49%
	Операций блокировки SQL Server: среднее время ожидания [мс]	734,916, н/д	1165; 5,866
	Операций блокировки SQL Server: максимальное время ожидания [мс]	15 335, н/д	28 683; 210,5
	Операций блокировки SQL Server: среднее время ожидания блокировки [мс]	108,98, н/д	847,72; 5,325
	Операций блокировки SQL Server: максимальное время ожидания блокировки [мс]	17 236,96, н/д	124 353; 12 920
	Операций блокировки SQL Server: взаимных блокировок в секунду	0, н/д	0,012; 0
	Операций кратковременной блокировки SQL Server: среднее время ожидания [мс]	1,4, н/д	2,233; 40,6
	Операций кратковременной блокировки SQL Server: максимальное время ожидания [мс]	1606, н/д	917,8; 1 895
	Компиляций SQL Server в секунду: в среднем	24,28, н/д	72,7; 11,39
	Компиляций SQL Server в секунду: максимум	416, н/д	460; 76,62
	Статистика SQL Server: повторных компиляций SQL Server в секунду: в среднем	0,560, н/д	0,295; 0,099
	Статистика SQL Server: повторных компиляций SQL Server в секунду: максимум	0,24, н/д	17,50; 17,393
	Соотношение чтение/запись (операций ввода/вывода для базы данных): максимум	20,3, н/д	1,18/0,214
	Средняя длина дисковой очереди (SQL Server)	90,113, н/д	138,64; 27,478
	Максимальная длина дисковой очереди (SQL Server)	3179, н/д	2783,543; 847,574
	Длина дисковой очереди: операций записи (SQL Server): в среднем	86,93, н/д	130 853; 26,086
	Длина дисковой очереди: операций записи (SQL Server): максимум	1882, н/д	2781,197; 884,801
	Обращений чтения с диска в секунду (SQL Server): в среднем	99, н/д	147,462; 159,159
	Обращений чтения с диска в секунду (SQL Server): максимум	3772, н/д	2403,336; 896,462
	Обращений записи на диск в секунду (SQL Server): в среднем	373, н/д	475,886; 539,497
	Обращений записи на диск в секунду (SQL Server): максимум	18 522, н/д	2031,888; 4174,271
Сервер приложений	Средняя длина дисковой очереди (сервер обхода контента)	0,075	0,063
	Длина дисковой очереди: операций записи (сервер обхода контента)	0,046	0,053
	Обращений чтения с диска в секунду (сервер обхода контента)	1,958	1,693
	Обращений записи на диск в секунду (сервер обхода контента)	62,33	101,093
	Средний объем использования памяти (сервер обхода контента)	59%	56,38%
	Максимальный объем использования памяти (сервер обхода контента)	70%	58,93%
Интерфейсный веб-сервер	Запросов ASP.NET в очереди (среднее число для всех интерфейсных веб-серверов)	Н/д	Н/д
	Средний объем использования памяти (интерфейсный веб-сервер)	Н/д	Н/д
	Максимальный объем использования памяти (интерфейсный веб-сервер)	Н/д	Н/д
Результаты тестирования	Число успешных запросов	1 909 739	1 247 838
	Число ошибок	9361	331
	Скорость обхода контента портала (элементов в секунду)	70,3	131,44
	Скорость обхода контента привязки (элементов в секунду)	764	525,84
	Общая скорость обхода контента (элементов в секунду)	64	105

Масштабирование системы поиска

В этом разделе описывается система поиска, а также приводятся требования и рекомендации по масштабированию для отдельных компонентов.

Существует несколько вариантов развертывания и настройки SharePoint Server 2010. Таким образом, не существует простого способа оценить, сколько пользователей или элементов будет поддерживаться для указанного количества серверов. Следовательно, перед развертыванием SharePoint Server 2010 в рабочей среде рекомендуется провести собственное тестирование.

Система поисковых запросов

В этом разделе описываются компоненты системы поисковых запросов для заданного приложения-службы поиска. Требования к масштабированию для каждого компонента приведены в таблице "Сведения о масштабировании" после следующего рисунка.

Система поисковых запросов

Описание объектов

В следующем списке определяются объекты системы поисковых запросов, показанные на предыдущем рисунке:

Прокси-служба поиска Прокси-служба приложения-службы поиска, которая устанавливается в любой ферме, использующей функции поиска этого приложения-службы. Выполняется в контексте веб-приложений, связанных с прокси приложения-службы поиска.
Служба параметров сайтов и запросов поиска Также называется обработчиком запросов. При получении запроса из подключения прокси приложения-службы поиска обработчик запросов выполняет следующие действия:
- Запрос отправляется в один активный компонент запросов для каждого раздела индекса (в базу данных свойств или в оба адресата, в зависимости от типа запроса)
- Извлекаются наиболее подходящие элементы; из полученного набора результатов удаляются повторяющиеся элементы
- Выполняется фильтрация результатов по ролям безопасности на основе дескрипторов безопасности в базе данных администрирования поиска
- Из базы данных свойств извлекаются метаданные итогового набора результатов
- Результаты запроса отправляются в прокси-службу
Раздел индекса Это логическая группа компонентов запросов, которые представляют собой подмножество полнотекстового индекса. В совокупности все разделы индекса формируют полнотекстовый индекс. Следует обратить внимание, что компоненты запросов содержат фактическое подмножество индекса. Каждый раздел индекса связан с одной базой данных свойств.
Компонент запросов поиска Компонент запросов может содержать весь полнотекстовый индекс или его часть. При получении запроса от обработчика запросов компонент определяет наиболее подходящие результаты из индекса и возвращает их. Создаваемый компонент запросов может иметь одно из следующих предназначений:
- Активный — по умолчанию отвечает на запросы. Добавление нескольких активных компонентов в один раздел индекса позволяет увеличить пропускную способность.
- Резервный — отвечает на запросы только в том случае, если их не обрабатывает ни один из активных компонентов для этого раздела индекса.
База данных администрирования поиска Создается одновременно с приложением-службой поиска и содержит данные на уровне этого приложения, которые используются для обработки запросов (например, сведения о наиболее подходящих элементах, дескрипторы безопасности, а также параметры приложений).
База данных свойств Содержит метаданные (название, автор, связанные поля) для элементов индекса. База данных свойств используется для обработки запросов на основе свойств в дополнение к процессу извлечения метаданных, необходимых для отображения итоговых результатов. Разделы индекса можно сопоставлять с разными базами данных свойств.

Сведения о масштабировании

Объект	Рекомендации по масштабированию	ОЗУ	Число операций ввода-вывода в секунду (чтение/запись)
Прокси-служба поиска	Масштабируется с использованием интерфейсных веб-серверов, с которыми она связана.	Н/д	Н/д
Служба параметров сайтов и запросов поиска	Эта служба устанавливается на странице Службы на сервере центра администрирования и должна быть запущена на каждом сервере с компонентом запросов. При необходимости эту службу можно перенести на отдельный сервер (или пару серверов для более высокой доступности), чтобы высвободить ОЗУ серверов, на которых размещаются компоненты запросов. Использование настраиваемого триммера безопасности (Возможно, на английском языке) также может отрицательно повлиять на загрузку ЦП и ОЗУ.	Использует ОЗУ (кэш процессов) для кэширования дескрипторов безопасности индекса.	Н/д
Раздел индекса	При увеличении числа разделов индекса уменьшается число элементов в каждом из них, что ведет к менее интенсивному использованию ОЗУ и дискового пространства на сервере запросов, на котором размещаются компоненты запросов, назначенные разделу индекса.	Н/д	Н/д
Компонент запросов	Каждый активный компонент запросов на сервере при обработке запросов потребляет память. При этом каждый активный компонент создается или изменяется в составе топологии приложения-службы поиска. В процессе обхода контента и активный, и резервный компоненты выполняют операции чтения и записи. При соблюдении требований к ОЗУ и производительности операций ввода-вывода можно использовать выделенные серверы для компонентов запроса (например, два активных и два резервных компонента на одном сервере). По возможности следует использовать как минимум два выделенных ядра ЦП на каждый активный компонент, а также как минимум одно ядро ЦП на каждый резервный компонент на сервере.	Объем ОЗУ (кэша операционной системы) для каждого активного компонента на сервере приложений должен обеспечивать хранение 33% индекса.	2000 операций ввода-вывода в секунду для каждой пары (активный/резервный) компонентов запросов для заданного сервера. Компонент запросов выполняет операции ввода-вывода в следующих целях: Загрузка индекса в ОЗУ для запросов Запись фрагментов индекса, полученных от каждого компонента обхода контента Объединение фрагментов индекса, например, в ходе процедуры объединения с главной копией
База данных администрирования поиска	Для каждого запроса из базы данных администрирования поиска загружаются наиболее подходящие элементы и дескрипторы безопасности. Убедитесь, что на сервере баз данных выделен достаточный объем ОЗУ для обслуживания этого кэша. Рекомендуется по возможности не размещать эту базу данных на одном сервере с базой данных обхода контента, поскольку для последней часто выполняется сброс кэша соответствующего сервера баз данных.	Убедитесь, что на сервере баз данных выделен достаточный объем ОЗУ для хранения важной таблицы (MSSSecurityDescriptors) в ОЗУ.	700
База данных свойств	Для каждого запроса из базы данных свойств извлекаются метаданные, соответствующие возвращаемым результатам, поэтому для повышения производительности рекомендуется увеличить объем ОЗУ на сервере баз данных. При наличии нескольких разделов индекса можно разделить базу данных свойств и перенести ее на другой сервер, что позволит снизить загрузку ОЗУ и число используемых операций ввода-вывода в секунду.	Убедитесь, что на сервере баз данных выделен достаточный объем ОЗУ для хранения 33% от объема важных таблиц (MSSDocSDIDs + MSSDocProps + MSSDocresults) в кэше.	2000 30% чтение, 70% запись

Система обхода при поиске

В этом разделе описываются компоненты системы обхода при поиске. Требования к масштабированию для каждого компонента приводятся в таблице после рисунка.

Система обхода при поиске

Описание объектов

В этом разделе определяются объекты системы обхода при поиске, показанные на предыдущем рисунке:

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

Сведения о масштабировании

Объект	Рекомендации по масштабированию	ОЗУ	Число операций ввода-вывода в секунду (необязательно, % чтение/запись)
Компонент администрирования	Отдельный компонент администрирования не поддерживает масштабирование. По умолчанию он располагается на сервере, на котором размещается компонент обхода контента (в малых фермах на этом сервере также размещается центр администрирования).	Минимальное	Минимальное
Компонент обхода контента	Компоненты обхода контента активно используют ресурсы ЦП. В идеальном варианте для каждого такого компонента требуется четыре выделенных ядра ЦП. Требования к ОЗУ носят менее критичный характер. В более крупных фермах для снижения воздействия программы-обходчика на другие компоненты компоненты обхода контента размещаются на выделенных серверах (особенно это касается сценариев с использование компонентов обхода, связанных с разными базами данных обхода контента в целях обеспечения избыточности).	Умеренное. Обратите внимание, что при обходе контента документов на восточноазиатских языках требования к ОЗУ возрастают в связи с поддержкой средств разбиения текста на слова.	300–400
База данных администрирования поиска	См. описание системы поисковых запросов выше. Рекомендуется по возможности не размещать эту базу данных на одном сервере с базой данных обхода контента, поскольку для последней часто выполняется сброс кэша соответствующего сервера баз данных.	См. описание системы поисковых запросов выше.	700
База данных обхода контента	Базы данных обхода контента активно используют ресурсы подсистемы ввода-вывода. Требования к ОЗУ носят менее критичный характер. На операции, связанные с обходом контента затрачивается порядка 3500 операций ввода-вывода в секунду; при достаточной пропускной способности это число может возрастать до 6000.	Умеренное	3500–7000 73% чтение, 27% запись

Расчет размера хранилища

Чтобы оценить требования к размеру хранилища, рассчитайте следующие коэффициенты. Коэффициенты масштабирования определяются на основе внутренней системы до развертывания с индексом, содержащим преимущественно контент SharePoint (размер базы данных контента 13,3 ТБ). В общем случае система поиска SharePoint использует приблизительно 20% от дискового пространства, занимаемого базой данных контента. Рекомендуется провести тестирование в собственной среде, прежде чем развертывать SharePoint Server 2010 в рабочей среде.

Примечание.

Собрание, для которого рассчитывались эти коэффициенты, содержит преимущественно англоязычный контент SharePoint. При наличии другого контента (например, если собрание включает преимущественно общие сетевые папки или сайты, не являющиеся сайтами SharePoint HTTP), результаты могут существенно отличаться.
Даже если в собрании хранится в основном контент SharePoint, на величину коэффициентов могут дополнительно влиять следующие обстоятельства:
- При наличии крупных репозиториев документов величины коэффициентов значительно возрастают.
- Если собрание содержит преимущественно изображения, коэффициенты могут быть меньше.
- Наличие многоязычного контента также может повлиять на величину коэффициентов.

1. Расчет коэффициента масштабирования базы данных контента (ContentDBSum)

Определите суммарный объем баз данных контента SharePoint, для которых будет выполняться обход контента. Это значение, ContentDBSum, будет использоваться при дальнейших вычислениях объема хранилища.

2. Расчет размеров индекса (TotalIndexSize и QueryComponentIndexSize)

Определите полный размер индекса (располагается в компонентах запросов и используется для полнотекстовых запросов):

Умножьте величину ContentDBSum на 0,035. Будет получено значение TotalIndexSize до создания разделов и резервирования места для объединения и разбиения на разделы.

Далее определите число разделов в соответствии с архитектурой среды и сценарием. Рекомендуемый размер раздела индекса находится в диапазоне от 5 до 10 миллионов элементов. После этого можно рассчитать размер хранилища для компонента запросов.

Разделите значение TotalIndexSize на (число разделов индекса). Будет получено значение QueryComponentIndexSize, которое используется для расчета следующих величин:
- Умножьте величину QueryComponentIndexSize на 0,33. Будет получено значение, соответствующее минимально необходимому объему ОЗУ для активного компонента.
  - Резервные компоненты потребляют ресурсы ОЗУ только после того, как переводятся в активное состояние.
  - Если на сервере присутствует несколько активных компонентов запросов, чтобы определить совокупные требования к ОЗУ, следует сложить требования для каждого из компонентов.
- С помощью величины QueryComponentIndexSize также можно определить требования к дисковому пространству в зависимости от того, планируется ли разбиение индекса на разделы (т. е., планируется ли рост индекса свыше 10 миллионов элементов):
  - Умножьте величину QueryComponentIndexSize на 3. Будет получен объем дискового пространства для отдельного компонента запросов с учетом требований к пространству для объединения индекса.
  - Умножьте величину QueryComponentIndexSize на 4. Будет получен объем дискового пространства для отдельного компонента запросов с учетом требований к пространству для разбиения индекса на разделы.

Если на сервере развернуто несколько компонентов запросов, требования к дисковому пространству для каждого из них должны согласовываться с требованиями к числу операций ввода-вывода в секунду (см. подраздел "Сведения о масштабировании" в разделе "Система поисковых запросов" этой статьи).

3. Расчет размеров баз данных свойств

Определите размеры баз данных свойств:

Умножьте величину ContentDBSum на 0,015. Будет получено значение TotalPropertyDBSize до разбиения на разделы.
Умножьте величину ContentDBSum на 0,0031. Будет получено значение TotalPropertyDBLogSize до разбиения на разделы. Предполагается, что базы данных SQL Server используют простую модель восстановления.
Умножьте величину ContentDBSum на 0,00034. Будет получена величина TempDBSize для базы данных свойств. Поскольку рекомендуется хранение 33% таблиц ключей базы данных свойств в ОЗУ, временная база данных используется неактивно.

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

Разделите величину TotalPropertyDBSize на (число баз данных свойств). Будет получено значение PropertyDatabaseSize.
Разделите величину TotalPropertyDBLogSize на (число баз данных свойств). Будет получено значение PropertyDatabaseLogSize.
Умножьте величину PropertyDatabaseSize на 0,33. Будет получено значение, соответствующее минимально необходимому объему ОЗУ для этой базы данных свойств.

Если на сервере баз данных развернуто несколько баз данных свойств, требования к дисковому пространству и ОЗУ для каждой из них должны согласовываться с требованиями к числу операций ввода-вывода в секунду и ОЗУ (см. подраздел "Сведения о масштабировании" в разделе "Система поисковых запросов" этой статьи).

4. Расчет размеров баз данных обхода контента

Далее определите размер базы данных контента:

Умножьте величину ContentDBSum на 0,046. Будет получено значение TotalCrawlDBSize до разбиения на разделы.
Умножьте величину ContentDBSum на 0,011. Будет получено значение TotalCrawlDBLogSize до разбиения на разделы. Предполагается, что базы данных SQL Server используют простую модель восстановления.
Умножьте величину ContentDBSum на 0,0011. Будет получена величина TempDBSize для базы данных обхода контента. Поскольку система обхода при поиске влияет на производительность временной базы данных, не рекомендуется размещать другие базы данных на серверах, на которых размещаются базы данных обхода контента, если это может привести к снижению производительности.

Далее определите число баз данных обхода контента в соответствии с архитектурой и сценарием. Рекомендуемый размер базы данных обхода контента составляет не более 25 миллионов элементов. При этом предполагается отсутствие проблем, связанных с производительностью обхода.

Разделите величину TotalCrawlDBSize на (число баз данных обхода контента). Будет получено значение CrawlDatabaseSize.
Разделите величину TotalCrawlDBLogSize на (число баз данных обхода контента). Будет получено значение CrawlDatabaseLogSize.

Если на сервере баз данных развернуто несколько баз данных обхода контента, требования к дисковому пространству для каждой из них должны согласовываться с требованиями к числу операций ввода-вывода в секунду (см. подраздел "Сведения о масштабировании" в разделе "Система обхода при поиске" этой статьи). На выделенном сервере для баз данных обхода контента рекомендуется наличие как минимум 16 ГБ ОЗУ.

5. Расчет размера базы данных администрирования поиска

Определите размер базы данных администрирования поиска (предполагается применение проверки подлинности Windows):

Умножьте число элементов в индексе (в миллионах) на 0,3. Будет получено значение SearchAdminDBSize.
Умножьте величину SearchAdminDBSize на 0,33. Будет получено значение, соответствующее минимально необходимому объему ОЗУ для этой базы данных свойств.

Если на сервере баз данных развернуто несколько баз данных, требования к дисковому пространству и ОЗУ для каждой из них должны согласовываться с требованиями к числу операций ввода-вывода в секунду и ОЗУ (см. подраздел "Сведения о масштабировании" в разделе "Система поисковых запросов" этой статьи).

Необязательно. Расчет размера резервной копии

Чтобы определить объем дискового пространства для резервного копирования одного приложения-службы поиска, выполните следующие вычисления:

Сложите величины TotalCrawlDBSize + TotalPropertyDBSize + TotalIndexSize + SearchAdminDBSize. Будет получен базовый размер резервной копии.

Базовый размер резервной копии является отправной точкой и может изменяться в зависимости от следующих факторов:

Дополнительный размер индекса, включаемый в величину TotalIndexSize для обхода контента с момента последнего объединения с главной копией.
Рост с течением времени в связи с добавлением дополнительных элементов, запросов и дескрипторов безопасности.

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

Пример расчета коэффициентов масштабирования

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

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

Чтобы определить требования к хранилищу и ОЗУ, выполните следующие действия:

В ферме SharePoint с несколькими базами данных контента совокупный объем включаемого в обход контента составляет 20 ТБ.
Умножьте 20 ТБ на 0,035 (коэффициент индекса). Будет получено значение TotalIndexSize, равное 716,8 ГБ. Если используется один раздел индекса, это значение определяет его размер.
Разделите значение TotalIndexSize на число разделов: 716,8 ГБ / 10 = 71,68 ГБ. Это размер индекса для каждого компонента запросов (QueryComponentIndexSize) с одним разделом индекса. Эта величина одинакова для активных и резервных компонентов запросов.
Умножьте TotalIndexSize на 4, если планируется разбиение индекса на разделы; в противном случае умножьте это значение на 3, чтобы обеспечить поддержку объединения с главной копией. 71,68 ГБ * 4 = 286,72 ГБ. Соответственно, для поддержки одного компонента запросов требуется 286,72 ГБ свободного дискового пространства на сервере запросов. Если на одном сервере приложений размещается два компонента запросов (как, например, в рекомендуемой для крупных ферм топологии "активный/резервный"), требования к дисковому пространству будут следующими:
1. Диск операционной системы (стандартный размер).
2. Дополнительная система хранения 1: общая папка компонента запросов 1 (размер не менее 300 ГБ), используется для активного компонента раздела индекса 1.
3. Дополнительная система хранения 2: общая папка компонента запросов 2 (размер не менее 300 ГБ), используется для активного компонента раздела индекса 2.

Примечание

На этом сервере приложений с одним активным компонентом запросов потребуется как минимум 71,68 ГБ * 0,33 = 23,65 ГБ ОЗУ + 3 ГБ ОЗУ для операционной системы (фактически используется 32 ГБ) для кэширования большинства запросов.

Ограничения программного обеспечения

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

Объект	Ограничение	Дополнительные примечания
Приложение-служба поиска SharePoint	Рекомендуется не более 20 на ферму. Абсолютное ограничение составляет 256 приложений-служб.	В одной ферме можно развертывать несколько приложений-служб поиска SharePoint, поскольку компоненты и базы данных поиска можно назначать разным серверам.
Индексируемые документы	Общее рекомендуемое ограничение составляет 10 миллионов элементов на каждый раздел индекса и 100 миллионов элементов на каждое приложение-службу поиска.	Служба поиска SharePoint поддерживает разделы индекса, каждый из которых содержит подмножество индекса поиска. Рекомендуемый максимум составляет 10 миллионов элементов для каждого раздела. Рекомендуемый максимум для общего числа элементов (пользователи, элементы списка, документы, веб-страницы) составляет 100 миллионов.
Разделы индекса	Рекомендуется не более 20 на каждое приложение-службу поиска.	Раздел индекса содержит логическое подмножество индекса приложения-службы поиска. Рекомендуемое ограничение составляет 20. Увеличение числа разделов индекса ведет к уменьшению числа элементов в каждом разделе. Это, в свою очередь, повлечет сокращение объема ОЗУ и дискового пространства, выделяемого на сервере запросов, на котором размещается компонент запроса, назначенный разделу индекса. Тем не менее, это может привести к снижению релевантности из-за уменьшения числа элементов в разделе индекса. Максимальное ограничение числа разделов индекса — 128.
База данных свойств	Рекомендуется не более 10 на каждое приложение-службу поиска.	В базе данных свойств хранятся метаданные для элементов в каждом связанном разделе индекса. Раздел индекса может быть связан только с одним хранилищем свойств. Рекомендуемое ограничение составляет 10 баз данных свойств для каждого приложения-службы поиска. Максимальное ограничение составляет 255 (аналогично разделам индекса).
Базы данных обхода контента	Ограничение составляет 32 базы данных обхода контента на приложение.	В базе данных обхода контента хранятся данные обхода контента (время, состояние и т. д.) для всех элементов, для которых выполнен обход. Рекомендуемое ограничение составляет 25 миллионов элементов для одной базы данных обхода контента (всего четыре базы данных для одного приложения-службы поиска).
Компоненты обхода контента	Рекомендуемое ограничение для каждого приложения составляет 16 компонентов обхода контента (по два на каждую базу данных обхода и по два на каждый сервер с учетом того, что сервер должен иметь как минимум восемь процессоров или ядер).	Для минимального распространения ухудшений в производительности системы ввода-вывода общее число компонентов обхода контента для каждого сервера не должно превышать значения, вычисляемого по формуле 128/(общее число компонентов запроса). Превышение рекомендуемого ограничения не обязательно приведет к росту производительности обхода контента. В действительности, производительность обхода контента может уменьшиться в соответствии с наличием доступных ресурсов на сервере обхода контента и на узле, либо в базе данных.
Компоненты запроса	Рекомендуемое ограничение составляет 128 на каждое приложение, 64/(общее число компонентов обхода контента) для каждого сервера.	Общее число компонентов запроса ограничивается возможностями компонентов обхода контента по копированию файлов. Максимальное число компонентов запроса для каждого сервера ограничивается возможностями компонентов запроса по приему файлов, распространяемых из компонентов обхода контента.
Число параллельных обходов контента	Рекомендуется не более 20 на каждое приложение-службу поиска.	Число одновременно выполняемых обходов контента. Задачи обхода контента потребляют очень большой объем ресурсов, что может отрицательно сказаться на производительности базы данных и других приложений. Превышение этого ограничения может привести к снижению общей скорости обхода контента.
Источники контента	Рекомендуется не более 50 на каждое приложение-службу поиска.	Рекомендуемое ограничение в 50 источников может быть превышено вплоть до максимального ограничения, которое составляет 500 источников контента для каждого приложения-службы поиска. Тем не менее, при этом следует использовать меньшее число начальных адресов и соблюдать ограничение числа параллельных обходов контента.
Начальные адреса	Рекомендуется не более 100 начальных адресов на каждый источник контента.	Рекомендуемое ограничение может быть превышено вплоть до значения границы, которое составляет 500 начальных адресов для каждого источника контента. Тем не менее, рекомендуется использовать меньшее число источников контента. При наличии большого числа начальных адресов рекомендуется поместить их на HTML-страницу в виде ссылок и выполнить обход HTTP-контента страницы по этим ссылкам.
Правила обхода контента	Рекомендуется не более 100 на каждое приложение-службу поиска.	Это значение может быть превышено, однако это может привести к снижению производительности правил обхода контента в системе администрирования поиска.
Журналы обхода контента	Рекомендуется не более 100 миллионов на каждое приложение.	Задает число отдельных записей в журнале обхода контента. Определяется в соответствии с ограничением на число индексированных документов.
Число распознанных свойств метаданных на элемент	Максимальное ограничение составляет 10 000.	Число свойств метаданных, которые могут быть определены и потенциально сопоставлены или использованы для запросов при обходе контента элементов.
Свойства для обхода	500 000 для каждого приложения-службы поиска	Свойства, которые будут обнаруживаться в процессе обхода контента.
Управляемые свойства	100 000 для каждого приложения-службы поиска	Это свойства, используемые поисковой системой в запросах. Свойства для обхода сопоставляются с управляемыми свойствами. Рекомендуется использовать не более 100 сопоставлений для каждого управляемого свойства. Превышение этого ограничения может привести к снижению скорости обхода контента и эффективности запросов.
Области	Рекомендуемое ограничение составляет 200 для каждого сайта.	Это рекомендуемое ограничение для каждого сайта. Превышение этого ограничения может привести к снижению эффективности обхода контента и увеличению задержки в браузере конечного пользователя (в случае добавления областей в группу отображения). Также по мере превышения рекомендуемого ограничения на число областей снижается производительность при отображении областей в интерфейсе администрирования поиска.
Группы отображения	25 для каждого сайта	Группы отображения служат для отображения областей в группах через пользовательский интерфейс. Превышение установленного ограничения приведет к снижению эффективности областей в интерфейсе администрирования поиска.
Правила области	Рекомендуемое ограничение составляет 100 правил для каждой области; всего 600 правил для каждого приложения-службы поиска.	Превышение этого ограничения повлечет за собой уменьшение актуальности обхода контента и задержку возврата потенциальных результатов из запросов с заданной областью.
Ключевые слова	Рекомендуемое ограничение составляет 200 для каждого семейства сайтов.	Рекомендуемое ограничение может быть превышено вплоть до максимального ограничения в 5000 для каждого семейства сайтов (задается в ASP.NET) при использовании пяти наиболее подходящих элементов на ключевое слово. Если это ограничение превышено, производительность отображения ключевых слов в пользовательском интерфейсе администрирования сайта при превышении этого ограничения будет ухудшаться. Устанавливаемое в ASP.NET ограничение может быть изменено посредством изменения файлов Web.config и Client.config (MaxItemsInObjectGraph).
Достоверные страницы	Рекомендуемое ограничение — одна достоверная страница верхнего уровня и минимально необходимое для обеспечения релевантности число страниц второго и третьего уровня.	Максимальное ограничение составляет 200 на уровень релевантности для каждого приложения-службы поиска, однако добавление дополнительных страниц может привести к снижению релевантности. Добавьте ключевой сайт на первый уровень релевантности. При необходимости по одному добавляйте дополнительные ключевые сайты на второй или третий уровень релевантности и оценивайте релевантность после каждой операции добавления, чтобы гарантировать достижение нужной релевантности.
Оповещения	Рекомендуется не более 1 000 000 на каждое приложение-службу поиска.	Это проверенное ограничение.
Удаление результатов	100 URL-адресов за одну операцию	Это рекомендуемое максимальное количество URL-адресов, которое следует удалять из системы за одну операцию.

Оптимизация

В следующих разделах описываются способы повышения производительности фермы.

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

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

Оптимизация системы поисковых запросов

В общем случае оптимизация системы поисковых запросов требуется в следующих сценариях:

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

Горизонтальное и вертикальное масштабирование подсистемы запросов всегда предполагает создание дополнительных компонентов запросов. При наличии избыточных ресурсов (ОЗУ, подсистема ввода-вывода и ЦП) на существующем сервере запросов можно выполнить вертикальное масштабирование за счет создания на нем дополнительных компонентов. Это позволит повысить эффективность использования ОЗУ, ЦП или подсистемы ввода-вывода. В противном случае можно создать дополнительные компоненты (или перенести некоторые из существующих компонентов) на новом сервере (горизонтальное масштабирование).

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

Уменьшение задержки запросов

Добавление компонентов запросов для уменьшения задержки

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

Влияние нагрузки пользователя на задержку запроса (75 процентиль

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

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

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

Влияние нагрузки пользователя на задержку запроса (75 процентиль

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

Горизонтальное масштабирование для повышения пропускной способности запросов

Добавление компонентов запросов для повышения пропускной способности запросов

Влияние нагрузки пользователя на пропускную способность запроса с различным числом компонентов

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

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

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

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

Оптимизация системы обхода при поиске

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

При обходе начального адреса источника контента в соответствии с требованиями актуальности могут возникать следующие проблемы, связанные с производительностью:

Низкая скорость обхода из-за снижения производительности подсистемы ввода-вывода в подсистеме обхода при поиске.
Низкая скорость обхода из-за нехватки потоков ЦП в подсистеме обхода при поиске.
Низкая скорость обхода из-за высокой задержки отклика репозитория.

Во всех случаях проблемы связаны с низкой скоростью обхода контента. В разделе Use search administration reports (SharePoint Server 2010) (в рамках жизненного цикла программного обеспечения) приводятся рекомендации по определению базовой скорости обхода контента для системы. При ухудшении этого базового показателя необходимо устранить проблемы, связанные с производительностью, руководствуясь рекомендациями в следующих подразделах.

Снижение производительности подсистемы ввода-вывода

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

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

Топология (Компонент обхода контента/ база данных обхода контента)	Использование ЦП	ОЗУ: коэффициент попадания в кэш буфера %	Задержка чтения	Задержка записи	Скорость обхода контента (документов в секунду)
2 / 1 БД	19,5	99,6	142 мс	73 мс	50
4 / 2 БД	8,502	99,55	45 мс	75 мс	Около 75
6 / 2 БД	22	99,92	55 мс	1050 мс	Около 75

Снижение производительности из-за нехватки потоков ЦП

Если в среде присутствует большое число узлов и отсутствуют другие проблемы с производительностью обхода контента, необходимо масштабировать систему обхода контента с использованием нужного решения. Программа-обходчик поддерживает не более 256 потоков на одно приложение-службу поиска. Для полноценного использования преимуществ многопотоковой обработки рекомендуется наличие четырехъядерного процессора. Если точно определено, что скорость обработки данных в репозитории достаточно высока (см. раздел "Снижение производительности обхода контента из-за репозитория" этой статьи), можно повысить пропускную способность обхода за счет более быстрого запроса данных из репозитория (достигается путем увеличения числа потоков для программы-обходчика). Это можно реализовать одним из трех следующих способов:

Изменение уровня производительности индексатора на частично сокращенный или максимальный с помощью следующего командлета Windows PowerShell:
- Get-SPEnterpriseSearchService | Set-SPEnterpriseSearchService –PerformanceLevel "Maximum"
  
  Значение Maximum следует применять при использовании процессора с числом ядер меньше 4.
Использование правил воздействия обходчика для увеличения числа потоков на узел. Такой способ рекомендуется использовать, если поддерживается до 256 потоков, и назначение большого числа потоков меньшему числу узлов может привести к снижению скорости извлечения данных из других репозиториев.
При большом числе узлов оптимальным решением будет добавление дополнительного компонента обхода контента на отдельном индексаторе для более быстрого обхода контента на узлах, которые требуется индексировать.

Идеальным способом повысить пропускную способность обхода контента является добавление дополнительного индексатора (если в подсистеме поиска используется достаточно производительная подсистема ввода-вывода, и репозиторий обеспечивает быструю обработку контента).

Снижение производительности обхода контента из-за репозитория

В некоторых случаях, если веб-приложение SharePoint Web содержит большое число вложенных семейств сайтов или удаленных общих сетевых папок, для которых требуется выполнять обход контента, снижение производительности обхода при поиске может быть связано с репозиторием. Признаками такой ситуации является одновременной соблюдение следующих двух условий:

Низкий (менее 20%) уровень использования ЦП на серверах обхода контента.
Большое число ожидающих потоков в сети (в худших случаях практически все потоки).

Определить наличие такой ситуации можно по значению счетчика производительности "Средство сбора данных поиска OSS/Потоков, обращающихся к сети".

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

После определения проблемного узла необходимо выявить причины высокой задержки отклика. Дополнительные сведения относительно контента SharePoint см. в статье Capacity management and sizing for SharePoint Server 2010.

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

Устранение проблем производительности и масштабируемости

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

Показатели производительности на разных этапах жизненного цикла системы поиска

Показатель	Получение индекса	Обслуживание индекса	Очистка индекса
Использование ЦП SQL Server (в %) База данных свойств / база данных обхода контента	14,8 / 19,13	35 / 55	11 / 63
Ожидаемый срок жизни страницы SQL Server База данных свойств / база данных обхода контента	60 548 / 5913	83 366 / 5373	33 927 / 2806
Средняя длительность операции записи на диск (SQL Server) База данных свойств / база данных обхода контента	9 мс / 48 мс Максимум: 466 мс / 1277 мс	12 мс / 28 мс	20 мс / 49 мс Максимум: 253 мс / 1156 мс
Средняя длительность операции чтения с диска (SQL Server) База данных свойств / база данных обхода контента	8 мс / 43 мс Максимум: 1362 мс / 2688 мс	11 мс / 24 мс	24 мс / 29 мс Максимум: 2039 мс / 2142 мс
Использование ЦП программы-обходчика (в %) Сервер индекса 1 (2 компонента обхода контента) / сервер индекса 2 (2 компонента обхода контента)	18 / 11	25,76 / 21,62	8,34 / 7,49 Максимум до 99%
Обращений записи на диск/сек Сервер индекса 1 (2 компонента обхода контента) / сервер индекса 2 (2 компонента обхода контента)	64,32 / 42,35	93,31 / 92,45	99,81 / 110,98
Обращений чтения с диска/сек Сервер индекса 1 (2 компонента обхода контента) / сервер индекса 2 (2 компонента обхода контента)	0,23 / 0,20	4,92 / 2,03	1,38 / 1,97
Среднее время записи на диск Сервер индекса 1 (2 компонента обхода контента) / сервер индекса 2 (2 компонента обхода контента)	11 мс / 11 мс	1 мс / 2 мс	5 мс / 4 мс Максимум: 1962 мс / 3235 мс
Среднее время чтения с диска Сервер индекса 1 (2 компонента обхода контента) / сервер индекса 2 (2 компонента обхода контента)	1 мс / 2 мс	12 мс / 11 мс	10 мс / 16 мс Максимум: 2366 мс / 5206 мс

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

В системе поиска SharePoint реализованы инструментированный конвейер запросов и связанные с ним административные отчеты, которые можно использовать при устранении неполадок, связанных с эффективностью запросов на стороне сервера. Дополнительные сведения см. в разделе Use search administration reports (SharePoint Server 2010). В этом разделе описываются некоторые отчеты и демонстрируется их применение для устранения неполадок на стороне сервера. Кроме того, в этом разделе описываются средства и приводятся рекомендации по устранению неполадок на стороне клиента (в браузере).

Проблемы, связанные с эффективностью запросов на стороне сервера

Проблемы, связанные с эффективностью запросов на стороне сервера, можно подразделить на два уровня:

Проблемы на стороне интерфейсных серверов поиска
Проблемы на стороне внутренних серверов поиска

В следующих подразделах приводятся общие рекомендации по устранению неполадок каждого вида.

Проблемы на стороне интерфейсных серверов

В первую очередь при устранении неполадок такого рода необходимо ознакомиться с административным отчетом системы поиска "Общая задержка обработки запросов". Ниже приводится пример этого отчета:

Простой отчет о задержке запроса на поиск

В этом отчете показатели эффективности на стороне интерфейсных серверов представлены следующими рядами данных:

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

Устранение неполадок, связанных с визуализацией на сервере

Причинами проблем, связанных с визуализацией на сервере, могут быть любые неполадки на интерфейсном веб-сервере, который обслуживает страницу результатов поиска. В общем случае необходимо определить, сколько времени затрачивается на извлечение различных веб-частей, что позволяет выявить компоненты, в которых возникает дополнительная задержка. Для получения более подробных отчетов о задержке включите панель разработчика (Возможно, на английском языке) на странице результатов поиска. Ниже перечислены типовые проблемы, связанные с увеличением задержки при визуализации на сервере:

Проблемы, связанные с платформой, в том числе следующие:
- Низкая скорость поиска Active Directory
- Низкая скорость отклика SQL Server
- Низкая скорость обработки запросов к приложению профиля пользователя в пользовательских запросах в SharePoint Server 2010 или во всех запросах в FAST Search Server 2010 для SharePoint
- Низкая скорость обработки запросов на извлечение параметров пользователя
- Низкая скорость обработки вызовов для получения маркера пользователя из службы маркеров безопасности
Проблемы, связанные с кодом программной части, в том числе измененные страницы результатов поиска (например, results.aspx и peopleresults.aspx), которые были возвращены, но не были опубликованы.

Устранение неполадок, связанных с объектной моделью

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

Проблемы на уровне Windows Communication Foundation (WCF), в том числе:
- Истечение времени ожидания и исключения threadabortexception в вызовах WCF в развертывании.
- Низкая скорость взаимодействия между интерфейсным веб-сервером и сервером приложений. Это может быть связано с ошибками протокола IPsec или низкой скоростью подключения к сети.
Проблемы, связанные с взаимодействием между фермами контента и служебными фермами (если такие настроены).

Проблемы на стороне внутренних серверов

В первую очередь при устранении неполадок такого рода необходимо ознакомиться с административным отчетом системы поиска "Задержка обработки запросов к базе данных SharePoint". Ниже приводится пример этого отчета:

Простой отчет о задержке запроса на серверный поиск

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

Компонент запросов:
- Полнотекстовый запрос. Среднее время, затрачиваемое на запрос результатов из полнотекстового индекса.
База данных свойств:
- Получение нескольких результатов. Среднее время, затрачиваемое на извлечение метаданных документа (например, названия или автора), которые отображается в результатах запроса.
- Запрос хранилища свойств. Среднее время, затрачиваемое на обработку основанного на свойствах запроса к базе данных свойств.
База данных администрирования поиска:
- Наиболее подходящие элементы. Среднее время, затрачиваемое на проверку наличия доступных для запроса наиболее подходящих элементов.
- Наиболее достоверные результаты. Среднее время, затрачиваемое на извлечение наиболее достоверных результатов для запросов.
Обработчик запросов:
- Фильтрация по ролям безопасности. Среднее время, затрачиваемое на удаление элементов, к которым у пользователя отсутствует доступ.
- Удаление повторений. Среднее время, затрачиваемое на удаление повторений.
- Заполнение результатов. Среднее время, затрачиваемое на создание в памяти таблиц, которые возвращаются в объектную модель.

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

Компоненты запросов, особенно в активном состоянии (в процессе обработки запросов), потребляют большой объем ресурсов. Устранение неполадок, связанных с эффективностью компонентов запросов, является одно из самых сложных задач при работе с системой поиска. Ниже приводятся общие рекомендации, которые следует учитывать в этом случае:

Наиболее ресурсоемким событием компонентом запросов является объединение с главной копией, в ходе которого теневые индексы объединяются с главным. Это событие возникает независимо для каждого компонента. Пример влияния этого события можно просмотреть в отчете "Задержка обработки запросов к базе данных SharePoint" (см. ранее в этой статье) в районе отметки 13:30. Если это событие влияет на задержку обработки запросов, можно определить периоды блокировки, в которые операции объединения с главной копией будут отключаться, если процент изменений не превышает заданного ограничения.
Если в среде постоянно наблюдаются высокие значения, рекомендуется выполнить следующие действия:
- Проверьте размер индекса для каждого компонента на сервере. Убедитесь, что на сервере установлен объем ОЗУ, достаточных для хранения приблизительно 33% от совокупного размера индексов в кэше.
- Проверьте состояние канала ввода-вывода компонента запросов на сервере. Убедитесь в отсутствии узких мест, связанных с этим каналом.
- Если подсистема ввода-вывода и ОЗУ не являются причинами снижения производительности, следует выполнить разбиение индекса на разделы (добавить новые разделы индекса), а также горизонтальное масштабирование системы, добавив дополнительные компоненты запросов на новые серверы.

Устранение неполадок, связанных с базой данных свойств

Проверьте работоспособность SQL Server, основываясь на рекомендациях раздела Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010). Если выполняются настраиваемые запросы, возможно, потребуется ознакомиться с рекомендациями по разработке плана запросов.

Устранение неполадок, связанных с базой данных администрирования поиска

Устранение неполадок, связанных с обработчиком запросов

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

Фильтрация по ролям безопасности:
- Для утверждений Windows проверьте подключение Active Directory к серверу, на котором размещается обработчик запросов.
- Во всех случаях, если существует взаимосвязь с большим числом операций приема-передачи SQL Server (определяется в приложении SQL Server Profiler), можно увеличить размер кэша, используемого обработчиком запросов. Использовать вызовы SQL Server для извлечения дескрипторов безопасности из базы данных администрирования поиска должны не более 25% запросов. В противном случае следует увеличить размер кэша обработчика запросов.
Удаление повторений:
- Проверьте, не выполняется ли обход одного и того же контента в разных местах. Отключите функцию удаления повторений в центре поиска.
Получение нескольких результатов:
- Проверьте работоспособность SQL Server, основываясь на рекомендациях разделаПланирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010).

Проблемы, связанные с эффективностью запросов в браузере

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

Суммарное время загрузки страницы в пользовательском интерфейсе системы поиска не должно превышать 1 секунды. Из этого времени на стороне клиента (в зависимости от используемого браузера и способов измерения) затрачивается не более 280 миллисекунд. Если эти показатели соблюдаются, пользователи будут удовлетворены результатами.

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

Ниже приводятся общие рекомендации:

Наличие базовых фирменных настроек и дополнительных стилей не должно увеличивать время загрузки страницы более чем на 25 мс. Чтобы определить величину изменения, измерьте время загрузки до и после внедрения настроек.
Пользователи обычно замечают изменения (увеличение или уменьшение скорости) с шагом в 20%. Учитывайте это при внесении изменений. 20% от стандартного времени отображения составляет всего 50 мс. (Источник: статья, посвященная управлению временем при проектировании (Возможно, на английском языке))
Чаще всего основными источниками задержки становятся каскадные таблицы стилей и скрипты JScript. Чтобы свести к минимуму последствия их применения, рекомендуется не использовать более одного такого элемента в одном файле.
Скрипты JScript могут загружаться по запросу после отображения страницы пользователю, что позволяет максимально быстро предоставлять наглядные результаты. Более подробно этот вопрос рассматривается в статье, посвященной вопросам производительности.
Чем больше настроек добавлено на страницу, тем медленнее она загружается. В каждом случае следует тщательно взвесить, стоит ли расширение функциональных возможностей или новый стиль увеличения задержки при выводе результатов пользователям.

Кроме того, в Интернете можно найти дополнительные сведения о том, как сократить время загрузки страницы, а также о том, как медленная загрузка страницы влияет на эффективность пользовательского интерфейса.

Устранение неполадок, связанных с эффективностью обхода контента

В системе поиска SharePoint на этапах получения, обслуживания и удаления индекса могут возникать узкие места, связанные с подсистемой обхода контента. Для эффективного устранения неполадок, связанных с обходом контента, используйте отчеты мониторинга работоспособности поиска, а также рекомендации, приведенные в разделе "Распространенные узкие места и причины их возникновения" этой статьи.

Устранение неполадок на этапе получения индекса

Основным способом определения проблем, связанных с обходом контента, является отчет "Скорость обхода по источникам контента". Как показано далее в этой статье, в этом отчете приводится обзор скорости обхода для каждого источника контента в системе. В общем случае скорость обхода должна превышать 15 документов в секунду для источников пользовательского контента и 35 документов в секунду для остальных источников контента.

Простой отчет о скорости обхода при поиске

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

Приостановите все процессы обхода контента, за исключением проблемного источника. Определите, возросла ли скорость обхода до рекомендуемого значения в 15 (35) документов в секунду?
Если предыдущее действие не помогло, убедитесь, что репозиторий, для которого выполняется обход контента, отвечает в приемлемое время и не является причиной снижения скорости обхода контента. См. раздел "Снижение производительности обхода контента из-за репозитория этой статьи.
Если узкое место не связано с репозиторием, проверьте производительность сервера обхода контента или сервера баз данных и оптимизируйте их работу. Соответствующие рекомендации см. в разделах "Снижение производительности подсистемы ввода-вывода" и "Снижение производительности из-за нехватки потоков ЦП" этой статьи.

Устранение неполадок на этапе обслуживания индекса

Основная задача на этапе обслуживания индекса заключается в поддержании максимальной степени актуальности индекса. На данном этапе используется два ключевых индикатора:

Актуальность индекса. Заканчивается ли обход контента в установленное время и в соответствии с заданными ИТ-отделом ограничениями относительно актуальности индекса?
Скорость добавочного обхода. Если установленные показатели актуальности индекса не соблюдаются, определите скорость добавочного обхода (должна составлять 10 документов в секунду для источников пользовательского контента и 35 документов в секунду для остальных источников контента). Если скорость добавочного обхода ниже оптимальной, следует выполнить анализ узких мест для репозитория, включаемого в процесс обхода, и подсистемы обхода, как показано выше.

Распространенные узкие места и причины их возникновения

В ходе тестирования производительности было обнаружено несколько узких мест. Узкое место — это состояние, при котором достигается предельная емкость отдельного компонента фермы. Узкие места снижают пропускную способность фермы.

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

Узкое место	Признак (счетчик производительности)	Решение
ОЗУ базы данных	База данных свойств Характеристики базы данных администрирования поиска: Диспетчер буферов SQL Server/ожидаемый срок жизни страницы < 300 с (должно быть > 1000 с) Диспетчер буферов SQL Server/коэффициент попадания в кэш буфера < 96% (должно быть > 98%)	Увеличьте объем памяти сервера баз данных. Выполните дефрагментацию базы данных свойств, если отключено правило еженедельной дефрагментации. Убедитесь, что используется выпуск SQL Server 2008 Enterprise, поддерживающий сжатие страниц. Переместите базу данных на отдельный сервер (при необходимости добавьте несколько баз данных свойств).
Подсистема ввода-вывода сервера баз данных	Характеристики базы данных свойств или обхода контента: Среднее время чтения с диска и среднее время записи на диск ~50 мс или > 50 мс	Убедитесь, что на сервере баз данных выделен достаточный объем ОЗУ для хранения 33% от объема важных таблиц (MSSDocSDIDs + MSSDocProps + MSSDocresults) в кэше. Увеличьте зарезервированное число операций ввода-вывода для базы данных, выполнив следующие действия: Используйте разные массивы запоминающих устройств. Оптимизируйте конфигурацию хранилища. Например, добавив дополнительные шпиндели (жесткие диски) в массив запоминающих устройств. Запустите анализатор работоспособности системы поиска SharePoint — правило индексов одной или нескольких баз данных свойств фрагментировано (если отключено). Запустите анализатор работоспособности системы поиска SharePoint — правило индексов одной или нескольких баз данных обхода контента фрагментировано. Убедитесь, что используется выпуск SQL Server 2008 Enterprise, поддерживающий сжатие страниц. Переместите базу данных на отдельный сервер (при необходимости добавьте несколько баз данных свойств или обхода контента).
Подсистема ввода-вывода компонента запросов	Характеристики логического диска, используемого для хранения индекса компонента запросов: Среднее время чтения с диска и среднее время записи на диск в течение длительного времени составляет около 30 мс или > 30 мс (в течение большей части дня, а не только в процессе объединения индекса).	Убедитесь, что на каждом сервере приложений выделен достаточный объем для хранения 33% индекса каждого из активных компонентов (на этом сервере) в кэше (кэш операционной системы). Увеличьте зарезервированное число операций ввода-вывода для диска, который используется для хранения индекса компонента запросов, выполнив следующие действия: Используйте разные массивы запоминающих устройств для разных компонентов. Оптимизируйте конфигурацию хранилища. Например, добавив дополнительные шпиндели (жесткие диски) в массив запоминающих устройств.

ОЗУ базы данных

База данных свойств

Характеристики базы данных администрирования поиска:

Диспетчер буферов SQL Server/ожидаемый срок жизни страницы < 300 с (должно быть > 1000 с)

Диспетчер буферов SQL Server/коэффициент попадания в кэш буфера < 96% (должно быть > 98%)

Увеличьте объем памяти сервера баз данных.

Выполните дефрагментацию базы данных свойств, если отключено правило еженедельной дефрагментации.

Убедитесь, что используется выпуск SQL Server 2008 Enterprise, поддерживающий сжатие страниц.

Переместите базу данных на отдельный сервер (при необходимости добавьте несколько баз данных свойств).

Подсистема ввода-вывода сервера баз данных

Характеристики базы данных свойств или обхода контента:

Среднее время чтения с диска и среднее время записи на диск ~50 мс или > 50 мс

Убедитесь, что на сервере баз данных выделен достаточный объем ОЗУ для хранения 33% от объема важных таблиц (MSSDocSDIDs + MSSDocProps + MSSDocresults) в кэше.

Увеличьте зарезервированное число операций ввода-вывода для базы данных, выполнив следующие действия:

Используйте разные массивы запоминающих устройств.

Оптимизируйте конфигурацию хранилища. Например, добавив дополнительные шпиндели (жесткие диски) в массив запоминающих устройств.

Запустите анализатор работоспособности системы поиска SharePoint — правило индексов одной или нескольких баз данных свойств фрагментировано (если отключено).

Запустите анализатор работоспособности системы поиска SharePoint — правило индексов одной или нескольких баз данных обхода контента фрагментировано.

Убедитесь, что используется выпуск SQL Server 2008 Enterprise, поддерживающий сжатие страниц.

Переместите базу данных на отдельный сервер (при необходимости добавьте несколько баз данных свойств или обхода контента).

Подсистема ввода-вывода компонента запросов

Характеристики логического диска, используемого для хранения индекса компонента запросов:

Среднее время чтения с диска и среднее время записи на диск в течение длительного времени составляет около 30 мс или > 30 мс (в течение большей части дня, а не только в процессе объединения индекса).

Убедитесь, что на каждом сервере приложений выделен достаточный объем для хранения 33% индекса каждого из активных компонентов (на этом сервере) в кэше (кэш операционной системы).

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

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

Об авторе

Брайон Стоун (Brion Stone), ведущий руководитель программы системы поиска SharePoint Server в корпорации Майкрософт.

Share via

Оценка требований загрузки и производительности для системы поиска SharePoint Server 2010

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

Выбор сценария

Жизненный цикл поиска

Сценарии

Малая ферма

Спецификации

Топология

Аппаратное обеспечение

Веб-серверы

Серверы приложений

Серверы баз данных

Рабочая нагрузка

Набор данных

Данные о работоспособности и производительности

Данные по эффективности запросов

Данные по эффективности обхода контента

Данные тестов

Задержка запросов

Пропускная способность запросов

Скорость обхода контента

Выводы

Средняя ферма

Спецификации

Топология

Аппаратное обеспечение

Веб-сервер

Серверы приложений

Серверы баз данных

Рабочая нагрузка

Набор данных

Данные о работоспособности и производительности

Данные по эффективности запросов

Данные по эффективности обхода контента

Данные тестов

Задержка запросов

Пропускная способность запросов

Скорость обхода контента

Выводы

Крупная ферма

Спецификации

Топология

Аппаратное обеспечение

Веб-серверы

Серверы приложений

Серверы баз данных

Данные по эффективности запросов

Данные по эффективности обхода контента

Рекомендации и устранение неполадок

Рекомендации

Рекомендации к оборудованию

Масштабирование системы поиска

Система поисковых запросов

Описание объектов

Сведения о масштабировании

Система обхода при поиске

Описание объектов

Сведения о масштабировании

Расчет размера хранилища

1. Расчет коэффициента масштабирования базы данных контента (ContentDBSum)

2. Расчет размеров индекса (TotalIndexSize и QueryComponentIndexSize)

3. Расчет размеров баз данных свойств

4. Расчет размеров баз данных обхода контента

5. Расчет размера базы данных администрирования поиска

Необязательно. Расчет размера резервной копии

Пример расчета коэффициентов масштабирования

Ограничения программного обеспечения

Оптимизация

Оптимизация системы поисковых запросов

Уменьшение задержки запросов

Добавление компонентов запросов для уменьшения задержки

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

Горизонтальное масштабирование для повышения пропускной способности запросов

Добавление компонентов запросов для повышения пропускной способности запросов

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

Оптимизация системы обхода при поиске

Снижение производительности подсистемы ввода-вывода

Снижение производительности из-за нехватки потоков ЦП

Снижение производительности обхода контента из-за репозитория