Коллеги, поделитесь своим мнением, какие Вы у себя защиты от дурака внедрили, чтоб пользователи Вам не ложили всю базу например каким нибудь отчетом с кривым отбором\периодом. Решали вопрос на уровне кластера 1с или же переписывали сами отчеты (тут имеется ввиду, не сам запрос, а например проверки, указан ли период) ? Или какое то иное комплексное решение, может быть на уровне самой СУБД ? Или как-то еще на сервере приложений. Очень интересно выслушать Ваше мнение и опыт.

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

"Безопасный расход памяти за один вызов"

(1) + а если у тебя период ложит отчет, то значит отчет непрвильный

период ложит отчет [x]

(4) Я использовал сленг ТС)

(1) Нет никаких УФ :) УПП 1.3 на обычных формах, недавно вот перешли на 1с 8.3, работаем в режиме совместимости ))

(2) Мысль действительно интересная, однако, как же быть например с тяжелыми регламентными заданиями вне рабочее время? Например расчет себестоимости? Порядка 80% занимает всей ОЗУ.

(3) Гигантская куча внешних отчетов доставшихся по наследству. Вот рассматриваю пути, смогу ли избежать ситуацию. В принципе у меня конечно очень редко доходит до полного обвала продакшена, спасибо заббиксу за это. Но не очень комфортно постоянно дропать сеансы. Ищу пути решения, хотелось бы послушать кто и как решил проблему у себя)

(7) Это не вариант лимитировать по памяти. Боремся уже со следствием

По поводу лимитирования.

Вообще схема баз у меня следующая, есть Главный узел и от него 5 РИБов (базы порядка 1 ТБ+). Во всех РИБах наш админ как раз таки настроил лимитирование, но лимиты стоят конкретно на рпхосты + у них есть 300 секунд на возврат в нормальное состояние. Лимитировать Главный узел нет возможности как раз таки из-за расчета себестоимости в большей степени. Если только р\с не переносить на отдельный сервер посредством требований назначения функциональности.

(8) Ну см. в запрос, может там в виртуальных таблицах бардак или соединения без использования регистров или неправильное написание, либо отсутствие временных таблиц и т.д.

(11) ВЫБРАТЬ РАЗРЕШЕННЫЕ запросе тоже может помочь

(11) Вопрос немного в другом, я все ровно все отчеты не смогу переписать, вопрос в большей степени как минимизировать риски падение\замедление работы продакшена. А так безусловно все выявленные случаи отправляются разработчику на доработку.

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

Я что - то недопонял из (13) и (14)
Ты писал, что проблема возникает из-за некорректного выбора группировок, записей, выборок в отчетах.
А типовые внешние отчеты работают нормально. А сейчас говоришь что падает и замедляется всё

(15) Ты меня сейчас сам уже запутал.

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

Не знаю как еще мысль донести свою, если я как-то не понятно выражаюсь :)

(16) А ты не думаешь, что почти ЛЮБОЙ, даже нормально написанный отчет (особенно для УПП) уронит СУБД, в итоге сервер вернет ошибку памяти.
Достаточно из детальных записей удалить группировки и перенести их в столбцы или строки если их там тысячи.
Определись, с чем ты хочешь бороться

(17) Я хочу бороться с сессиями пользователей, которые на выходе формируют запрос к СУБД, результатом которого возвращается огромное кол-во строк (из-за которых рп хост может быть > 8 ГБ), чтобы последствия формирования такого запроса не приводило к остановке сервиса. А уже потом посредством траблшутинга исправлять эти куски кода конфигурации\запросы в отчетах и т.д.
- Давай так попробую объяснить :-D
p.s: "в итоге сервер вернет ошибку памяти. " - Может мы из-за этого друг друга понять не можем ? У меня ничего не возвращает. Кончилась ОЗУ -> Берем из СВОПа.