Проблема производительности. Как может заблокировать работу в ERP один-единственный документ от 01.01.2099 года?

24.01.23

База данных - HighLoad оптимизация

Разберем ситуацию, когда создание одного ошибочного документа будущей датой может существенно ухудшить работу пользователей в базе 1С.

Скажу сразу — с такой проблемой можно столкнуться практически в любых версиях 2.4 конфигурации ERP и соответствующих УТ, КА. Чтобы прочувствовать эффект, нужно взять базу побольше, а дальше добавить один единственный документ.

В версии 2.5 по всей видимости с подобной ситуацией столкнулись и реализовали предупреждение при попытке провести документ дальним будущим, но «злобный» пользователь при желании все равно сможет наломать дров.

Кто виноват и почему так получилось, ищите ниже в статье.

 

План статьи:

  1. Обнаружение проблемы
  2. Поиск точки возникновения проблемы
  3. Анализ найденной проблемы
  4. Горячее исправление текущей ситуации
  5. Пути решения и дополнительное исследование

 

Исходные параметры рассматриваемой системы:

Итак, мы продолжаем делиться знаниями и опытом... 3. 2. 1. Поехали!

 

1. Обнаружение проблемы

 

Как всегда, проблема появилась внезапно. Начали появляться таймауты. Наш ИИ Лариса заметила нестандартную ситуацию и начала нагнетать обстановку. Потом подтянулись пользователи и начали жаловаться на затрудненность в выполнении некоторых операций в базе. База, конечно же, не встала, но работать стало некомфортно, даже можно сказать, значительно сложнее чем ранее.

 

 

Когда появились проблемы, "Who ya gonna call?" Конечно же надо сразу вызывать охотников за привидениями багами в базе 1С.

 

 

2. Поиск точки возникновения проблемы

 

Замеры есть, смотрим проблемы по блокировкам:

 

 

Ого-го! Блокировок достаточно много с обычными 3-4 в десять минут.  Мы видим резкий рост проблем до нескольких сотен. Далее открываем журнал замера по блокировкам и начинаем его смотреть. В замер блокировок включаются события TTIMEOUT (ошибка по таймауту на управляемых блокировках) и TDEADLOCK (взаимоблокировки). Мы видим в основном только TTIMEOUT.

 

 

Смотрим контекст:

 

 

По контексту видно, что блокируются виды запасов по товарам. Иными словами, подбираются остатки видов запасов и на время проведения документа на них ставится блокировка, чтобы их не подъел кто-то другой.

Сначала у нас было предположение, что какой-то пользователь или регламент завис. И вот этот злодей блокирует работу остальных. Надо провести анализ. Его проводили по следующему алгоритму:

а) Мы взяли значение из поля WaitConnections:9680 из журнала блокировок.

 

 

б) Далее взяли срез данных консоли RAS на время  10:19

 

 

И нашли сеанс пользователя, который заблокировал. Это номер 12489. 

в) Далее посмотрим, что за пользователь.

Во-первых, мы видим, что этот пользователь висит довольно долго — более 230 с.

 

 

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

После проверки нескольких пользователей в попытке найти зависший сеанс проявилась следующая картинка:

  1. Пользователь Иванов проводит Этап. Его ждет пользователь Петров и Козлов. 
  2. Потом в какой-то момент времени Петров дожидается и начинает проводить документ. Теперь его ждут Иванов и Козлов.
  3. И так по кругу. Переходим на шаг 1, но уже с другим пользователем.

Иными словами, нет злосчастного зависшего сеанса. Предположение не подтвердилось. Давайте смотреть дальше.

Посмотрим по этому пользователю (которого мы анализировали выше) проблемные запросы. Помните, было ощущение, что время проведения подозрительно большое.

Открываем замер "длительные запросы" и видим интересную картинку (рисунок ниже). Берем ориентировочное время блокировки по этому пользователю и обнаруживаем продолжительный запрос. И не один, таких сразу несколько.

 

 

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

Дальше будем смотреть по контексту. Открываем его:

 

 

Судя по всему, выполняется проведение этапа. Получается, что стало происходить что-то необычное при проведении этапа, т.к. время проведения составило практически 60 с.  Это очень много.

Делаем предположение, что виной вот этот запрос. Модуль, в котором видна проблема - это ПроведениеСерверУТ. И функция - ВыполнитьКонтрольРезультатовПроведения. Отправная точка для начала поиска у нас есть. Теперь осталось найти зацепку для поиска текста запроса.

Давайте откроем запрос. Он хранится в замере (колонка SQL). И эта форма с текстом подозрительно долго открывается. 

 

 

В нем более 10 000 строк, Карл! Вот это запрос!!!

 

 

Наше подозрение подтверждается. Ищем теперь его внутри лога от PostgreSQL. Я искал по части строк и запроса «FROM _AccumRgT40229 T4». Находим первый, и он сразу похож на проблемный.

 

 

На рисунке вы можете увидеть дату от 3999 года. Но это нормальная ситуация, это дата бесконечности от компании 1С. На эту дату хранятся текущие итоги в таблице итогов регистра накопления (_AccumRgT).

Теперь ищем план. Это было непросто, но мы смогли, и он занимает 61 180 строк! Ради спортивного интереса мы попробовали его посмотреть, но, увы, слишком он здоровый. И мне так и не удалось его открыть в браузере. Не беда.

Кстати, посмотрите, как из-за этой проблемы вырос лог сервера PostgreSQL.

 

 

Размер запроса в строках (Сам запрос + План запроса), который выполняется практически при проведении каждого коммерческого документа, объясняет,  почему вырос лог с 13 МБ до 650 МБ. 

Давайте поищем, где формируется такой запрос внутри конфигурации. Выбираем какой-нибудь знаковый кусочек. Мы выбрали небольшой отрывок этого "шедевра", который часто повторяется. И, преобразовав запрос, мы начинаем искать, где встречается подобная штука.

 

 

В самом модуле ПроведениеСерверУТ такой шаблон не встречается. Но мы видим, что текст запроса проверки собирается из частей. И мы понимаем, что этот запрос должен быть связан с товарами организаций.

После непродолжительного поиска был обнаружен вызов подходящей функции - ЗапасыСервер.ДобавитьКонтрольПоТоварамОрганизаций. Внутри которой встречается подобный текст. Это шаблон для запроса, и называется он ШаблонЗапросаОстаткаМесяца

 
 Код шаблона запроса ШаблонЗапросаОстаткаМесяца

Мы нашли точку формирования проблемы. И будем смотреть эту функцию дальше.

 

3. Анализ найденной проблемы

 

Итоговый текст запроса, который мы видели в логах, формируется именно в этой функции. Такое количество объединений у нас получается в цикле, который ниже.

 

 

Нам интересно понять - сколько итераций внутри этого цикла будет выполняться. И соответственно чему равны два параметра. Шаг итератора у нас равен 1 месяцу.

а) МинимальныйПериод определяется так:

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

 
 Запрос получения минимального возможного значения МинимальныйПериод

 

ВЫБРАТЬ ПЕРВЫЕ 1
	РезервыТоваровОрганизаций.Период КАК Период
ИЗ
	РегистрНакопления.РезервыТоваровОрганизаций КАК РезервыТоваровОрганизаций
	
УПОРЯДОЧИТЬ ПО
	Период

 

2. А потом выбирается дата не более 3 лет назад.

 
 Уточнение значения переменной МинимальныйПериод

 

	МинимальныйПериод = КонецМесяца(Мин(МинимальныйПериод, ДатаПервогоРезерва(МинимальныйПериод)));
	КонецТекущегоМесяца = КонецМесяца(ТекущаяДатаСеанса());
	
	// Больше трех лет не контролируем, чтобы не превысить количество таблиц в запросе.
	ТриГодаНазад = КонецМесяца(ДобавитьМесяц(КонецТекущегоМесяца, -36)); 
	Если МинимальныйПериод < ТриГодаНазад Тогда
		МинимальныйПериод = ТриГодаНазад;
	ИначеЕсли МинимальныйПериод > КонецТекущегоМесяца Тогда
		МинимальныйПериод = КонецТекущегоМесяца;
	КонецЕсли;

 

Т.е. получается, что разработчики подумали над тем, чтобы не лезть слишком глубоко в прошлое. Т.е. 3 года назад от текущей даты это будет не менее 01.01.2020 года. А что у нас со второй переменной - ОбрабатываемыйМесяц?

б) А вот обрабатываемый месяц находится через функцию ДатаПоследнегоДвижения (на рисунке выше выделено красной чертой). А внутри этой функции нас ожидает запрос:

 
 Запрос получения максимального периода среди всех регистраторов

 

ВЫБРАТЬ ПЕРВЫЕ 1
    ТоварыОрганизаций.Период КАК Период,
    ТоварыОрганизаций.Регистратор КАК Регистратор
ИЗ
    РегистрНакопления.ТоварыОрганизаций КАК ТоварыОрганизаций

УПОРЯДОЧИТЬ ПО
    Период УБЫВ

 


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

 

 

Вот это поворот. У нас в базе есть документ фактически из следующего века.

Давайте посмотрим на документ, узнаем, как он появился - пользователь или какой-то регламент.

 

 

Он был создан пользователем. И это очевидная ошибка ввода данных. Мы нашли проблему!

 

Небольшое подведение итога по расследованию:

Алгоритм работает с максимального периода (2099 года) и движется назад к текущей дате с шагом 1 месяц. Фактически мы видим, что цикл работает от даты, которая хранится в переменной ОбрабатываемыйМесяц, и до даты МинимальныйПериод.

Если посчитать вручную, то это чуть больше 900 объединений. Вот таким образом и получается наш запрос монстр. В обычном режиме работы всего несколько объединений (может, десятка два), которые не влияют на производительность в целом.

 

 

А самое замечательное, что чуть ранее до выполнения контроля вызывается управляемая блокировка видов запасов по товарам организаций  в большинстве случаев - функция ЗапасыСервер.ЗаполнитьЗапасыТоваровОрганизаций

По результатам этого мини расследования мы можем кратко описать работу пользователей:

  1. Пользователь проводит документ.
  2. В какой-то момент устанавливается блокировка при вызове функции ЗапасыСервер.ЗаполнитьЗапасыТоваровОрганизаций.
  3. Выполняется контроль в функции ПроведениеСерверУТ.ВыполнитьКонтрольРезультатовПроведения, который занимает 60 с из-за тяжелого запроса контроля остатков. Блокировка все еще держится.
  4. Все остальные пользователи, кто решил провести данные по совпадающим аналитикам разреза блокировки, начинают ожидать и встают в очередь (очередь СУБД).
  5. Проведение завершается и блокировка снимается.
  6. Следующий счастливчик пользователь из очереди начинает проводить свой документ.
  7. Переходим в начало на шаг 1.

 

4. Исправление текущей проблемы

 

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

Берем копию базы и на ней пробуем (в данной ситуации можно взять любой свежести и добавить новый документ будущей датой). Проводим тестирование по следующим шагам:

  1. Сначала проводим документ как есть, ловим 60-70 секунд при проведении и запрос монстр. Видим его в логах и замерах.
  2. Теперь изменяем дату на 2023 и проводим еще раз. О чудо. Проведение вернулось в район нескольких секунд. Логи ушли.

Оперативно передаем информацию администратору базы. И ждем исправления документа. После правки контролируем изменение ситуации.

  • Графики должны вернуться в норму
  • Блокировки в журнале блокировок должны уйти
  • Пользователи должны начать работать штатно

Смотрим графики после исправления ситуации:

Применили исправление около 11 часов. Проблема ушла практически мгновенно и все вернулось в норму.

На графиках ниже приведены результаты замеров. Нам доступны следующие показатели (про них можно узнать подробнее в статье Анализ проблем производительности по динамике мониторинга RAS 1C):

  • очередь к сервисам 1С (сколько обращений к службам в единицу времени),
  • очередь к СУБД (сколько в единицу времени обрабатывает СУБД запросов),
  • нагрузка на сервере 1С и СУБД.

Красная черта - это граница - экспертная оценка, которая считается верхней нормой, при которой работа считается нормальной. Также мы видим, что блокировки не нагружают сервер 1С. Это логично, т.к. он просто ждет и ждет, пока ему вернут результат запроса. А вот на СУБД ситуация противоположная и нагрузка достигает 50%, и пик явно выражен.

 

 

Для наглядности приведем еще график блокировок с данными за двое суток - проблемный и следующий день. Слева проблемный день, а справа тишь да гладь.

 

 

Резюме:

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

 

5. Пути решения и дополнительное исследование проблемы

 

Что же, пожар потушен! Теперь можно более пристально взглянуть на ситуацию и подробнее разобрать, что произошло, почему и как исправить. Думаю, что так все поступают.

Прежде чем самостоятельно садиться и придумывать решение - как закрыть эту «дырку», давайте ответим на вопрос: «А что у нас в ERP 2.5?». Зачем что-то придумывать, если решение уже существует.

а) Сначала проверим наличие подобного контроля в товарах организаций этой версии конфигурации:

Ищем по ключевым фразам и находим. Данную функцию перенесли в общий модуль «ЗапасыСервер». И называется она сейчас «ИнициализироватьДанныеКонтроляИзменений». Сам подход ее остался тем же, т.е. ситуация в целом повторяема.

б) Теперь проверим/повторим наличие ошибки или найдем наличие исправления.

Попробуем сходу в демонстрационной базе создать новый документ и провести его будущей датой.

При попытке выполнить такую операцию нам выдается предупреждение о возможной ошибке. Данная ситуация обрабатывается. Видимо, подобного характера "особенность" встречалась еще у кого-то, и вендор добавил обработку ситуации. И поэтому в качестве отправной точки для собственной "заплатки" будем использовать предложенный подход.

На рисунке ниже приведен результат эксперимента с созданием документа будущей датой на демонстрационной конфигурации ERP версии 2.5.

 

 

в) Теперь давайте посмотрим, а почему собственно возникают такие проблемы? Возьмем базу с хорошим набором данных. У нас есть одна такая под рукой. И опять смоделируем ситуацию. Дату возьмем поменьше, т.к. слишком много текста.

В результате мы получили следующую картинку (приведена ниже). Еле заметная красная черточка на круге - это одно объединение. Из схемы следует, что как таковых перекосов нет, просто очень много объединений, которые равноценно вносят вклад в общее время.

 

 

 

 

См. также

Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    2965    spyke    26    

42

Быстродействие типовой 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    5100    vasilev2015    19    

37

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    7626    158    ZAOSTG    67    

96

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    5967    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8851    ivanov660    6    

76

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    5097    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

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

11.10.2023    16167    skovpin_sa    14    

98
Отзывы
18. m_aster 111 24.01.23 22:32 Сейчас в теме
(17)Вот-вот. Как будто 1С вчера появилась и подобных ошибок предположить ребята-разработчики не могли проектируя такое сложное решение. Ведь сама 1С разработала стандарты, в том числе написания запросов и т.д. Впечатление, что пишут настолько разные люди, что кто-то соблюдает стандарты, кто-то около того(в статье о комментариях привел в пример два модуля, один "голый", ни единого коммента, второй привычный, как полагается, как пишет сама 1С в своих стандартах).
Вообще, системы 1С усложняются все больше, превращаясь в монстров, на мой взгляд, не всегда оправданно, к примеру, в УХ дали задачу посмотреть почему не формируются счета номенклатуры в документе, я пока прошел по всем модулям в отладчике, потратил около 4-х часов, и в конце концов пришел к месту в коде, где по типу номенклатуры, например, "Товар" присваивается программно 41 счет. Зачем такая сложность, куча проверок, сложного кода, когда проще было сделать как раньше, регистр с одноименным названием - "Счета учета номенклатуры", заполнить его и вести, и гораздо проще, и быстрее, плюс конфа будет меньше "весить". Ну да, человеческий фактор, это ж надо себя заставлять, заполнять, вести, следить)).
Сейчас в семействе УТ, КА, ЕРП наблюдается система жизненных циклов, насколько я вижу, поддержка 2.4 прекратилась с мая 2022 и даже внутри 2.5 тоже самое, 2.5.8 сколько-то живет, поживет-поживет и отомрет, переходи на 2.5.9.
Люди только-только внедрили 2.4, потратив кучу денег и сил, и теперь хочешь, не хочешь переходи на 2.5.8(не важно какая версия, она все равно будет ограничена по времени), к примеру, а она до апреля 2023 и так дальше.
Такие сложные системы, на мой взгляд, эффективнее выпускать в виде блоков, в той же КА сколько раз видел, как БП подсистемой не хочет народ пользоваться(по сути, "висит", ненужный блок), пилят различные обмены, выгрузки и т.д. в БП, из-за регламентного формирования движений, как это мотивирует 1С почему так, судя по учебным роликам, потому что во главе оперативный учет. Так и выпустите основной блок УТ 11, хочешь нарастить функционала, докупай соответствующий блок, как раньше было в семерке, купил БП и работаешь и горя не знаешь, нужен тебе склад, докупил склад. И проще и понятнее, и эффективнее обслуживать.
В принципе, оно и сейчас так есть, конечно, поставил УТ, поставил отдельно БП и синхронизируй между собой, правильно настрой и наблюдай за ними. Но если нужен еще какой-то функционал, больше, чем в УТ, взял бы КА или ЕРП, например, а там та же УТ и та же БП в составе, зачем? У меня уже есть и то и другое, живет и работает себе прекрасно и люди привыкли.
Автору огромное спасибо, очень интересно и познавательно, прочитал на одном дыхании.
Lacoste4life; MiCe; fatman78; asu63samaraoil; dmitryada; olexi2012; polskay; vakham; kuzyara; kamisov; elena_veza; user1194361; xantif_2000; EliasShy; shu_vol; ivanov660; +16 Ответить
38. Gilev.Vyacheslav 1910 25.01.23 11:43 Сейчас в теме
всего бы этого не было если решения автоматом хотя бы раз в сутки проверяли документы старше ну пусть будет 20 лет и будущими годами, большинство таких ошибок носит характер 0023 год вместо 2023 года
d_sdr; quazare; sapervodichka; ivanov660; +4 Ответить
Остальные комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Nefilimus 75 24.01.23 11:32 Сейчас в теме
Кто-нибудь скиньте уже в 1С ссылку на значение слова "Оптимизация". С каждым релизом всё хуже и хуже...
корум; vakham; kamisov; +3 Ответить
2. tormozit 7136 24.01.23 12:27 Сейчас в теме
ВыполнитьКонтрольРезультатовПровдеения
Опечатка ?
3. ivanov660 4330 24.01.23 12:40 Сейчас в теме
4. tormozit 7136 24.01.23 13:21 Сейчас в теме
Было бы полезно иметь не только картинки, отображающие текст, но и их тексты натурально. Это позволит
- искать по ним
- копировать
- разглядеть в хорошо читаемом размере шрифта без необходимости открывать картинку в новом окне, о чем кстати многие не знают
karpik666; artbear; kser87; +3 Ответить
6. ivanov660 4330 24.01.23 14:15 Сейчас в теме
(4)Приложить файл запроса 10 000 и плана с 60 000 строк?
Или речь про контекст? Или про все вместе
8. starik-2005 3033 24.01.23 14:25 Сейчас в теме
(6) 70к знаков - на 7 статей хватит, т.е. на 70 $m)))
ogroup; Shmell; awk; BurlakovIvan; CherTolik_26rus; +5 Ответить
27. tormozit 7136 25.01.23 07:07 Сейчас в теме
(6) На картинках НЕ показаны 10к или 60к строк, а показаны некоторые фрагменты примерно по 50 строк. Вот их и хотелось бы в текстовом виде. Главное неудобство - на ужатых картинках трудно читать текст.
33. ivanov660 4330 25.01.23 10:05 Сейчас в теме
(27) В следующих статьях учту предложение.
5. Tonik_ 24.01.23 13:23 Сейчас в теме
Почитать расследование было интересно. Спасибо
SergeyTerentyev; ivanov660; +2 Ответить
7. starik-2005 3033 24.01.23 14:23 Сейчас в теме
У нас в базе есть документ фактически из следующего тысячелетия.
Прям вот так?
Вообще, в 1С таких костылей овер дофига. Как-то смотрел, как строится запрос по ДЗ/КЗ, так там тоже такой вот "бесконечный" цикл. И то, что там был мелкомягкий скуль, горю мало помогало.
40. siamagic 25.01.23 12:25 Сейчас в теме
57. starik-2005 3033 15.02.23 13:57 Сейчас в теме
(40) Автор, смотрю, поправил. Это как "вы из другой галактики? А мы из Чертаново!" (вот серьезно, прям с Магелланова облака летели, да?), хотя в 90-х авторы были грамотнее и писали, что из другого созвездия (хотя в одном созвездии расстояние между звездами в сотни парсек может быть, а в современной астрономии созвездие - это просто участок неба), хотя самое правильное было бы просто "из другой звездной системы" (и то правда, ибо в солнечной-то системе жизнь пока найдена лишь на Земле-родимой). Так что работа с большими цифрами и расстояниями - это больная проблема миллениалов и людей, который под них косят )))
9. tigrandis 340 24.01.23 14:30 Сейчас в теме
Сталкивался с этой проблемой в 2017 году в КА2 и думал давно исправили ...
10. kser87 2438 24.01.23 14:35 Сейчас в теме
Генерируемые программно запросы опасная штука. И выборки с неограниченным фактически периодом. Думаю, что в бюджетировании таких полно. Но там вряд-ли на общую производительность так влияет.
11. quazare 3586 24.01.23 16:44 Сейчас в теме
(10) УТ 11.5 почти вся сделана на подобных запросах
12. Shmell 533 24.01.23 17:23 Сейчас в теме
Сколько совокупно ушло времени на расследование проблемы? Это всегда забавно - когда незначительный косяк в пользовательских данных, который делается за 1 секунду - отнимает потом +-день на расследование ) Но зато, такие кейсы делают нас сильнее.
14. ivanov660 4330 24.01.23 17:47 Сейчас в теме
(12) Ориентировочно - в районе 1 часа. Если бы не отвлекали, то скорее всего быстрее.
sapervodichka; +1 Ответить
19. CheBurator 3119 24.01.23 22:41 Сейчас в теме
(12) прежде чем лазить в код - надо смотреть на явные косяки в базе на пользовательском уровне.
со времен клюшек два явных косяка с документами/регистрами - документы в начале времен и документы далеко в будущем. Это почти всегда "логическая" ошибка. Даже в код не надо лазить... В код уже лезть когда другое не помогает...
25. Shmell 533 25.01.23 05:47 Сейчас в теме
(19) А здесь вопрос - что быстрее найти: ошибку в данных в базе где работает овер 1000 пользователей (можно представить интенсивность ввода документов и справочников и вообще количество данных) или использовать инструментарий поиска проблем? Мое мнение - работа с инструментарием куда интереснее чем копание в данных. У такого подхода есть существенный плюс - между делом можно найти и другие потенциальные проблемы, которые можно зафиксировать в бэклог и потихонечку заняться их устранением.
28. CheBurator 3119 25.01.23 07:27 Сейчас в теме
(25) это да. но устранение технологических проблем редко ведет к устранению бардака в учете как такового. а документ от2099 года - ну явно в консерватории что-то не так...
d.snissarenko; Shmell; +2 Ответить
29. Shmell 533 25.01.23 07:28 Сейчас в теме
(28) все верно, нужен комплексный подход )
31. ivanov660 4330 25.01.23 09:30 Сейчас в теме
(19)
Без инструментария найти что-то практически не возможно. А тыкать пальцем в данные, на мой взгляд, все равно что играть в спортлото.
Проблемы часто встречаются в тех местах где их не ждешь. К тому же, для каждого случая должно быть объяснение причин и рекомендации по их устранению.
У нас есть методика по поиску и устранению проблем, в рамках нее мы и работаем.
13. tazhitkov 24.01.23 17:35 Сейчас в теме
А есчо с такими движениями, тормоза будут и не только от алгоритмов такого плана. Если более менее насыщеный регистр, там еще итогов стока наплодится. А если он еще не накопления а бухгалтерии, и без алгоритмов все колом встанет.
15. ivanov660 4330 24.01.23 17:58 Сейчас в теме
(13)Чем больше записей в регистре тем больше думает. Поэтому на демонстрационной базе замедление даже не почувствуется.
16. ildary 21 24.01.23 21:05 Сейчас в теме
Спасибо за автору за интересные подробности. Мне пришлось столкнуться с похожей проблемой, но там неверная дата была в прошлом - 215 год вместо 2015. Обнаружилось это из-за тормозов проведения складских документов, а причину нашли посмотрев размеры файлов регистров - и нашли раздувшийся (уже не помню его название), после чего запросом нашли проблемную дату и создавший эту дату документ.
ivanov660; +1 Ответить
17. kauksi 216 24.01.23 21:08 Сейчас в теме
А всего то, написать одну функцию, проверяющую параметры запроса (даже пусть собранный программно) на необычную дату...
18. m_aster 111 24.01.23 22:32 Сейчас в теме
(17)Вот-вот. Как будто 1С вчера появилась и подобных ошибок предположить ребята-разработчики не могли проектируя такое сложное решение. Ведь сама 1С разработала стандарты, в том числе написания запросов и т.д. Впечатление, что пишут настолько разные люди, что кто-то соблюдает стандарты, кто-то около того(в статье о комментариях привел в пример два модуля, один "голый", ни единого коммента, второй привычный, как полагается, как пишет сама 1С в своих стандартах).
Вообще, системы 1С усложняются все больше, превращаясь в монстров, на мой взгляд, не всегда оправданно, к примеру, в УХ дали задачу посмотреть почему не формируются счета номенклатуры в документе, я пока прошел по всем модулям в отладчике, потратил около 4-х часов, и в конце концов пришел к месту в коде, где по типу номенклатуры, например, "Товар" присваивается программно 41 счет. Зачем такая сложность, куча проверок, сложного кода, когда проще было сделать как раньше, регистр с одноименным названием - "Счета учета номенклатуры", заполнить его и вести, и гораздо проще, и быстрее, плюс конфа будет меньше "весить". Ну да, человеческий фактор, это ж надо себя заставлять, заполнять, вести, следить)).
Сейчас в семействе УТ, КА, ЕРП наблюдается система жизненных циклов, насколько я вижу, поддержка 2.4 прекратилась с мая 2022 и даже внутри 2.5 тоже самое, 2.5.8 сколько-то живет, поживет-поживет и отомрет, переходи на 2.5.9.
Люди только-только внедрили 2.4, потратив кучу денег и сил, и теперь хочешь, не хочешь переходи на 2.5.8(не важно какая версия, она все равно будет ограничена по времени), к примеру, а она до апреля 2023 и так дальше.
Такие сложные системы, на мой взгляд, эффективнее выпускать в виде блоков, в той же КА сколько раз видел, как БП подсистемой не хочет народ пользоваться(по сути, "висит", ненужный блок), пилят различные обмены, выгрузки и т.д. в БП, из-за регламентного формирования движений, как это мотивирует 1С почему так, судя по учебным роликам, потому что во главе оперативный учет. Так и выпустите основной блок УТ 11, хочешь нарастить функционала, докупай соответствующий блок, как раньше было в семерке, купил БП и работаешь и горя не знаешь, нужен тебе склад, докупил склад. И проще и понятнее, и эффективнее обслуживать.
В принципе, оно и сейчас так есть, конечно, поставил УТ, поставил отдельно БП и синхронизируй между собой, правильно настрой и наблюдай за ними. Но если нужен еще какой-то функционал, больше, чем в УТ, взял бы КА или ЕРП, например, а там та же УТ и та же БП в составе, зачем? У меня уже есть и то и другое, живет и работает себе прекрасно и люди привыкли.
Автору огромное спасибо, очень интересно и познавательно, прочитал на одном дыхании.
Lacoste4life; MiCe; fatman78; asu63samaraoil; dmitryada; olexi2012; polskay; vakham; kuzyara; kamisov; elena_veza; user1194361; xantif_2000; EliasShy; shu_vol; ivanov660; +16 Ответить
20. CheBurator 3119 24.01.23 22:46 Сейчас в теме
(18)
хочешь нарастить функционала, докупай соответствующий блок, как раньше было в семерке, купил БП и работаешь и горя не знаешь, нужен тебе склад, докупил склад. И проще и понятнее, и эффективнее обслуживать.

- смотри здесь на портале ответы Нуралиева на вопросы сообщества. Аналогичный мой вопрос - то ли второй то ли третий. Чтобы сделать такую блочную структуру - это надо очень нехило над архитектурой думать. по сути каждый блок работает независимо от кода другого блока. стык только на выходе предыдущего блока и вход текущего блока. Даже получение свободных остатков с блоком резервирования и без блока резервирования - я уже слабо себе представляю - почти никак - насколько изолированы блоки должны быть...
21. m_aster 111 24.01.23 23:39 Сейчас в теме
(20)Сергей, так, наверное, народ не зря спрашивает. Что будет дальше? SAP модульная система, к слову, чем не пример? Ключевые слова "надо очень нехило над архитектурой думать". Непременно надо думать, в любом случае, особенно, на перспективу, и не только о развитии продукта, а и о людях прежде всего, ты же им его продаешь, должен представлять как они будут работать, как удобно, как эффективно, как апгрейд, интеграция, развитие и т.д. Про резервирование не совсем ясно, зачем эти блоки разделять на отдельные блоки? Я о более крупном делении. Живой пример, фирма торгует товаром из Китая, есть УТ, БП, ну и ЗуП. Решили открыть свое производство, чтобы из Китая не возить. Смотрят на ЕРП, а там те же УТ и БП, и ЗуП в составе. Почему не сделать отдельно производственное решение, сама только поставка ЕРП стоит около полумиллиона плюс лицензии почти столько же. И получается люди приобретают избыточный функционал, еще раз такие же подсистемы, которые у них уже есть. А ранее приобретенные решения куда девать, если в ЕРП тоже самое также есть? Для производства важно обеспечение материалами, какими-то комплектующими и т.д., пусть УТ этим и дальше занимается. Нужные движения для БП пусть выгружаются в БП же регламентно. БСП, например, появилась, чтобы унифицировать и однообразить служебные вещи, так почему не унифицировать складской блок, производственный, бухгалтерский, бюджетирование, CRM, финансовый, зарплатный и т.д.?
MiCe; dmitryada; espero; +3 Ответить
22. CheBurator 3119 25.01.23 00:47 Сейчас в теме
(21) ну вот и унифицировали... В ЕРП
30. noprogrammer 236 25.01.23 09:29 Сейчас в теме
42. m_aster 111 25.01.23 12:53 Сейчас в теме
(30)Спасибо, посмотрел. Люди не просто недовольны, а предлагают свое решение, интересно. Расширения это первое, что приходит на ум. Это небольшие модули все же, и в основе ЕРП, где получаешь все и сразу. Я о более крупных блоках. Почему у нас нет отдельной производственной конфигурации? Чтобы была возможность расширяться более гибко, чтобы не дублировать функционал, а использовать существующий, соответственно, и экономить при этом.
43. noprogrammer 236 25.01.23 13:04 Сейчас в теме
(42)
Это небольшие модули все же, и в основе ЕРП, где получаешь все и сразу.

Это не "небольшие модули" и не в основе типового ЕРП.
Есть ядро конфигурации и есть модули (расширения) которые порой могут быть не меньше самого ядра (как бы странна это не показалась на первый взгляд). Например есть модуль (расширение), который расширяет возможности производственного учета (в частности производство БПЛА) при котором основной модуль производственного учета кажется просто детским.

Если конфигурация написана по принципу "монолита" то расширять ее с помощью модулей(расширений) практически никакого смысла нет.
44. m_aster 111 25.01.23 14:24 Сейчас в теме
(43)Не люблю спорить и не буду, Вы сами себе противоречите, по Вашей ссылке показано ядро конфигурации, которая носит в названии "ERP", посмотрите на базовый функционал "ядра" приведенный в описании, что это, как не "монолит". По сравнению с ним расширения это небольшие модули и так и должно быть, крупные блоки и наработки лучше встраивать в конфигурацию. И что значит "монолит"? Можно расширить и дополнить и ERP в том числе. Речь же не об этом, а об избытке функционала.
24. kauksi 216 25.01.23 05:00 Сейчас в теме
(18) Даже на партнерке, люди пишут, что 1с годами не исправляет критичных недоработок функционала ЕРП, зато в бета-релизах появляются свистоперделки, которые нужны единичным пользователям. LTS-версии живут год... а должны ну хотя бы 3... Вот на этот должна выйти 2.5.12, а ее только к марту выпустят... к сентябрю уберут критичные глюки... с каждым обновлением думаешь... что опять поломали... а исправлять да... часами сидеть в отладчике или (кто не готов) молится и ждать патч... Т
dmitryada; espero; sapervodichka; zakiap; +4 Ответить
23. dmitryada 25.01.23 03:43 Сейчас в теме
Только я в ШОКЕ, что в стандартном решении, для выполнения стандартной для учётной системы операции не придумали ничего лучше, чем сделать запрос на 60 000 строк? Руки опускаются после такого...
34. ivanov660 4330 25.01.23 10:09 Сейчас в теме
(23)Таким он стал из-за ошибки при вводе данных. Но вот про ограничения на "дурака" разработчики судя по всему не думают, т.е. считают что пользователь всегда все делает правильно, всегда вводит корректные данные, и в среднестатистической компании заводят 5-10 документов в год)
36. muskul 25.01.23 10:12 Сейчас в теме
(34)и на этих 5 документах все работает быстро, поэтому оптимизация не нужна
espero; ivanov660; +2 Ответить
53. shard 279 28.01.23 14:16 Сейчас в теме
(23) Относительно недавно в КА2 (2.5 кажется, но точно не помню, как и вид документа) смотрел механизм формирования проводок БУ. Запрос тоже формировался программно, содержал порядка 4000+ строк. На выходе - единственная проводка... И вроде все правильно, но зачем...
dmitryada; d_sdr; +2 Ответить
26. tormozit 7136 25.01.23 07:01 Сейчас в теме
Если запрос выполняется 60 секунд, то даже если он не блокирует других пользователей явно, я бы все равно его сразу проверил. Поэтому кажется надо мониторить все настолько долгие запросы, т.е. читалка логов должна их сразу помечать и ответственный их должен проверять, если это новый тип (шаблон) долгого запроса. А в статье показалось очень издалека шли поиска такого "слона".
32. ivanov660 4330 25.01.23 10:02 Сейчас в теме
(26) Идея конечно правильная мониторить каждый новый запрос и разбирать его причину. Но ситуация сталкивается с суровой действительностью - их очень много. И для их анализа и классификации сейчас нужно сажать отдельного человека.
Во-первых, очень много запросов, которые нельзя оптимизировать из-за RLS. Иными словами тут мы уперлись в ограничения, использовать новый производительный RLS в текущей версии нельзя, пока не выполним переход на 2.5. А перепиливать архитектуру под редко используемые действия - это слишком долго и дорого, не эффективно.
Во-вторых, куча долгих запросов по отчетам. У пользователей есть возможность отчеты крутить туда, сюда, снимать отборы и т.п.
В-третьих, вручную смотреть так себе удовольствие. Просто так сравнивать запросы по тексту на равно, плохо. Будет очень много задач. Их надо классифицировать. Алгоритм классификации, который мы ранее создали Автоматическая классификация ошибок технологического журнала слишком широк. Он сейчас у нас позволяет отнести тип запроса к какому-то ограниченному классу. Требуется более детальное сравнение. Это в дальнейшем можно будет сделать после того как создадим вот этот плагин Создать плагин статистики по аналогии с pg_stat_statements
Иными словами - это выглядит не так что сегодня появилось два новых запроса и мы их тут же препарировали. Их несколько тысяч каждый день. Работа идет, но не всегда, как я писал выше, можно взять и устранить проблему.
35. muskul 25.01.23 10:12 Сейчас в теме
Зря в заголовке написали ответ. Потому что читая всю статью и поиски в голове витало кто то сделал что то подобное.
37. Светлый ум 406 25.01.23 11:25 Сейчас в теме
В упп такие же проблемы были при документе 3***х годов
38. Gilev.Vyacheslav 1910 25.01.23 11:43 Сейчас в теме
всего бы этого не было если решения автоматом хотя бы раз в сутки проверяли документы старше ну пусть будет 20 лет и будущими годами, большинство таких ошибок носит характер 0023 год вместо 2023 года
d_sdr; quazare; sapervodichka; ivanov660; +4 Ответить
39. ivanov660 4330 25.01.23 12:03 Сейчас в теме
(38)
1. Для данной ситуации такое решение подойдет, но часто встречаются проблемы не такого банального характера.
Но вот есть беда, заказчик и владелец данных со скрипом исправляет ошибки в данных. Те что мешают работать оперативно - мгновенно, а все остальные идут очень тяжело. Видимо по принципу - не мешает работать и ладно, сейчас некогда, как-нибудь потом. А обещанного как известно ждут и ждут. И это не один такой заказчик.
2. Конечно идея интересная написать скрипт, который будет проверять на заведомо не верные данные и делать рассылку. Но если данные не будут исправляться, то эти письма в скором времени будут игнорироваться. Попробую обыграть идею.
41. Gilev.Vyacheslav 1910 25.01.23 12:36 Сейчас в теме
(39) да я больше не вам, а фирме 1С
имхо это надо централизовано делать, а не на откуп франчам и программистам, да и не факт что почта, лучше какое то монопольное раздражающее окно - "пока ты гад не исправишь я тебе постоянно буду напоминать, тебе будет легче исправить чем каждый раз ок жать" :)

ну и почему пользователи не любят исправлять - потому что обычно им свешивают задачу без конкретики "исправь там" (почему все программисты думают что пользватели знают что такое запрос с сортировкой по дате или начальник не вникая в детали теряет важное в постановке), а надо списочек этих документов дать и конкретику, написать исправляй дату этого документа (правильный номер должен быть не старше тольких то лет). А так с Вами согласен, с Заказчиками сложно :)
45. sapervodichka 6697 25.01.23 14:38 Сейчас в теме
(38) Сама ошибка с годами в будущем, у меня тоже несколько раз встречалась.
Если смотреть не в скрипты, а со стороны обычного 1С-ка типа меня, то:

Дата 0023 г. успешно отсекается датами запрета редактирования (механизм в каждом продукте 1С есть)
Дата 3023 г. не отсекается датами запрета редактирования (механизма нет)

По идее 1С можно было бы малой кровью механизм дат запрета редактирования допилить, добавив к полю "Запрет до даты" поле "Запрет после даты". Т.к. все подписки проверочные уже есть в конфах и даты проверяются постоянно у документов и регистров, думаю не повлияло бы на производительность проверять не только условие Документ.Дата >= ЗапретДоДаты, но и условие Документ.Дата <= ЗапретПослеДаты.
d_sdr; espero; +2 Ответить
46. kembrik 10 25.01.23 15:33 Сейчас в теме
(45) Встречное предложение, сделать редактирование даты пользователем максимально затрудненным, по типу редактирования номера. По умолчанию ставить текущую дату сеанса

Ловили неоднократно подобные ошибки, так как вовсю использовалось штрихкодирование документов, как и поиск по штрихкоду, если активна ячейка с датой, а пользователь этого не замечал, то в поле подставлялось со сканера такое... В итоге закрыли редактирование даты глобально, включив только просмотр.
espero; sapervodichka; +2 Ответить
47. ivanov660 4330 25.01.23 16:20 Сейчас в теме
(45) Запрет даты редактирования не на всех документах висит, в основном на регламентных. Поэтому не универсально.
56. user851077 04.02.23 19:44 Сейчас в теме
(47)А сравнивать даты в документах с текущей датой перед записью программистам западло?
48. Gilev.Vyacheslav 1910 25.01.23 16:30 Сейчас в теме
(45) реалтайм-проверки дороже по ресурсам сумарно, но тоже можно
но тогда надо еще проверять всякие обработки программистов, которые обычно под полными правами что то делают в обход многих проверок, всякие загрузки не из 1С и 1с-ные обмены, так как оттуда тоже может приехать

ну и кроме быстродействия, это еще ошибки в учете
в фирму 1С писать бесполезно, они всё только голованием теперь определяют )))
55. user851077 04.02.23 19:42 Сейчас в теме
(48)Знаете, Вячеслав, однажды мне удалось очень даже быстро убедить 1С в необходимости исправлений.
Дело было в августе 2012 года. Пользователи пожаловались на неправильных расчёт НДФЛ, и я полез разбираться. Оказалось, что в запросе ошибка (все конфигурации «Зарплата и Управление Персоналом», на мой взгляд, славятся каким-то невероятным числом ошибок в запросах, но, в данном случае, речь не об этом).
Нашёл ошибку и решил (вдруг!) написать в 1С.
Вы не поверите, но уже на следующий день вышли новые конфигурации ЗУП, КА и УПП. Под совершенно надуманными предлогами. Об исправленной ошибке в расчёте НДФЛ в сведениях о релизе не было ни слова.
В самом деле: узнай налоговики, что их любимая и доверенная программа неверно считала НДФЛ, их отношения с !С здорово бы осложнились. А фирме 1С оно надо?
49. user738268 26.01.23 09:58 Сейчас в теме
Проведена интересная работа. Не хотите посотрудничать по данной теме? Есть ряд проблем данного характера, требующие анализа и решения.
50. ivanov660 4330 26.01.23 12:00 Сейчас в теме
51. user738268 26.01.23 16:35 Сейчас в теме
52. пользователь 26.01.23 16:47
Сообщение было скрыто модератором.
...
54. triviumfan 92 30.01.23 20:39 Сейчас в теме
Интересная статья. И да, таких циклов по месяцам в современных конфигурациях предостаточно. Есть над чем подумать.
58. leongl 524 24.03.23 16:29 Сейчас в теме
Подскажите, а вы сбор планов не отключаете на PG? Каким инструментом пользуетесь для сбора планов? Оценивали влияние постоянного сбора планов на нагрузку сервера?
Оставьте свое сообщение