Установление базовых показателей для перестроения индекса контента Exchange. Часть 3

  • Article

Дата публикации исходной статьи: понедельник, 2 июля 2012 г.

В первой части этой серии статей я описывал скрипт E2K7_IndexRebuildAnalyzer.ps1, а во второй части я говорил о платформе Search Rebuild Framework, разработанной моим коллегой Анатолием Гирко (Anatoly Girko) и мной. Прежде чем завершить эту серию, я бы хотел представить ряд графиков и таблицу с наблюдаемыми значениями, которые иллюстрируют характеристики перестроения, полученные нами с момента создания платформы. Я надеюсь, что это позволит вам лучше понять концепцию и сделать более точные оценки во время расчета собственных параметров перестроения...

Средние значения, полученные на настоящее время в Майкрософт

Мы с Анатолием долго решали, как лучше представить данные. Нетрудно догадаться, что представить данные можно бесконечным числом способов. Мы решили ограничить графики и таблицу размером сообщений, на который ориентируются большинство архитекторов хранилищ Exchange: 150 КБ на почтовый элемент . Затем мы применили второй фильтр к параметру Число почтовых ящиков и при вычислении приведенных ниже средних значений учитывали только те базы данных почтовых ящиков, которые содержали 100 или больше активных почтовых ящиков. После этого мы удалили из коллекции 10 % самых производительных и 10 % самых медленных операций перестроения, и для вычисления средних значений, представленных в графиках и таблицах, использовали только оставшиеся данные.

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

  • 1 700–1 799 МБ.
  • 1 800–1 899 МБ.
  • 2 000–2 099 МБ.
  • 2 100–2 199 МБ.

Графики

Мы представим четыре сводные диаграммы Excel, которые отражают характеристики пропускной способности, полученные к настоящему времени, на основе отфильтрованной коллекции, как описано выше. Эти сводные диаграммы предназначены для иллюстрации отношений, которые существуют между различными свойствами хранилищ почтовых ящиков (т. е. числом почтовых ящиков, числом элементов и размером EDB-файлов), а затем сравнения их с историческими данными о пропускной способности полного обхода в хранилищах почтовых ящиков со сходными характеристиками.

График 1

1

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

Этот график ясно дает понять, что по мере роста общего числа активных почтовых ящиков в базе данных Exchange параллельно будет расти и размер EDB-файла в файловой подсистеме хранилища. Это отношение в свою очередь влияет на общее время выполнения полного обхода индекса контента. Это просто замысловатая формулировка того, что большее количество активных почтовых ящиков обычно дает большее число почтовых элементов; большее число почтовых элементов дает больший размер EDB-файла на диске; больший размер EDB-файла на диске "обычно" требует большего времени на перестроение индекса контента. Единственный случай, когда эта гипотеза не работает, — это базы данных почтовых ящиков с большим объемом пустых фрагментов в файле. В этом случае общее время выполнения перестроения индекса контента будет заметно меньше, чем предполагается. Эта аномальная ситуация наблюдается в средах, которые мы обслуживаем, но такая статистика была удалена из нашей коллекции при помощи фильтрации, о которой говорилось выше.

График 2

2

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

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

График 3

3

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

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

График 4

4

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

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

Таблица с полученными средними значениями

Для создания таблицы мы использовали тот же отфильтрованный набор данных (описанный выше и представленный на графиках), но решили представить детализированные средние значения, упорядоченные по среднему размеру почтовых ящиков. Были созданы независимые строки по этому параметру с приращением в 99 мегабайт. Характеристика пропускной способности для каждой строки соответствует обобщенным средним значениям для всех баз данных со сходными размерами, для которых в нашей коллекции были выполнены операции перестроения. В частности, где средний размер сообщения был равен 150 КБ и средний размер почтового ящика для всех активных почтовых ящиков в этих базах данных находился в диапазонах, определенных в столбце A.

5

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

  • Первый способ, "исторические средние значения", можно реализовать на основе среднего размера почтовых ящиков , где средний размер сообщения для элементов, находящихся в этих почтовых ящиках, составляет 150 КБ.Так как у нас в коллекции содержится большой объем исторических данных по перестроениям, мы решили использовать этот вариант. Мы получаем нашу оценку, определяя значение среднего размера почтовых ящиков через метрики “перед перестроением” и сравнивая его с историческими средними значениями. Затем мы берем обобщенное среднее значение из столбца Rebuild: Seconds per/Mailbox(Скорость перестроения, секунд на почтовый ящик) и умножаем это значение на число почтовых ящиков в базе данных, требующей обхода, чтобы определить общее время, которое необходимо на выполнение обхода.
  • Второй способ, "среднее по организации", также основан на среднем размере сообщения , но не учитывает число элементов и средний размер почтовых ящиков в организации (это среднее по организации дано в строке Averages (Средние) в таблице выше).
  • Третий способ — объединенные средние значения исторических средних и средних по организации.

Например, если мне требуется перестроить индекс контента в базе данных, в которой пользователи имеют средний размер почтовых ящиков в диапазоне 500–599 МБ, а средний размер сообщения предполагается равным 150 КБ, то для 200 пользователей, содержащихся в базе данных, я могу вычислить оценку тремя возможными способами:

По таблице исторических средних значений :

200 почтовых ящиков * 63 секунд = 12 600 секунд в сумме. Это равно 210 минутам или примерно 3,5 часам на полный обход .

Среднее по организации :

200 почтовых ящиков * 108 секунд = 21 600 секунд в сумме. Это равно 360 минутам или примерно 6,0 часам на полный обход .

Объединенные средние значения (среднее от "исторических" + "по организации") :

3,5 + 6,0 = 9,5 часов

9,5 / 2 = 4,75 часов

Заключение

Общее время перестроения индекса контента будет всегда меняться, так как число почтовых ящиков и количество элементов в них не постоянно. Наиболее точные и надежные оценки перестроения индекса контента всегда основаны на исторических средних. Я хочу заметить, что когда я или мы принимаем решение о перестроении внутреннего индекса контента в Майкрософт, мы предпринимаем усилия, чтобы запланировать это на периоды "наименьшего влияния на пользователей". Однако наши реализации глобальны, поэтому невозможно полностью устранить влияние на работу пользователей. Самое большее, на что можно надеяться, — это минимизация влияния в рамках определенной физической территории. В наших коллекциях данных мы не учитывали задержки регулирования индексатора поиска. Все задержки регулирования перестроения индексатора поиска обрабатываются и анализируются в момент сбора данных и представляются в виде отдельных билетов, выданных операции. Используя методы фильтрации, описанные в статье, можно отделить получаемые значения от заниженных средних (то же касается и операций перестроения со "слишком большой пропускной способностью"), что сделает общие оценки существенно более точными.

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

Мы надеемся, что эта серия оказалось полезной и, возможно, вы узнали из нее что-то новое!

Успехов в работе!

Эрик Норберг (Eric Norberg)
Инженер по эксплуатации,
специализирующийся на Office 365

Это локализованная запись блога. Исходная статья находится по адресу Establishing Exchange Content Index Rebuild Baselines – Part 3