Оптимизация производительности служб Reporting Services

Авторы: Дэнни Ли (Denny Lee), Лукаш Павловски (Lukasz Pawlowski)

Соавторы: Роберт Брюкнер (Robert Bruckner), Джеймс Ву (James Wu), Джон Галлардо (John Gallardo), Дин Кэланквин (Dean Kalanquin)

Введение

Эта техническая статья входит в серию технических статей по построению и развертыванию крупномасштабных сред служб SQL Server Reporting Services, содержащую общие рекомендации по настройке, реализации и оптимизации горизонтально масштабируемых архитектур служб Reporting Services корпоративного масштаба. В этой статье приводятся рекомендации по использованию служб Reporting Services как в Microsoft® SQL Server® 2005, так и в SQL Server 2008. Основное внимание в статье уделяется оптимизации архитектуры служб Reporting Services для повышения производительности, увеличения пропускной способности при формировании отчетов и ускорения обработки пользовательских нагрузок.

Архитектура

Рис. 1 иллюстрирует типичное горизонтальное масштабирование  среды Reporting Services. Красный прямоугольник указывает, что в этой технической статье основное внимание уделяется Оптимизации производительности существующего масштабного развертывания.

Рис. 1.. Архитектура горизонтального масштабирования  развертывания служб Reporting Services

 

Следует ли использовать 64-разрядную архитектуру?

Да.

Но почему именно? Ответ состоит из двух частей: в первой описывается, как 64-разрядные вычисления повышают производительность каталога сервера отчетов, а во второй описывается повышение производительности самого сервера отчетов.

Как 64-разрядные вычисления повышают производительность каталога сервера отчетов

Не забывайте, что каталоги сервера отчетов являются базами данных SQL Server, поэтому к ним применимы стандартные методики оптимизации баз данных SQL Server, которые описаны в технической статье Советы и рекомендации по использованию сервера отчетов. Начиная с SQL Server 2005, базы данных разрабатывались в расчете на 64-разрядные вычисления и могут задействовать дополнительную адресуемую память.

Как 64-разрядные вычисления улучшают работу службы сервера отчетов

Для серверов отчетов ответ будет несколько более сложным. В общем случае большинство отчетов служб Reporting Services интенсивно используют память, поэтому дополнительное адресное пространство, доступное  при использовании 64-разрядных  версий, расширяет возможности масштабирования. Обратите внимание, что некоторые рабочие нагрузки могут выполняться быстрее при использовании 32-разрядных вычислений, особенно в ситуации, когда имеется много небольших отчетов. Но благодаря доступу к большему объему памяти в 64-битной версии, можно будет работать с большим количеством пользователей отчетов одновременно. Так как процессы в этом случае меньше конфликтуют за память, пропускная способность обработки возрастет, то есть можно будет позволить просматривать и экспортировать отчеты большего размера большему количеству пользователей. В службах SQL Server 2005 Reporting Services набор данных каждого отчета помещался в память, соответственно, чем больше отчетов выполнялось одновременно, тем больше использовалось памяти. При использовании 32-разрядных вычислений в этом случае можно легко достичь предела выделяемой памяти, равного 3 ГБ. В этом случае может произойти перезапуск процесса IIS, вызывающий сбой отчета.

В то же время, как описано в технической статье Советы и рекомендации по масштабному развертыванию служб Reporting Services, службы SQL Server 2008 Reporting Services не настолько зависят от доступной памяти. Они могут эффективно использовать файловую систему для выгрузки и загрузки структур данных в случае, если доступный серверу отчетов объем памяти недостаточен. Предельные значения объемов памяти в службах Reporting Services в SQL Server 2008 можно задать в файле RSReportServer.config, как описано  ниже в разделе Настройка памяти для служб SQL Server 2008 Reporting Services. Когда службы Reporting Services задействуют файловую систему, отчеты выполняются медленнее, поскольку выборка данных из памяти намного более эффективна, чем доступ к диску. Файловая система начинает использоваться только тогда, когда используемый службами Reporting Services объем памяти приближается к установленным предельным значениям. Если сервер отчетов в службах SQL Server 2008 Reporting Services будет перегружен большим количеством одновременно обращающихся пользователей или очень больших отчетов, все отчеты все же будут выполнены, хотя это займет больше времени, поскольку службы Reporting Services смогут обработать данные, не превышая доступный объем пространства памяти. В корпоративной среде рано или поздно может возникнуть ситуация, когда серверам придется одновременно обслуживать многих пользователей и значительные нагрузки — и службы SQL Server 2008 Reporting Services (в отличие от SQL Server 2005 Reporting Services) оптимизированы таким образом, что, хотя отчеты иногда могут формироваться дольше, они гарантированно будут сформированы.

Исключения

Не забывайте, что не все поставщики данных доступны в 64-разрядном варианте (например, недоступен поставщик Microsoft JET и некоторые поставщики сторонних производителей). В таких случаях пользователю  придется продолжить использование 32-разрядных вычислений в среде служб Reporting Services.

 

Обработка большой рабочей нагрузки

Как отмечалось в предыдущем разделе, два основных требования к корпоративной среде создания отчетов — это возможность обработки одновременной нагрузки от одновременно работающих пользователей и возможность обработки большой рабочей нагрузки (т. е. больших отчетов). Чтобы решить проблему параллельного обслуживания пользователей, можно масштабировать среду на несколько серверов отчетов и распределить между ними создаваемую запросами пользователей нагрузку, как описано в технической статье  Советы и рекомендации по масштабному развертыванию служб Reporting Services .

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

Управляйте размером отчетов

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

Частой проблемой, связанной с большими отчетами, является наличие в них неиспользуемых полей данных или дублирующихся наборов данных. Нередко пользователи извлекают больше данных, чем им в действительности требуется. Чтобы значительно уменьшить нагрузку на среду служб Reporting Services, создавайте сводные отчеты, переносящие статистические вычисления в источники данных, и включайте в отчеты только действительно необходимые столбцы. Если необходимо предоставить доступ к потокам данных, их можно реализовать асинхронно с помощью более подходящих средств, например служб SQL Server Integration Services, реализующих файловые потоки данных.

Используйте выполнение в кэше

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

Настраивайте и планируйте выполнение отчетов

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

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

Доставляйте готовые к просмотру отчеты не в форматах обозревателя

В службах SQL Server 2008 Reporting Services повышена производительность подготовки отчетов к просмотру в форматах не для обозревателей, например в форматах PDF и XLS, как описано в технической статье Масштабирование служб Reporting Services 2008 по сравнению с Reporting Services 2005: полученные уроки. В любом случае для уменьшения нагрузки на среду служб SQL Server Reporting Services можно помещать отчеты в форматах не для обозревателей в общую папку или размещать их в командных службах SharePoint®, чтобы пользователи могли работать непосредственно с файлом без постоянного повторного создания отчета.

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

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

Возвращаясь к каталогам отчетов

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

Настройка веб-службы

С помощью настройки IIS и Http.sys можно достичь дополнительного повышения производительности компьютера, на котором размещен сервер отчетов. Параметры нижних уровней позволяют изменять длину очереди HTTP-запросов, длительность поддержания соединений в активном состоянии и т. п. В случае одновременного выполнения больших нагрузок отчетов может потребоваться изменение этих параметров, чтобы компьютер с сервером мог одновременно принимать достаточное количество запросов для использования в полной мере ресурсов сервера.

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

·        Для служб SQL Server 2005 Reporting Services выполните настройку IIS.

• Для служб SQL Server 2008 Reporting Services выполните настройку драйвера Http.sys в операционной системе: в Windows® 2003 или в Windows 2008.

 

Наблюдение с помощью представления ExecutionLog2

Начать анализ существующих рабочих нагрузок и исследование размера наборов данных, производительности и характеристик сложности этих нагрузок можно с представления ExecutionLog2 в службах Reporting Services. Дополнительные сведения см. в блоге Роберта Брюкнера, в котором содержатся исчерпывающие сведения о представлении ExecutionLog2 (http://blogs.msdn.com/robertbruckner/archive/2009/01/05/executionlog2-view.aspx). Дополнительные сведения о запросах и отчетах по данным журнала выполнения отчетов см. в электронной документации по SQL Server (http://msdn.microsoft.com/ru-ru/library/ms155836.aspx).

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

Ниже даны советы по просмотру представления ExecutionLog2 и быстрому обнаружению потенциальных «узких мест», ограничивающих производительность. Эта ссылка  указывает на проект Просмотр журналов выполнения служб Reporting Services. Проект создает сводные и подробные отчеты Reporting Services по 1000 последних записей в представлении ExecutionLog2 с указанными ниже параметрами сортировки.

Рис. 2. Сводный отчет просмотра журналов выполнения (ExecutionLog2)

Рис. 3. Подробный отчет просмотра журналов выполнения (ExecutionLog2)

Длительное выполнение?

Сортировка по полям ElapsedSec или RowCount  поможет выделить долго выполняющиеся отчеты. Если значение в поле TimeDataRetrieval велико, то «узким местом», ограничивающим производительность, является источник данных. Возможно, следует провести оптимизацию. Если велико значение RowCount, то службы Reporting Services извлекают и выполняют статистическую обработку большого объема данных — возможно, следует вынести эти операции в источник данных, чтобы сократить нагрузку на сервер отчетов.

Подписки или интерактивные отчеты?

Сортировка по полю RequestType позволяет определить, много ли выполняется подписок. Затем можно выделить «узкие места» и запланировать последовательное выполнение отчетов (то есть разнести плановое время выполнения подписок).

Данные, передаваемые в режиме реального времени, или моментальные снимки?

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

Сбалансирована ли нагрузка?

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

Определите связанные с отчетами закономерности

Сортировка по полям ReportPath и TimeStart может помочь при обнаружении интересных закономерностей выполнения отчетов. Например, может выясниться, что каждые 10 минут запускается ресурсоемкий отчет, выполнение которого занимает 5 минут.

Исправность отчетов

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

Кроме того, если значение ScalabilityTime больше нуля, то службы Reporting Services работают в режиме масштабирования, то есть при остром дефиците памяти, и выгружают долго выполняющиеся отчеты в файловую систему, чтобы освободить достаточно памяти для выполнения запросов меньшего объема. Если это происходит часто, рассмотрите возможность выполнения одного из следующих действий.

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

 

Управляемые данными подписки

Используя все приведенные сведения, можно создавать собственные управляемые данными подписки, которые будут сортировать, фильтровать и отслеживать возникающие проблемы. Например, можно создать подписку, которая будет отправлять предупреждение, если доля ошибок (поле Errors) превысит 5 %.

 

Настройка памяти для служб SQL Server 2008 Reporting Services

Как упоминалось выше в разделе о 64-разрядных вычислениях, в службах SQL Server 2008 Reporting Services память на уровне структуры данных используется более эффективно. При высокой интенсивности рабочих нагрузок службы задействуют кэш в файловой системе, чтобы сократить используемый объем памяти. За счет повышения эффективности и возможности выгрузки на диск службы могут успешно выполнять большее количество отчетов (даже отчетов большого размера). Администратор задает параметры, определяющие, когда службы SQL Server 2008 Reporting Services начинают использовать кэш в файловой системе и насколько интенсивно используется этот кэш. Администратору рекомендуется рассмотреть возможность настройки параметров памяти в службах SQL Server 2008 Reporting Services для оптимального использования ресурсов компьютеров. Тонкая настройка этих параметров может обеспечить рост производительности при интенсивных рабочих нагрузках (по сравнению с конфигурацией по умолчанию).

Дополнительные сведения см. в электронной документации по SQL Server 2008 в разделе Настройка доступной памяти для приложений сервера отчетов. Ниже перечислены основные параметры управления памятью.

• WorkingSetMinimum. Это минимальный объем памяти, выделяемый службами Reporting Services для функционирования (то есть, если используемый процессом служб SQL Server Reporting Services объем памяти ниже этого предела, кэш в файловой системе не используется). Он указывается в килобайтах в файле RSReportServer.config. По достижении этого предела службы Reporting Services начинают компенсировать нехватку памяти, перемещая долго выполняющиеся запросы в кэш в файловой системе и освобождая память для выполнения запросов меньшего объема.

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

 

• WorkingSetMaximum. Это максимальный объем физической памяти, используемой службами Reporting Services. Он также задается в килобайтах в файле RSReportServer.config. Если это предельное значение превышается в течение определенного периода времени, службы Reporting Services очищают домены приложений, чтобы сократить использование памяти. Таким образом обеспечивается наличие достаточного объема свободной памяти для нормальной работы операционной системы. Это значение можно увеличить, если необходимо одновременно обрабатывать большее количество отчетов.

 

• MemorySafetyMargin и MemoryThreshold. Эти значения определяют интенсивность использования кэша в файловой системе. MemorySafetyMargin. Задает значение, разделяющее уровни низкой и средней нагрузки. По умолчанию этот параметр равен 80 %. MemoryThreshold. Задает границу между уровнями средней и высокой нагрузки. По умолчанию этот параметр равен 90 %. Оба параметра задаются в файле RSReportServer.config.

Обычно при постоянном достижении предельных уровней памяти рекомендуется рассмотреть возможность увеличения доступных ресурсов (добавления памяти, изменения этих значений конфигурации), а в дальнейшем — и масштабирования (добавления серверов). Сначала следует увеличить доступные ресурсы на существующем компьютере, так как в службах SQL Server 2008 Reporting Services ресурсы используются и управляются более эффективно (см. техническую статью Масштабирование служб Reporting Services 2008 по сравнению с Reporting Services 2005: полученные уроки.

 

Настройка памяти для служб SQL Server 2005 Reporting Services

Как отмечено в технической статье Архитектура масштабного развертывания служб Reporting Services, в этом случае также возможно масштабирование путем добавления дополнительной памяти. Но результат этого может быть не таким существенным: в некоторых ситуациях удваивание объема памяти и количество ЦП (до 16 ГБ ОЗУ и до 8 ядер ЦП) может увеличивать производительность на 1/3. Тем не менее существуют способы, которыми можно увеличить производительность служб SQL Server 2005 Reporting Services до масштабирования путем добавления дополнительных серверов.

Как и в службах SQL Server 2008 Reporting Services, можно с помощью параметров конфигурации памяти решить проблемы, связанные с пороговыми значениями уровней доступной памяти. В службах SQL Server 2005 Reporting Services имеется две основных настройки памяти, которые рекомендуется изменять в случае постоянного достижения пороговых значений памяти.

• MemoryLimit. Этот параметр аналогичен параметру WorkingSetMinimum в SQL Server 2008. По умолчанию его значение соответствует 60 % от объема физической памяти. При увеличении данного параметра службы Reporting Services смогут обрабатывать большее количество запросов. По достижении задаваемого этим параметром предельного уровня новые запросы не принимаются.
• MaximumMemoryLimit. Этот параметр аналогичен параметру WorkingSetMaximum в SQL Server 2008. По умолчанию его значение соответствует 80 % от объема физической памяти. Однако в отличие от версии для SQL Server 2008 при достижении этого параметра начинается прерывание выполнения процессов, а не отказ в приеме новых запросов.

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

Заключение

Эта статья завершает состоящую из четырех технических статей серию «Построение и развертывание крупномасштабных сред для служб SQL Server Reporting Services». Надеемся, что эта серия технических статей поможет вам при проектировании, управлении и поддержке корпоративной среды служб SQL Server Reporting Services.