Вход | Регистрация

1С:Предприятие :: 1С:Предприятие 8 общая

Защита от дурака.

Защита от дурака.
Я
   Dunya18
 
12.04.17 - 23:31
Коллеги, поделитесь своим мнением, какие Вы у себя защиты от дурака внедрили, чтоб пользователи Вам не ложили всю базу например каким нибудь отчетом с кривым отбором\периодом. Решали вопрос на уровне кластера 1с или же переписывали сами отчеты (тут имеется ввиду, не сам запрос, а например проверки, указан ли период) ? Или какое то иное комплексное решение, может быть на уровне самой СУБД ? Или как-то еще на сервере приложений. Очень интересно выслушать Ваше мнение и опыт.
 
 
   Glenas
 
1 - 12.04.17 - 23:52
(0) УФ - зло. Можно всё что угодно юзеру в отчетах, многое приходится закрывать.
На обычных предустановленным отбором и их вариантами с переключениями между настройками.
   H A D G E H O G s
 
2 - 12.04.17 - 23:52
"Безопасный расход памяти за один вызов"
   Glenas
 
3 - 12.04.17 - 23:52
(1) + а если у тебя период ложит отчет, то значит отчет непрвильный
   Неверный Параметр И
 
4 - 12.04.17 - 23:55
период ложит отчет [x]
   Glenas
 
5 - 12.04.17 - 23:56
(4) Я использовал сленг ТС)
   Dunya18
 
6 - 12.04.17 - 23:57
(1) Нет никаких УФ :) УПП 1.3 на обычных формах, недавно вот перешли на 1с 8.3, работаем в режиме совместимости ))
   Dunya18
 
7 - 12.04.17 - 23:58
(2) Мысль действительно интересная, однако, как же быть например с тяжелыми регламентными заданиями вне рабочее время? Например расчет себестоимости? Порядка 80% занимает всей ОЗУ.
   Dunya18
 
8 - 13.04.17 - 00:01
(3) Гигантская куча внешних отчетов доставшихся по наследству. Вот рассматриваю пути, смогу ли избежать ситуацию. В принципе у меня конечно очень редко доходит до полного обвала продакшена, спасибо заббиксу за это. Но не очень комфортно постоянно дропать сеансы. Ищу пути решения, хотелось бы послушать кто и как решил проблему у себя)
   Glenas
 
9 - 13.04.17 - 00:01
(7) Это не вариант лимитировать по памяти. Боремся уже со следствием
   Dunya18
 
10 - 13.04.17 - 00:09
По поводу лимитирования.

Вообще схема баз у меня следующая, есть Главный узел и от него 5 РИБов (базы порядка 1 ТБ+). Во всех РИБах наш админ как раз таки настроил лимитирование, но лимиты стоят конкретно на рпхосты + у них есть 300 секунд на возврат в нормальное состояние. Лимитировать Главный узел нет возможности как раз таки из-за расчета себестоимости в большей степени. Если только р\с не переносить на отдельный сервер посредством требований назначения функциональности.
 
 Рекламное место пустует
   Glenas
 
11 - 13.04.17 - 00:10
(8) Ну см. в запрос, может там в виртуальных таблицах бардак или соединения без использования регистров или неправильное написание, либо отсутствие временных таблиц и т.д.
   Glenas
 
12 - 13.04.17 - 00:12
(11) ВЫБРАТЬ РАЗРЕШЕННЫЕ запросе тоже может помочь
   Dunya18
 
13 - 13.04.17 - 00:14
(11) Вопрос немного в другом, я все ровно все отчеты не смогу переписать, вопрос в большей степени как минимизировать риски падение\замедление работы продакшена. А так безусловно все выявленные случаи отправляются разработчику на доработку.
   Dunya18
 
14 - 13.04.17 - 00:16
Пока мысли в голове, это использование вот этого нового функционала по требованию-назначения функциональности. Возможно как вариант:
1. Перенос р\с на отдельный сервер, на основном сервера выставлять лимиты по памяти за один вызов.
2. Перенос формирование всех отчетов полностью на отдельный сервер.
   Glenas
 
15 - 13.04.17 - 00:20
Я что - то недопонял из (13) и (14)
Ты писал, что проблема возникает из-за некорректного выбора группировок, записей, выборок в отчетах.
А типовые внешние отчеты работают нормально. А сейчас говоришь что падает и замедляется всё
   Dunya18
 
16 - 13.04.17 - 00:32
(15) Ты меня сейчас сам уже запутал.

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

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

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует