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

Публикация № 1794627 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.

 

 

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

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

 

 

 

 

Специальные предложения

Лучшие комментарии
18. m_aster 102 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, хочешь нарастить функционала, докупай соответствующий блок, как раньше было в семерке, купил БП и работаешь и горя не знаешь, нужен тебе склад, докупил склад. И проще и понятнее, и эффективнее обслуживать.
В принципе, оно и сейчас так есть, конечно, поставил УТ, поставил отдельно БП и синхронизируй между собой, правильно настрой и наблюдай за ними. Но если нужен еще какой-то функционал, больше, чем в УТ, взял бы КА или ЕРП, например, а там та же УТ и та же БП в составе, зачем? У меня уже есть и то и другое, живет и работает себе прекрасно и люди привыкли.
Автору огромное спасибо, очень интересно и познавательно, прочитал на одном дыхании.
kamisov; elena_veza; user1194361; xantif_2000; EliasShy; shu_vol; ivanov660; +7 Ответить
38. Gilev.Vyacheslav 1898 25.01.23 11:43 Сейчас в теме
всего бы этого не было если решения автоматом хотя бы раз в сутки проверяли документы старше ну пусть будет 20 лет и будущими годами, большинство таких ошибок носит характер 0023 год вместо 2023 года
sapervodichka; ivanov660; +2 Ответить
Остальные комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Nefilimus 71 24.01.23 11:32 Сейчас в теме
Кто-нибудь скиньте уже в 1С ссылку на значение слова "Оптимизация". С каждым релизом всё хуже и хуже...
2. tormozit 6756 24.01.23 12:27 Сейчас в теме
ВыполнитьКонтрольРезультатовПровдеения
Опечатка ?
3. ivanov660 3726 24.01.23 12:40 Сейчас в теме
4. tormozit 6756 24.01.23 13:21 Сейчас в теме
Было бы полезно иметь не только картинки, отображающие текст, но и их тексты натурально. Это позволит
- искать по ним
- копировать
- разглядеть в хорошо читаемом размере шрифта без необходимости открывать картинку в новом окне, о чем кстати многие не знают
karpik666; artbear; kser87; +3 Ответить
6. ivanov660 3726 24.01.23 14:15 Сейчас в теме
(4)Приложить файл запроса 10 000 и плана с 60 000 строк?
Или речь про контекст? Или про все вместе
8. starik-2005 2797 24.01.23 14:25 Сейчас в теме
(6) 70к знаков - на 7 статей хватит, т.е. на 70 $m)))
ogroup; Shmell; awk; BurlakovIvan; CherTolik_26rus; +5 Ответить
27. tormozit 6756 25.01.23 07:07 Сейчас в теме
(6) На картинках НЕ показаны 10к или 60к строк, а показаны некоторые фрагменты примерно по 50 строк. Вот их и хотелось бы в текстовом виде. Главное неудобство - на ужатых картинках трудно читать текст.
33. ivanov660 3726 25.01.23 10:05 Сейчас в теме
(27) В следующих статьях учту предложение.
5. Tonik_ 24.01.23 13:23 Сейчас в теме
Почитать расследование было интересно. Спасибо
SergeyTerentyev; ivanov660; +2 Ответить
7. starik-2005 2797 24.01.23 14:23 Сейчас в теме
У нас в базе есть документ фактически из следующего тысячелетия.
Прям вот так?
Вообще, в 1С таких костылей овер дофига. Как-то смотрел, как строится запрос по ДЗ/КЗ, так там тоже такой вот "бесконечный" цикл. И то, что там был мелкомягкий скуль, горю мало помогало.
40. siamagic 25.01.23 12:25 Сейчас в теме
9. tigrandis 296 24.01.23 14:30 Сейчас в теме
Сталкивался с этой проблемой в 2017 году в КА2 и думал давно исправили ...
10. kser87 2284 24.01.23 14:35 Сейчас в теме
Генерируемые программно запросы опасная штука. И выборки с неограниченным фактически периодом. Думаю, что в бюджетировании таких полно. Но там вряд-ли на общую производительность так влияет.
11. quazare 2708 24.01.23 16:44 Сейчас в теме
(10) УТ 11.5 почти вся сделана на подобных запросах
12. Shmell 454 24.01.23 17:23 Сейчас в теме
Сколько совокупно ушло времени на расследование проблемы? Это всегда забавно - когда незначительный косяк в пользовательских данных, который делается за 1 секунду - отнимает потом +-день на расследование ) Но зато, такие кейсы делают нас сильнее.
14. ivanov660 3726 24.01.23 17:47 Сейчас в теме
(12) Ориентировочно - в районе 1 часа. Если бы не отвлекали, то скорее всего быстрее.
sapervodichka; +1 Ответить
19. CheBurator 3079 24.01.23 22:41 Сейчас в теме
(12) прежде чем лазить в код - надо смотреть на явные косяки в базе на пользовательском уровне.
со времен клюшек два явных косяка с документами/регистрами - документы в начале времен и документы далеко в будущем. Это почти всегда "логическая" ошибка. Даже в код не надо лазить... В код уже лезть когда другое не помогает...
25. Shmell 454 25.01.23 05:47 Сейчас в теме
(19) А здесь вопрос - что быстрее найти: ошибку в данных в базе где работает овер 1000 пользователей (можно представить интенсивность ввода документов и справочников и вообще количество данных) или использовать инструментарий поиска проблем? Мое мнение - работа с инструментарием куда интереснее чем копание в данных. У такого подхода есть существенный плюс - между делом можно найти и другие потенциальные проблемы, которые можно зафиксировать в бэклог и потихонечку заняться их устранением.
28. CheBurator 3079 25.01.23 07:27 Сейчас в теме
(25) это да. но устранение технологических проблем редко ведет к устранению бардака в учете как такового. а документ от2099 года - ну явно в консерватории что-то не так...
d.snissarenko; Shmell; +2 Ответить
29. Shmell 454 25.01.23 07:28 Сейчас в теме
(28) все верно, нужен комплексный подход )
31. ivanov660 3726 25.01.23 09:30 Сейчас в теме
(19)
Без инструментария найти что-то практически не возможно. А тыкать пальцем в данные, на мой взгляд, все равно что играть в спортлото.
Проблемы часто встречаются в тех местах где их не ждешь. К тому же, для каждого случая должно быть объяснение причин и рекомендации по их устранению.
У нас есть методика по поиску и устранению проблем, в рамках нее мы и работаем.
13. tazhitkov 24.01.23 17:35 Сейчас в теме
А есчо с такими движениями, тормоза будут и не только от алгоритмов такого плана. Если более менее насыщеный регистр, там еще итогов стока наплодится. А если он еще не накопления а бухгалтерии, и без алгоритмов все колом встанет.
15. ivanov660 3726 24.01.23 17:58 Сейчас в теме
(13)Чем больше записей в регистре тем больше думает. Поэтому на демонстрационной базе замедление даже не почувствуется.
16. ildary 19 24.01.23 21:05 Сейчас в теме
Спасибо за автору за интересные подробности. Мне пришлось столкнуться с похожей проблемой, но там неверная дата была в прошлом - 215 год вместо 2015. Обнаружилось это из-за тормозов проведения складских документов, а причину нашли посмотрев размеры файлов регистров - и нашли раздувшийся (уже не помню его название), после чего запросом нашли проблемную дату и создавший эту дату документ.
ivanov660; +1 Ответить
17. kauksi 211 24.01.23 21:08 Сейчас в теме
А всего то, написать одну функцию, проверяющую параметры запроса (даже пусть собранный программно) на необычную дату...
18. m_aster 102 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, хочешь нарастить функционала, докупай соответствующий блок, как раньше было в семерке, купил БП и работаешь и горя не знаешь, нужен тебе склад, докупил склад. И проще и понятнее, и эффективнее обслуживать.
В принципе, оно и сейчас так есть, конечно, поставил УТ, поставил отдельно БП и синхронизируй между собой, правильно настрой и наблюдай за ними. Но если нужен еще какой-то функционал, больше, чем в УТ, взял бы КА или ЕРП, например, а там та же УТ и та же БП в составе, зачем? У меня уже есть и то и другое, живет и работает себе прекрасно и люди привыкли.
Автору огромное спасибо, очень интересно и познавательно, прочитал на одном дыхании.
kamisov; elena_veza; user1194361; xantif_2000; EliasShy; shu_vol; ivanov660; +7 Ответить
20. CheBurator 3079 24.01.23 22:46 Сейчас в теме
(18)
хочешь нарастить функционала, докупай соответствующий блок, как раньше было в семерке, купил БП и работаешь и горя не знаешь, нужен тебе склад, докупил склад. И проще и понятнее, и эффективнее обслуживать.

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

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

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

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

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

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

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

ну и кроме быстродействия, это еще ошибки в учете
в фирму 1С писать бесполезно, они всё только голованием теперь определяют )))
49. user738268 26.01.23 09:58 Сейчас в теме
Проведена интересная работа. Не хотите посотрудничать по данной теме? Есть ряд проблем данного характера, требующие анализа и решения.
50. ivanov660 3726 26.01.23 12:00 Сейчас в теме
51. user738268 26.01.23 16:35 Сейчас в теме
52. пользователь 26.01.23 16:47
Сообщение было скрыто модератором.
...
54. triviumfan 37 30.01.23 20:39 Сейчас в теме
Интересная статья. И да, таких циклов по месяцам в современных конфигурациях предостаточно. Есть над чем подумать.
Оставьте свое сообщение

См. также

Долго открывается конфигуратор Промо

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

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    47213    Gilev.Vyacheslav    1    

Избавиться от скана таблицы в плане запроса

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

Для запросов, содержащих "LIKE %СтрокаПоиска%". Справедливо для MS SQL и Postgres.

20.12.2022    2537    vasilev2015    31    

Концепция ORM как двигатель прогресса - выдержит ли ее ваша СУБД?

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

ORM (Object-Relational Mapping) используется во многих языках программирования, в том числе и в 1С. Однако реализация высоконагруженных решений приводит к мысли что разработчики ORM не учитывали ее влияния на производительность СУБД. Такая ситуация и в 1С, и ORM на Java, и наверняка в других ORM. Причины приоткрывает данная статья.

16.12.2022    966    1CUnlimited    5    

Нагрузочное тестирование в 1С:ERP

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

Для того чтобы еще до внедрения информационной системы убедиться, что целевая система справится с ожидаемой нагрузкой, требуется провести нагрузочное тестирование. О том какие инструменты и методики помогут организовать подобный проект при внедрении 1С:ERP, и о том, какие неожиданные факторы могут влиять на производительность системы я и хотел бы рассказать в данной статье.

02.11.2022    3046    Tavalik    23    

Видеодемонстрация применения Теста-центра для нагрузочного тестирования конфигураций Промо

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

Тест-центр – инструмент автоматизации многопользовательских нагрузочных испытаний информационных систем на платформе 1С:Предприятие 8. С его помощью можно моделировать работу предприятия без участия реальных пользователей, что позволяет оценивать применимость, производительность и масштабируемость информационной системы в реальных условиях. В видео показан пример с внедрением конфигурации Тест-центра в произвольную информационную базу и создание простого сценария нагрузочного теста.

16.09.2012    37283    Aleksey.Bochkov    29    

Партицированная дисциплина программиста в 1С

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

Почему при росте объемов базы 1С все становится медленней, даже если все индексы правильно сделаны? В статье на простом примере с регистром сведений показана причина и как этого избежать. Кто виноват больше, 1С или MS SQL решать Вам :)

20.09.2022    1648    1CUnlimited    2    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

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

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    71749    yuraos    112    

Быстрый фронт в базе размером 6.8 терабайт – наши стандарты при разработке и рефакторинге запросов

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

От быстродействия запросов, которые обращаются к крупным таблицам, напрямую зависит скорость работы всей базы в целом. Артем Кузнецов, тимлид команды 1С в компании ООО «Финтех решения» на конференции Infostart Event 2021 Moscow Premiere рассказал, как оптимизировать производительность при поддержке больших систем. Показал, на что следует обращать внимание при код-ревью запросов, как оптимизировать RLS, виртуальные таблицы, индексы и условия, и как доработка архитектуры решения может ускорить работу базы.

29.08.2022    5151    Chernazem    44    

Workaround me в 1С/MS SQL и не только, системный подход к созданию костылей

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

Workaround свидетельствует о невозможности решить проблему "правильным путем" и вызывает чувство стыда. Но практика показывает, что способность решать проблемы через workaround является порой единственным способом решить проблему в разумное время. А победителей, как говорят, не судят, так почему бы не создавать workaround по системе?

15.08.2022    1118    1CUnlimited    0    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

HighLoad оптимизация Платформа 1С v8.3 Платформа 1С v8.3 1С:Управление торговлей 10 1С:Управление торговлей 10 1С:Управление производственным предприятием 1С:Управление производственным предприятием Бесплатно (free) Бесплатно (free)

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

21.06.2013    60686    Антон Ширяев    117    

Ускорим проведение в 1С:Управление холдингом

HighLoad оптимизация Запросы Платформа 1С v8.3 Платформа 1С v8.3 1С:Управление холдингом 1С:Управление холдингом Бесплатно (free) Бесплатно (free)

В 1С:Управление холдингом есть "нехороший" запрос, который съедает значительную часть времени проведения документов. Если его подправить, то проведение заметно ускорится.

10.08.2022    4757    sapervodichka    60    

Миссия невыполнима. Общие реквизиты разделители против временных таблиц

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

Механизм общих реквизитов разделителей создает излишнюю\негативную нагрузку на структуру базы данных, но еще больше проблем доставляет при использовании временных таблиц.

05.08.2022    1524    1CUnlimited    0    

Методика похудения для 1С – 100%

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

Удаление архивных данных из базы - это непростая задача как для 1С, так и для любой базы данных. В статье изложены различные способы решения задачи, включая самый эффективный для 1С.

28.07.2022    5227    1CUnlimited    37    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

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

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    63119    Gilev.Vyacheslav    46    

Экспертный кейс. История расследования одного небыстрого закрытия месяца в 1C:ERP. Пример неочевидных путей расследования в виде детективной истории

HighLoad оптимизация Механизмы платформы 1С Запросы Платформа 1С v8.3 Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:ERP Управление предприятием 2 Бесплатно (free) Бесплатно (free)

В данной статье хотим рассказать об одном нашем непростом расследовании, в котором удалось собрать сразу несколько проблем на разных уровнях инфраструктуры заказчика и изначальной методологии ведения учета. Само расследование в какой-то момент стало напоминать детективную историю, с роялями в кустах, ошибками платформы, странным поведением пользователей и магическим поведением хорошо знакомых механизмов. Но мы реалисты, поэтому все проблемы были выявлены и устранены ;)

11.07.2022    5002    it-expertise    27    

Производительный режим работы RLS

HighLoad оптимизация Роли и права Платформа 1С v8.3 Платформа 1С v8.3 8.3.14 8.3.14 8.3.6 8.3.6 8.3.8 8.3.8 1С:ERP Управление предприятием 2 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х 1С:Комплексная автоматизация 2.х Бесплатно (free) Бесплатно (free)

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Каждый из режимов имеет свои преимущества и недостатки относительно другого. Основные из них будут рассмотрены в данном материале.

14.06.2022    5911    Neti    6    

Параллельные вычисления в 1С 8 Промо

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

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    38997    gallam99    19    

Любовь. Быстродействие. 1С

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

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

26.05.2022    3739    vasilev2015    20    

Оптимизация высоконагруженных конфигураций: история маленькой победы, или советы тем, кто столкнулся с проблемой впервые и не знает, что делать

HighLoad оптимизация Администрирование СУБД Платформа 1С v8.3 Платформа 1С v8.3 8.3.14 8.3.14 1С:ERP Управление предприятием 2 1С:ERP Управление предприятием 2 Россия Россия Бесплатно (free) Бесплатно (free)

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

24.05.2022    3788    avolsed    15    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

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

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    46090    madmpro    32    

Заметки эксперта. Расследование длительного выполнения отчета “Движение ТМЦ и затрат в производстве” (1С:ERP 2)

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

Кратко: в ходе проведения нагрузочного тестирования “1С:ERP 2” под ОС Linux на СУБД Postgres выявлено существенное замедление формирования отчета “Движение ТМЦ и затрат в производстве” - до 60 минут. После проведенного расследования и точечной корректировки СКД в отчете, без изменения бизнес-логики результатов его работы, работа отчета была ускорена в 80 раз - средний показатель формирования составил 30 секунд.

19.05.2022    2113    it-expertise    19    

Тестирование - игровое моделирование

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

Мы рассмотрим подход к тестированию с применением элементов искусственного интеллекта

25.04.2022    1395    ivanov660    0    

Несколько слов про платформенный механизм оптимизации RLS

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

Смотрим, как работает платформенный механизм оптимизации RLS, сравним поведение на разных СУБД MS SQL, Postgres 11,13,14.

07.04.2022    3506    ivanov660    23    

Почему после обновления Бухгалтерии в марте 2022 года отчеты стали такими медленными

HighLoad оптимизация Платформа 1С v8.3 Платформа 1С v8.3 Бухгалтерский учет Бухгалтерский учет 1С:Бухгалтерия 3.0 1С:Бухгалтерия 3.0 Бухгалтерский учет Бухгалтерский учет Бесплатно (free) Бесплатно (free)

Статья раскрывает причину, почему время формирования отчетов после обновления Бухгалтерии в марте 2022 сильно увеличилось. И рассказывает, как можно исправить ситуацию.

05.04.2022    4833    DBOdin_Lab    33    

Экспертный кейс. Расследование фатального замедления времени расчета себестоимости в 1С:ERP 2

HighLoad оптимизация Механизмы типовых конфигураций Запросы Платформа 1С v8.3 Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:ERP Управление предприятием 2 Бесплатно (free) Бесплатно (free)

При выполнении нагрузочного тестирования информационной системы на базе 1С:ERP для одного из клиентов с целью оценки возможности миграции системы на PostgreSQL и Astra Linux мы столкнулись с неприемлемым увеличением времени выполнения расчета себестоимости. Строго говоря, сценарий тестирования закрытия месяца не был выполнен вообще – он не укладывался в таймаут выполнения теста, 24 часа. По прошествии 18 часов всё ещё шло выполнение операции «Распределение затрат и расчет себестоимости». Более 16 часов выполнялся подэтап “Расчет партий и себестоимости. Этап. Расчет себестоимости: РассчитатьСтоимость”. Всё это время выполнялся запрос, который в текущей инфраструктуре клиента (СУБД MS SQL Server) выполняется чуть более 3 минут на аналогичных данных.

25.03.2022    5141    it-expertise    92    

Экспертный кейс. Расследование деградации производительности системы. Проведение документа “Поступление товаров и услуг” (1С:ERP 2)

Механизмы платформы 1С Запросы HighLoad оптимизация Платформа 1С v8.3 Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:ERP Управление предприятием 2 Бесплатно (free) Бесплатно (free)

В ходе проведения нагрузочного тестирования одним из наших клиентов была выявлена сильная деградация производительности системы в целом и, в частности, выполнения ключевой операции “Проведение документа поступление товаров и услуг” в течение выполнения теста. Согласно данным подсистемы БСП “Оценка производительности”, время выполнения ключевой операции “Проведение документа поступление товаров и услуг” возрастало в процессе тестирования с 15-20 секунд в начале тестирования до 150-200 секунд в его финале.

02.03.2022    3779    it-expertise    48    

Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками

HighLoad оптимизация Технологический журнал Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

Рассмотрим по шагам процесс обнаружения, анализа и решения проблемы производительности на примере базы ERP, сравним отличия в работе Postgres и MS SQL.

28.02.2022    11607    ivanov660    18    

Ускорение работы конфигуратора 1С с большими прикладными решениями

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

Ускорение работы 1С конфигуратора с большими прикладными решениями путем размещения системных каталогов 1С на RAM диске.

13.01.2022    6913    stg2005    105    

Ошибка производительности при проведении этапа 2.2 в ERP 2.4 и ERP 2.5

HighLoad оптимизация Платформа 1С v8.3 Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:ERP Управление предприятием 2 Россия Россия Бесплатно (free) Бесплатно (free)

Хочется поделиться одним подводным камнем, с которым могут встретиться другие пользователи ERP. Искал решение в интернете, но ничего похожего не нашел. Поэтому решил создать эту тему.

06.12.2021    1617    Rokky78    6    

Повышение производительности веб-сервисов. Переиспользование сеансов

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

Повышение производительности веб-сервисов. Переиспользование сеансов. Практическая реализация.

20.10.2021    4238    sorter1    2    

Оптимизация проведения документов списания партий в УПП 1.3

HighLoad оптимизация Платформа 1С v8.3 Платформа 1С v8.3 1С:Управление торговлей 10 1С:Управление торговлей 10 1С:Управление производственным предприятием 1С:Управление производственным предприятием Бесплатно (free) Бесплатно (free)

Почти в каждой конфигурации УПП 1.3 (возможно, и в УТ 10.3) есть медленный запрос, тормозящий проведение документа списания. Данная публикация раскрывает места вызова данного запроса и приводит пример оптимизации. Пример показывает результаты проведения документа «Реализация товаров и услуг», но метод работает и для других документов списания партий.

09.09.2021    1305    info1i    5    

Смотрим запросы 1С через Microsoft SQL Profiler по следам ошибок разработчиков, приводящих к проблемам производительности

HighLoad оптимизация Рефакторинг и качество кода Технологический журнал Платформа 1С v8.3 Платформа 1С v8.3 Бесплатно (free) Бесплатно (free)

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

07.09.2021    12432    ivanov660    26    

Адекватный параллелизм в 1С

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

Параллелизм ускоряет выполнение тяжелых регламентных операций на СУБД, но может негативно влиять на работу многопользовательских учетных систем. О том, как анализировать влияние параллелизма и настраивать его для MS SQL и PostgreSQL, рассказал ведущий разработчик компании ООО МКК «Ваш Инвестор» Вадим Фоминых.

13.08.2021    12469    Shmell    8    

Распространенные ошибки разработчиков, приводящие к проблемам производительности

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

Рассмотрим примеры ошибок, анализ, исправление и мероприятия по недопущению подобного в будущем. Всего будет 18 примеров.

02.08.2021    14981    ivanov660    77    

Решение проблем при настройке счетчиков производительности

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

Решение проблемы с заглавными буквами в power shell, поиск русского имени счетчика по английскому, и еще кое-что.

02.08.2021    1182    unichkin    4    

Parameter sniffing и генерация планов для разработчиков 1С

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

Особенности генерации планов запросов. Статья написана по мотивам вебинара Виктора Богачева.

01.06.2021    14602    vasilev2015    17    

Тонкости эксплуатации, плюшки и особенности Postgres Pro Enterprise

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

В ходе онлайн-встречи INFOSTART MEETUP Novosibirsk Руководитель ИТ из компании ИнфоСофт Антон Дорошкевич поделился с коллегами тонкостями и опытом работы с Postgresql для 1С. 

22.04.2021    7916    a.doroshkevich    6    

Решение нестандартных проблем производительности на реальных примерах

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

На екатеринбургском Infostart Meetup выступил с докладом архитектор ИС центра разработки ФТО Александр Криулин. Он поделился с коллегами кейсами нестандартных проблем производительности и рассказал о способах их решения.

24.03.2021    7416    AlexKriulin    37    

Соединение вложенными циклами

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

Nested loops и отсутствующие индексы. Статья написана по мотивам вебинара Виктора Богачева.

12.03.2021    4924    vasilev2015    22    

Долгое воспроизведение звука по RDP с удаленной машины

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

При воспроизведении короткого звука в 38 Кб, сигнализирующего об успешном сканировании, порою происходило подвисание примерно в 5 секунд.

09.02.2021    1660    pashamak    2    

Анализ блокировок СУБД: таблица изменений плана обмена 1С

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

Практический пример анализа типичной проблемы ожидания на блокировках СУБД, возникающих при использовании планов обмена 1С. Сервер СУБД: Microsoft SQL Server.

18.12.2020    5362    zhichkin    11