Невозможно отследить проблему производительности обработки отчетов

Question

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

У нас есть отчет, который иногда очень быстро возвращается, а иногда вообще не возвращается. Когда возникает проблема, отчет будет обрабатываться в течение 15 минут или около того, а затем в браузере отобразится ошибка «Не удается отобразить веб-страницу». Эта проблема носит эпизодический характер и обычно длится несколько дней, затем мы получаем несколько дней очень быстрой обработки, а затем возвращаемся к медленной. Когда отчет работает нормально, мы можем вернуть более 14 000 записей за 10 секунд.

Наша команда обработки данных сообщила, что на серверах SQL ничего не происходило, когда мы видим переход от медленного к быстрому. Нет перестроений индекса, пересчётов статистики и т. Д.

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

В отчете довольно много параметров. Я видел сообщения, касающиеся «анализа параметров», поэтому я создал версию отчета без параметров и все еще получаю те же результаты.

В этом отчете нет ничего сложного. Это стол. На уровне отчета не выполняется группировка или фильтрация. Подотчетов нет. В отчете используется интерактивная сортировка.

Отчет может возвращать более 14 тыс. Записей. Общий объем данных для этого составляет около 2 МБ. Но, как я уже говорил ранее, в некоторые дни отчет работает нормально и через несколько секунд вернет даже максимальное количество записей.

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

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

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

Кто-нибудь знает, почему работа может находиться в таблице RunningJobs? Мы должны увидеть что-то в файлах журнала сервера отчетов, если эти задания выполняются, верно? Есть ли что-то еще, что мы должны тестировать?

Наш сервер отчетов имеет версию 9.00.3050.00. Мы осуществляем доступ через веб-элемент управления Report Viewer.

Answer 1

Вы пытались профилировать запрос с помощью профилировщика SQL Server? Используя это, вы можете определить, завершился ли запрос в SQL Server, и проблема заключается в создании отчета или запрос фактически не завершается.

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

Answer 2

Возможно, попробуйте меньший набор данных, чтобы посмотреть, не изменит ли это его.

Какой-либо спайк ЦП на любом сервере?

Соответствует ли время выполнения отчета тому, что вы испытываете? Таблица ExecutionLog в ReportServer должна показать это.

Звучит очень раздражающе - я сочувствую, хотелось бы, чтобы у меня были лучшие идеи.

Answer 3

Убедитесь, что в отчете отсутствуют изображения с внешними ссылками. Если вы это сделаете, вполне возможно, что вашим изображениям может потребоваться много времени, чтобы быть хост-сервером изображений. У меня была очень похожая ситуация, когда сервер отчетов потерял исходящий доступ к Интернету, поэтому сервер отчетов не смог получить внешнее изображение во время обработки. К сожалению, SRRS не просто проверил, получил ошибку http и вернулся, он ждал и ждал. Я предпочитаю (но не проверил), что он пытался получить изображение для каждой страницы отчета. Я говорю это из-за корреляции между длиной отчета и несоответствием между старым временем выполнения и временем выполнения, когда существовала проблема. Казалось, задержка на 5-12 секунд на каждой странице отчета.

Если вам нужна более подробная информация о том, как я исправил проблему, см. Мой пост:

Службы отчетов SQL Server - Быстрый TimeDataRetrieval - Долгое время обработки

С уважением,

Bernie

Answer 4

Мне удалось решить аналогичную проблему, которая возникла после того, как мы переключили серверы баз данных и обновили строки подключения в web.config. Мой запрос выполнялся примерно через 5-6 секунд, но отчет занимал так много времени, что время моей веб-страницы истекло (я использую локальные отчеты; у меня нет сервера отчетов).

У меня было подозрение, что мои DataTables в моем DAL все еще искали старый сервер, прежде чем перейти на новый. Я, вероятно, далеко от этой идеи, но решение для нее все еще работает!

Я обновил все DataTables в моем файле .xsd, выбрав «Настроить» в контекстном меню и, сохраняя все значения по умолчанию, нажимал «Далее», пока мне не пришлось нажимать «Готово». После просмотра каждой таблицы данных, я перестроил веб-сайт, и теперь он работает так же быстро, как и мой запрос.

Надеюсь, это поможет!

Answer 5

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