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

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

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

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

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

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

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

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

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

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

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

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

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


sql-server reporting-services
person Rich Rousseau    schedule 19.11.2008    source источник
comment
Являются ли ваши блоки SQL и блоки IIS отдельными?   -  person gbn    schedule 27.11.2008

Ответы (5)


arrow_upward
1
arrow_downward

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

Любая перегрузка ЦП на любом из серверов?

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

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

person Sam    schedule 19.11.2008

arrow_upward
1
arrow_downward

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

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

person automatic    schedule 01.12.2008

arrow_upward
0
arrow_downward

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

person Arvo    schedule 24.11.2008

arrow_upward
0
arrow_downward

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

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

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

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

person Dubs    schedule 07.01.2009

arrow_upward
0
arrow_downward

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

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

Службы отчетов SQL Server — Fast TimeDataRetrieval — Long TimeProcessing

С уважением,

Берни

person BernicusMaximus    schedule 17.03.2010