Решение проблем производительности SharePoint

Приступив к написанию этой статьи, я осознал, что не могу начать серию очерков по решению проблем производительности, не имея основательной базы. В этом случае вероятность понять, что идет не так в вашей среде, чрезвычайно мала. Я решил подойти к вопросу с другой стороны и сперва выяснить, какие формы большой и хорошо работающей фермы Microsoft SharePoint 2010 вообще бывают. Тема производительности очень широкая, когда речь идет о SharePoint 2010. Конечные пользователи часто говорят, что «сохранение этой формы занимает слишком много времени», «такое чувство, что файл загружается целую вечность» или мое любимое — «этот SharePoint такой медленный». Как и все специалисты по ИТ, мы редко узнаем подробности, когда пользователи начинают жаловаться на производительность. Обычно они ждут от нас мгновенного решения проблем, не рассказывая в деталях, что на самом деле идет не так.

Однако образование конечного пользователя SharePoint — другая тема. , о которой я упомянул выше.

Характеристики оборудования

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

В таблице 1 (источник — technet.microsoft.com/en-us/library/cc262485.aspx#section3) показаны минимальные требования Microsoft к аппаратному обеспечению веб-серверов и серверов приложений, которые установлены в ферме. Помните, что это минимальные рекомендации, поэтому и производительность вы получите минимальную. Если вы хотите оптимизировать производительность, этих показателей недостаточно.

Таблица 1. Минимальные требования для оборудования веб-серверов и серверов приложений в ферме

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

(Необходимо памяти) × (Число пулов приложений) × 1,5 = Предполагаемый объем памяти

Более подробную информацию о пулах приложений для SharePoint можно найти в статье Microsoft «SharePoint Server 2010 capacity management: Software boundaries and limits» на сайте technet.microsoft.com/en-us/library/cc262787.aspx.

Правильный выбор процессора прежде всего основывается на балансе вашей среды между виртуализацией и аппаратным обеспечением. Microsoft Hyper-V Server 2008 R2 поддерживает четыре ядра на гостевую виртуальную машину, а VMware vSphere Enterprise Plus — восемь ядер. Если вам нужно больше восьми ядер, придется работать с физическими серверами. Я верю в виртуализацию как в основное направление из-за более низкой общей стоимости владения при высокой доступности и наличии функции восстановления после аварий, которую она дает. Однако каждый вариант имеет свои преимущества. Какую бы дорогу вы ни выбрали, общее правило производительности заключается в том, чтобы поддерживать использование процессора менее 50% на сервер.

Объем жесткого диска явно занижен: 80 Гбайт никогда не будет достаточно. Каждый веб-сервер и сервер приложений имеет собственные серверы Microsoft User Location Server (ULS), IIS и журналы событий, копию 14 ветвей реестра и каталог WinSxS. Прибавьте к этому потребность в страничном файле, который вдвое больше объема оперативной памяти, и желание, чтобы ваш сервер не остановился из-за нехватки места на жестком диске. Я рекомендую как минимум 200 Гбайт на каждый сервер либо 400 Гбайт, если вы можете себе это позволить. Вместо разделения дисков на множественные разделы сохраняйте единый большой раздел С для управления увеличением объема занимаемой памяти.

Требования SQL Server

Если не обеспечить SQL Server достаточным количеством «лошадиных сил», вы «потонете быстрее, чем покинете порт». Процессор и оперативная память критичны для производительности SQL Server, но имейте в виду, что SQL Server может «съесть» столько оперативной памяти, сколько ему дать, вне зависимости от нагрузки. В большинстве случаев SQL Server занимает оперативную память и никогда не отдает ее назад. Нагрузка на процессор будет повышаться и снижаться время от времени; но, если у вас недостаточно ядер, на которые будет распределяться нагрузка, вы столкнетесь с нехваткой процессорной мощности и с плохой производительностью фермы SharePoint. В таблице 2 (источник technet.microsoft.com/enus/library/cc262485.aspx#section3; technet.microsoft.com/en-us/library/cc298801.aspx#section4) перечислены минимальные требования Microsoft к аппаратному обеспечению для размещения SQL Server в ферме.

Таблица 2. Минимальные требования к оборудованию для SQL Server в ферме

Когда вы будете определять требования для SQL Server, подумайте о том, какие службы вы можете разделить. Минимальный набор требований ориентирован на систему управления базой данных (RDBMS) и не принимает во внимание никакие службы, SQL Server Integration Services (SSIS), Reporting Services (SSRS) или Analysis Services (SSAS), которые могут у вас быть. Отделите эти службы на собственную аппаратную базу, где это возможно, и учитывайте их специфические минимальные требования.

Напомню, что минимальные требования к аппаратному обеспечению, о которых я говорил выше, не являются достаточными при построении реальной фермы. Определите свои требования к высокой доступности и восстановлению после аварий и сравните их в зеркалировании против кластеризации, прежде чем покупать оборудование. Когда вы закончите анализ и будете готовы совершить покупку, приобретите столько железа, сколько может позволить ваш бюджет. Информацию о производительности кластеров SQL Server вы найдете в статье Microsoft «Optimizing Failover Cluster Performance» по адресу msdn.microsoft.com/en-us/library/ms190266.aspx. Сведения о производительности при зеркалировании SQL Server можно найти в статье Microsoft «Database Mirroring Best Practices and Performance Considerations» на сайте technet.microsoft.com/en-us/library/cc917681.aspx.)

По собственному опыту могу сказать, что предложенный подход оправдывал себя всегда. Каждый раз я обновлял оборудование (обычно через три-четыре года) или покупал новый SQL Server, чтобы заменить существующую систему, и ни разу не сказал: «Ого, а этот сервер мощнее, чем я запланировал для своих задач!» Мой обычный комментарий был таким: «Это удивительно, как мы додумались взять такой слабый блок!»

Производительность SQL Server

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

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

Одной из самых непроизводительных операций SQL Server является операция увеличения размера базы данных. SQL Server приостанавливает работу, ищет доступное пространство на диске и добавляет его к базе данных. По умолчанию эта операция установлена на прирост по 1 Мбайт за одну операцию. Когда создается база данных контента, у нее есть 20 Мбайт для файловых данных и 3 Мбайт для файла журнала. Создание пустого сайта захватывает еще 1 Мбайт свободного пространства — и база данных вынуждена увеличиваться. Загрузка двух файлов PDF (каждый до 3 Мбайт) вызывает рост файловых данных до общего объема в 28 Мбайт и делает объем файла журнала равным 5 Мбайт. Создание пустого сайта с библиотекой документов и двумя загруженными файлами PDF дают 11 операций наращивания объема. Представьте себе, как много операций роста в день будет происходить на производственном сервере с сотнями одновременно работающих пользователей.

Общее правило, которым я руководствуюсь при определении стартового размера базы данных контента, — получить оценку бизнес-аналитика (или оценить общий объем ваших данных). Если вы думаете, что вам потребуется 20 Гбайт, нарастите вашу базу данных до 40 Гбайт, чтобы обеспечить смежное пространство. Диски Fibre Channel и Serial ATA (SATA) сейчас относительно недорогие, если только вы не используете твердотельные накопители (которые я обычно не применяю для баз данных), вы можете получить множество дисков с высокой производительностью по достаточно низкой цене. Оставайтесь ниже рекомендованного размера в 200 Гбайт, где это возможно.

Убедитесь, что вы изменили настройку автоматического роста с 1 Мбайт до какого-либо разумного значения. Я устанавливаю эту настройку с 500 Мбайт до 1 Гбайт в зависимости от важности и назначения базы данных контента. Почему бы не установить переменное значение автоматического роста, если продукт позволяет это сделать? Ответ состоит в большом количестве баз данных. Если у вас есть база данных объемом 1 Tбайт и вы установите автоматический рост на 10%, при увеличении базы данных размером 500 Гбайт пользователь будет вынужден долго ждать, когда это произойдет. Если вы установите увеличение на 500 Мбайт, это не будет причинять пользователям неудобство.

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

• установите стандартное значение автоматического увеличения в пределах от 500 Мбайт до 1 Гбайт;
• создайте ежедневную операцию технического обслуживания, которая будет проверять количество свободного места в вашей базе данных;
• если количество свободного места менее 10%, тогда нарастите свободное пространство в запланированное время, когда этот процесс не будет влиять на работу пользователей.

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

Таблица 3. Результаты листинга, показывающие настройки базы данных

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

Как правило, файлы журналов SQL Server характеризуются высокой интенсивностью операций записи, тогда как файлы данных могут представлять собой смесь операций чтения и записи. Основываясь на общих базах данных, которые использует SharePoint (которые отличаются от TempDB, нацеленной на запись), можно сказать, что они по своей природе нацелены на чтение/запись. Вы можете задать архивные базы данных контента, которые вмещают коллекции сайтов только для чтения, но настоящая польза от SharePoint заключается в его функциях совместной работы, которые, по существу, нуждаются как в чтении, так и в записи элементов.

Почему это так важно понимать? Хранилище базы данных требует избыточности, а сутью данного метода является технология RAID. На производительность ваших баз данных может влиять уровень RAID, используемый в хранилище, в котором размещаются базы данных. Два наиболее часто используемых уровня RAID для хранилища базы данных — RAID 5 и RAID 10.

Разница в производительности между RAID 5 и RAID 10 состоит в операциях записи. В RAID 5 данные записываются на каждый диск для каждого блока данных, тогда как в RAID 10 данные записываются только один раз (есть фоновый процесс записи на зеркальный диск, но он не влияет на производительность, воспринимаемую пользователем). Феномен RAID 5 обычно относят к издержкам технологии RAID в силу увеличенного количества операций записи. В результате предполагается, что файлы журналов, TempDB и любые базы данных, которые, как вы думаете, будут характеризоваться большим объемом операций записи, «живут» на RAID 10. В таблице 4 дана карта рекомендаций.

Таблица 4. Рекомендуемые настройки RAID и оптимизации

Трудное решение относительно ввода-вывода — это соотношение затрат и отдачи. RAID 10 является чрезвычайно неэффективной и затратной памятью, но предоставляет самые лучшие избыточность и производительность. RAID 5 — эффективная дисковая память и предоставляет избыточность, но у вас будут проблемы с производительностью. Самым лучшим решением в данном случае будет выбрать то, что подходит конкретно вашей компании и дает правильный баланс. Если бюджет вашего отдела составляет 100 тыс. долл. в год, вы не сможете позволить себе SAN с достаточным объемом хранилища для того, чтобы поместить все базы на RAID 10 и внедрить твердотельные диски уровня предприятия. Сделайте все, что можете, в пределах бюджета (или постарайтесь его увеличить).

Тестирование нагрузки на веб-сервер SharePoint

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

• Microsoft Load Testing Kit (LTK) для SharePoint Foundation 2010 на сайте technet.microsoft.com/en-us/library/ff823731.aspx;
• Microsoft Web Capacity Analysis Tool (WCat) на сайте www.iis.net/community/default.aspx?tabid=34&g=6&i=1466;
• HP LoadRunner на сайте www8.hp.com/us/en/software/softwareproduct.html?compURI=tcm:245-935779.

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

• два веб-сервера SharePoint (4 ядра, 16 Гбайт оперативной памяти), используют балансировку нагрузки;
• один сервер приложений SharePoint (4 ядра, 16 Гбайт оперативной памяти);
• один экземпляр SQL Server (16 ядер, 128 Гбайт оперативной памяти).

Во время выполнения таких простых операций как Create, Read, Update и Delete в стандартном списке SharePoint система полностью перестает отвечать при 500 одновременно работающих пользователях. Во время теста пользователь регистрируется, создает элемент списка, добавляет к нему текст, удаляет элемент и завершает работу. Наблюдая за тестом на стороне сервера, мы обнаружили, что мгновенно получили предельную загрузку процессора.

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

Балансировка нагрузки в слое приложений SharePoint. В SharePoint 2010 специалисты Microsoft реализовали простую хорошую функцию под названием Service Application Load Balancer. Эта функция обслуживает циклические запросы ко всем прослушивающим служебным приложениям, которые отвечают на данный запрос. Таким образом, если пользователь вызывает веб-приложение A и делает запрос к службе Microsoft Excel Services и у вас есть три сервера приложений, которые прослушивают запросы к веб-приложению A, то SharePoint передает запрос на следующий по очереди сервер приложений для получения ответа. Какую же операцию должны осуществить вы, измученный администратор, для того чтобы совершить эту магию? Никакую. Просто добавьте службу Service Application Load Balancer и разрешите ей выполнить свою работу.

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

Причин много

Любое количество факторов может сделать свой вклад в производительность SharePoint, отражающуюся на пользователях. В некоторых случаях эти факторы абсолютно неконтролируемы и не имеют ничего общего с SharePoint. Не нужно даже упоминать о том, что пользователи обычно не думают о размере выполняемых ими операций. Пользователь, у которого возникли проблемы с загрузкой файла, не будет сообщать вам о том, что размер файла составляет 220 Мбайт или что он связывается с сервером, используя медленное соединение SSL VPN в отеле. Но во многих случаях проблем с SharePoint можно избежать, тщательно оценив и настроив ваше оборудование и поддерживающие приложения, прежде чем пользователи начнут работу с SharePoint.

Наряду с решениями для производительности, которые я рассмотрел в этой статье, есть и другие простые инструменты и функции, которые могут помочь в решении проблем SharePoint. Дополнительная информация по этому вопросу приведена во врезке «Набор инструментов для диагностики».

CREATE TABLE #GrowthTable
(
   Type_Desc varchar(50),
   Name varchar(500),
   Physical_Name varchar(max),
   State_Desc varchar(50),
   Size varchar(500),
   Max_Size varchar(500),
   Growth varchar(50),
   Is_Percent_Growth varchar(50));

exec sp_msforeachdb ‘use [?]; insert into #GrowthTable select Type_Desc, Name,
   Physical_Name, State_Desc,Size,Max_Size,Growth,Is_Percent_Growth from sys
   .database_files’

select * from #GrowthTable

drop table #GrowthTable

Джейсон Химмелстейн (jhimmelstein@sentri.com) — директор по SharePoint в компании Sentri (www.sentri.com), имеет звания MCTS и MCITP