Тяжелые Запросы В 1с И Способы Защиты Памяти На Сервере

Тема в разделе "1C и всё что с ней связано", создана пользователем cezey, 14 ноя 2011.

  1. cezey

    cezey Member

    Регистрация:
    17 июн 2009
    Сообщения:
    6
    Симпатии:
    0
    Привет!
    Есть вопрос ;)
    Есть конфигурация 1С 8.1 Розница. База работает на SQL варианте.
    В консоль кластеров создано 10 rphost.
    Оперативной памяти на сервере приложений 40 Гб.
    Есть файл подкачки... сколько место не знаю.

    Однако при запуске пользователя "тяжелого отчета" бывает что 1С зависает на компьютере, пользователь видит что все висит и через диспетчер устройст разрывает соединение... Запускает программу заново, однако, процесс с отчетом остается на сервере и постепенно съедает все оперативку.
    После того, как оперативная память кончается либо автоматом перезагружается host либо служба 1С.

    Это крайне не приятно... как можно избежать данной проблемы?
    Быть может ограничить максимальную транзакцию? ЕЕ можно увидеть в кластере сервера..
    Либо что-то еще?
    Переписывать отчеты и запрещать ставить большие интервалы дат не хочется.
    Жду сообщений.
     
  2. puh14

    puh14 Well-Known Member
    1C Team

    Регистрация:
    11 июл 2008
    Сообщения:
    1.412
    Симпатии:
    0
    постоянный отжор оперативы до полного её окончания говорит косяности написания отчета. Не должно так быть. Очень смахивает на бесконечный цикл.


    Насчет транзакции - вы уверены, что это именно отчет? Насколько я понимаю транзакция - это запись в БД.

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

    а так по-хорошему - смтреть какое узкое место у вас получилось (запрос, его обработка, функции какие-то хитрые) и "расширить и углУбить".


    Кстати вспонилось - универсальный отчет в 8.1 изначально был косяный на предмет рассчета ширины колонок - именно она жрала 80% времени и ресурсов. Где-то встречал переделку под другой вариант расчета, поставил себе - усё залетало.
     
Загрузка...

Поделиться этой страницей