Истекает время ожидания при формировании сводного отчёта по квартирам

Здравствуйте. У нас похожая ошибка, но во время формирования отчета. Скажите, как увеличить тайм-аут?
Нашел настройки тайм-аута, но там ограничение - 120 (попугаев?). В нашем случае этого недостаточно, можно ли как-то увеличить количество этих попугаев?


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

Суть в том, что ваша система отказывается формировать практически дефолтный отчет, в котором всего 500 точек учета.
Я вижу несколько вариантов решения

  1. сделать апгрейд комьютера.
    (Сейчас:
    Процессор Intel(R) Core™ i3-4170 CPU @ 3.70GHz, 3700 МГц, ядер: 2, логических процессоров: 4
    Установленная оперативная память (RAM) 4,00 ГБ

)
2) разбить отчет на 10 частей и потом все это склеивать.

Оба варианта кривые. Система должна выполнять работу, медленно если железо слабое (кстати железо вполне укладывается в ваши системные требования), но выполнять! А у вас система просто не работает.

а) у нас 1 объект учета (если я правильно понимаю ваши формулировки, достаточно запутанные кстати)
б) написано “для комфортной работы рекомендуется”, то есть отсюда следует, что если мы не уложились в эти требования, то работа будет некомфортная, но она будет. Мы же имеем отсутствие работы как таковой. Ваша система отказывается работать, безапеляционно. Это ненормально. Убирайте ограничение
LersSystemRequirements.PNG

Вася, почитайте правила нашего форума. Для вашего вопроса нужно создать новую тему.

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

В вашем случае скорее всего проблема в RAM. Чем больше её объём тем эффективнее SQL сервер обрабатывает запросы.

Сделать SELECT, в результате которого всего несколько тысяч строк - крайне затратная операция? Отличная шутка. Делать-то что?

Заказчик не будет докупать RAM. Я проводил эксперименты: проблемный отчет формируется , если выбирать интервал около месяца.
Если больше - упираемся в тайм-аут. То есть если будет скажем 100 точек учета в отчете, но большой период, ведь тоже будет проблема скорее всего.

Также я думаю, заказчик не будет рад, если я разобью отчет на 10 частей.
У нас есть опыт работы в других системах телеметрии, я сам делал там отчет в фастрепорте на > 1000 меркуриев. Отчет там формируется очень медленно, но он формируется.

Ну вы посмотрите сколько у вас всего записей в таблице и прикиньте размер индекса, который SQL server дложен загрузить в память для выполнения выборки. Судя по всему, компьютер у вашего заказчика не выделенный для ЛЭРС УЧЁТ, а используется как рабочий, да и диск далеко не SSD. 4ГБ с современными приложениями расходуются махом, вот ОС и начинает свопить всё подряд, когда сервер пытается вытянуть индекс из файла подкачки.

Увеличение таймаута на ответ от сервера больше 120 секунд вам не поможет, поскольку у вас заканчивается другой таймаут - на обращение к БД. По умолчанию он равен 60 секундам. Настраивается в конфигурационном файле сервера.

Вы мне решение какое-то можете предложить? Без дополнительных трат на модернизацию сервера?

Пожалуйста, перечитайте последнее предложение моего сообщения. Вы можете увеличить таймаут на обращение к БД в конфигурационном файле сервера. Сервре после этого придётся перезапустить.

Все. Это решение. Вы решили мою проблему! Спасибо

Но хочу сделать несколько наблюдений. Я могу ошибаться, но:

  1. Прогресс при формировании отчета сразу перепрыгивает с 0 до готово. Это намекает на то, что есть один большой запрос к бд. Об этом же говорит и тайм-аут. Я бы отказался от больших запросов в пользу маленьких (не 1 запрос на 500 точек, а 500 запросов на 500 точек).
  2. При формировании отчета серверный процесс потребил около 1Гб. Здесь скорее всего нужен рефакторинг (вероятно, entity framework основной виновник), Это вообще не дело, как мне кажется.
    Это просто мои предположения. Так как код я не видел
    LersReportMemoryLeak.PNG

Вы можете создать тему в разделе Предложения по улучшению ЛЭРС УЧЕТ, что бы мы рассмотрели ваше предложения.