Экспертный взгляд на оптимизацию производительности на примере исправления и декомпозиции запроса

Публикация № 1696397 20.07.22

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

Подписаться

производительность оптимизация эксперт postgres

+82 –
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
Еще один интересный пример оптимизации производительности ERP. Описываем решение проблемы подробно по шагам.

В данной статье мы изложим некоторую примерную последовательность действий по выявлению проблемы производительности и ее поэтапному решению (с картинками и комментариями). Думаю, что будет особенно интересно новичкам, а также тем, кто планирует столкнуться с СУБД Postgres или уже ведет активную работу в этом направлении. 

Структура статьи:

  • Введение и постановка задачи
  • Ищем точку возникновения
  • Получаем исполняемый текст запроса
  • Подготавливаем исходный запрос в консоли запросов
  • Анализируем план исходного запроса
  • Оптимизация шаг 1. Исправление очевидной ошибки
  • Оптимизация шаг 2. Декомпозиция запроса
  • Заключение

 

Введение и постановка задачи

 

Для решения этой задачи нам понадобится:

  • конфигурация «Мониторинг производительности» - в ней будем оценивать количество событий, точки возникновения, собирать статистику онлайн;
  • доступ к целевой конфигурации ERP - в ней будем смотреть проблемный код и получать текущий запрос;
  • консоль запросов – моделирование, оптимизацию;
  • конвертер текстов SQL в представления 1С – преобразовывать нечитаемое представление в читаемое тестов и планов, создавать графическое представление плана запросов;
  • доступ к базе Postgres для проверки некоторых гипотез (опционально).

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

 

Исходная информация:

Проблема проявилась в документе установка цен номенклатуры у известных пользователей (есть ФИО) конфигурации ERP 2.4. Нам предстоит выявить проблему и исправить эту ситуацию. 
 

Что мы будем делать?

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

 

I) Ищем точку возникновения

 

Для того чтобы было удобно и просто искать места проблем, мы рекомендуем установить и настроить конфигурацию "Мониторинг производительности". Это удобно cделать на продуктовом  и на тестовом сервере. Если вы конечно не приверженец Old-school и любите работать в каком-нибудь парсере руками.

Т.к. у нас это уже настроено, то мы сразу посмотрим картинку из журнала длительных замеров. Поставим фильтр по длительности, пользователю или текстовому вхождению - это зависит от входящей информации по проблеме. В текущем случае будем фильтровать по вхождению «установка цен» в поле "context".

 

 

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

Давайте посмотрим где это происходит. Двойной клик по полю выделенной строки открывает отдельную вкладку с контекстом выполняемой операции.

 

 

Анализируем контекст:

  • Это процедура открытия документа "Установка цен номенклатуры". На это нам указывает команда "получить форму";
  • Это основная форма документа;
  • Проблема формируется запросом. Самая последняя позиция стека содержит команду "Запрос.Выполнить()";
  • Этот запрос похоже находится в модуле «УстановкаЦенСервер» - функция «ЗагрузитьТабличнуюЧастьТовары»;
  • Этот запрос расположен в строке «3907»;
  • Если мы посмотрим еще несколько записей журнала, то можем встретить вторую функцию «ЗагрузитьСтарыеЦеныНоменклатурыПредприятия», они имеют похожую структуру, но она выполняется обычно быстрее.

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

 

II) Получим исполняемый текст запроса

 

Чтобы получить искомый текст нам необходимо выполнить набор простых действий:

  • Открываем конфигурацию;
  • В дереве метаданных находим общий модуль «УстановкаЦенСервер» и открываем его;
  • Переходим в точку выполнения запроса - это позиция «3907».  Для быстрого перехода к позиции нажимаем сочетания «Ctrl»+«G».
  • В итоге мы должны оказаться в функции «ЗагрузитьТабличнуюЧастьТовары».

 

 

Где-то чуть выше должен находиться нужный нам текст запроса их два, но нам нужен тот что используется для продажи. На первый взгляд, он довольно простой:

 
 Исходный текст запроса

 

Что про него можно сказать:

  • Это пакет, и он состоит из двух частей;
  • В первой загружается таблица данных и формируется временная таблица;
  • А во втором выполнятся выборка с учетом этих входных данных;
  • Проблема находится во второй части пакета, т.к. текст SQL представления начинается с ключевого слова "SELECT", а не "INSERT";
  • В нем есть несколько интересных параметров - «ТекстЗапросаКоэффициентУпаковки1» и «ТекстЗапросаКоэффициентУпаковки2», которые подставляются в программном коде следующим образом:
 
 Программное преобразование запроса (подстановка значения параметров "ТекстЗапросаКоэффициентУпаковки")

 

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

  • Ставим точку останова в позиции «3907»;
  • Стартуем предприятие;
  • Открываем любой документ; 
  • Получаем текст запроса.

 

 

Соберитесь! Полный текст запроса приведен внутри свернутого спойлера. Если будете его смотреть, то делайте это аккуратно и без резких движений)

 
 Полный текст запроса

 

Что будем делать дальше? А дальше мы будем выполнять исходный запрос, чтобы посмотреть что-там такое происходит.

 

III) Подготавливаем исходный запрос в консоли запросов

 

Для продолжения работы нам необходима любая консоль запросов. Открываем ее и далее начинаем дорабатывать запрос. 

1) Создаем первый пакет и называем его "Исходный запрос". Далее мы будем копировать его с установленными параметрами для выполнения экспериментов.

 

 

2) Исправим первый запрос пакета, чтобы нам не требовалось подгружать таблицу данных. Некоторые консоли могут такого не уметь, да и набивать 3-4 тысячи строк это ужасное удовольствие. Для этого мы изменим одну строчку с выборкой из временной таблицы следующим образом:

 

 

3) Вставляем ключ "Key-12345" для быстрого поиска по логу запросов. Это изменение будет выглядеть следующим образом:

 
Добавляем ключ в текст запроса

 

ВЫБРАТЬ
	”Key-12345” КАК Ключ,
	ВременнаяТаблицаТовары.Индекс КАК Индекс,
	ВременнаяТаблицаТовары.Номенклатура КАК Номенклатура,
	ВременнаяТаблицаТовары.Характеристика КАК Характеристика,
	//....

 

 

4) Найдем подходящий документ среди всех документов установки цен. Для этого воспользуемся запросом получения списка документов с количеством позиций в табличной части:

 
 Текст запроса для подбора документа установки цен

Результат запроса примерно такой:

 

 

5) Выбираем документ с 4871 записью (это похоже наш пример из первого пункта, где искали точку возникновения) и устанавливаем параметр "Ссылка" в консоли запросов. 

6) Если у вас консоль долго рисует таблицу данных или вы решили взять документ с парой сотен тысяч строк, то разумно будет не выводить результат выполнения в таблицу или табличный документ (у некоторых консолей такой функционал присутствует, или доработайте самостоятельно).

7) Теперь мы можем выполнить исходный запрос и, выпив чашку кофе, продолжить процесс оптимизации.

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

 

IV) Смотрим и анализируем исходный план запросов.

 

Будем считать, что у вас уже настроено сохранение длительных планов запросов на Postgres как на продуктовом сервере, так и на тестовом. Если это не так, то срочно выполняем необходимые действия - подключить компоненту auto_explain (как это делается можно найти в интернете или кратко в статье "Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками").

Настроить сохранение планов запросов на продуктовом сервере следует сделать потому что:

  • не всегда легко удается повторить полностью поведение на тестовом сервере;
  • мы сразу можем начать анализировать проблему, пропуская задачу воспроизведения этой ситуации;

Давайте найдем текстовый план запроса и воспользуемся обработкой конвертации представлений SQL в 1С:

  • Открываем текстовый файл лога;
  • Находим наш текст запроса поиском по вхождению ключа "Key-12345";
  • Копируем текстовый план запроса;
  • Вставляем в конвертер;
  • Жмем последовательно кнопки "преобразовать" и "объяснить план запроса";
  • Открываем браузер и смотрим, что там такое.

 

 

Полученный план запроса можно посмотреть по ссылке: https://explain.tensor.ru/archive/explain/7922ca5d978f541c7d9dee619365c80e:0:2022-07-19#visio

Сначала обратим на правую часть схемы, в которой самый большой красный круг. Это самый тяжелый участок, на который тратится до 98% ресурсов.

 

 

На картинке ниже мы поясняем соответствие операторов их тексту запроса:

  • красным цветом показана временная таблица товаров;
  • фиолетовым - получение виртуальной таблицы срез последних на дату;
  • синим - фильтрация данных индекса по полям "Номенклатура" и "Характеристика"

 

 

Получается, что у нас проблема при получении данных из виртуальной таблицы среза последних регистра "Цены номенклатуры"! А почему? Потому что внутри виртуальной таблицы отсутствует необходимый отбор по измерению "ВидЦены". Мы должны максимально использовать любую возможную фильтрацию данных. Можно воспользоваться пояснениями от 1С: Типичные причины неоптимальной работы запросов и методы оптимизации

 

 

Мы готовы к первому шагу оптимизации!

 

V) Первый шаг оптимизации

 

В текущем запросе у нас с вами явная проблема - отсутствие в виртуальной таблице фильтра по измерению "ВидЦены". Давайте выполним исправление:

1) В консоли запросов копируем исходный запрос и переименовываем его в "Оптимизация 1" 

2) Исправляем текст запроса в соответствии с примером ниже. Подставим условие в виртуальную таблицу "СрезПоследних" регистра "Цены номенклатуры":

 
 Оптимизация запроса - первый этап

 

//...
ИЗ
	ВременнаяТаблицаТовары КАК ВременнаяТаблицаТовары
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(
				&Дата,
				(Номенклатура, ВидЦены, Характеристика) В
					(ВЫБРАТЬ
						ВременнаяТаблицаТовары.Номенклатура,
						ВременнаяТаблицаТовары.ВидЦены,
						ВременнаяТаблицаТовары.Характеристика
					ИЗ
						ВременнаяТаблицаТовары)) КАК ЦеныНоменклатуры
//...

 

2) Меняем текст ключа на "Key-optim-1"

3) Выполняем запрос и смотрим результаты. Результаты у нас впечатляющие, данный запрос выполнился быстрее чем за 5 с.

https://explain.tensor.ru/archive/explain/80e06f99ebef84b08293e1b0e61126ac:0:2022-07-15#visio

4) Давайте откроем план запроса и посмотрим что изменилось:

  • наша первая проблема исчезла, теперь на этот блок приходится всего 2% ресурсов;
  • появилось, точнее вышли на первый план, три старых блока сканирования таблицы регистра - 21%, оператор цикла (Nested Loop) 45% и оператор Materialize 13%.

 

Сделаем несколько выводов:

  • В описании блока Nested Loop мы видим что всего выбрано 4871 строк, но отброшено порядка 22 миллиона (RRbF - удаленные строки по фильтру). Похоже зря тратятся ресурсы. 
  • Так же мы видим кучу маленьких Index Scan примыкающих к основной оси схемы - это левые соединения с упаковками номенклатуры для получения коэффициентов, размеров и т.п. скрыто через две точки, которые 1С сама разворачивается в запросах SQL. Это то что скрывалось в «ТекстЗапросаКоэффициентУпаковки1» и «ТекстЗапросаКоэффициентУпаковки2».
  • Скан таблицы регистра (Seq Scan) конечно выглядит не очень здорово, но он выполняется всего один раз (Loop=1) и т.к. присутствует оператор hash join. 

Давайте попробуем ограничить трату ресурсов на эти прогоны. В системе с одним пользователем - это выглядит не существенно. Когда их количество увеличится, то вносимый вклад будет более значительным. Однако, давайте взглянем, как выглядит этот запрос, когда в табличной части будет в 10 раз больше товаров. План запроса: https://explain.tensor.ru/archive/explain/3e61a905418d4284e66f4bf71ea3323d:0:2022-07-19#visio

 

 

Мы видим что количество обрабатываемых строк в цикле превысило 11 миллиардов, а время от 2 секунд улетело куда-то в район нескольких тысяч (суммарно). И это при ~78 тысячах строк. Поэтому мы подходим к следующему этапу оптимизации.

P.S. В версии ERP 2.5 эта ошибка недостающего поля фильтра устранена и запрос работает приемлемо быстро.

 

VI) Второй шаг оптимизации

 

Все из той же статьи рекомендаций 1С можно вынести следующий совет по работе с виртуальными таблицами в соединениях. Мы выполним процедуру декомпозиции запроса или проще говоря - разобьем один сложный запрос на несколько простых.

Глаза боятся запроса, но консоль все сделает! Начинаем процесс второго этапа оптимизации:

  • Копируем в консоли запрос оптимизация 1 и называем его оптимизация 2;
  • Далее открываем конструктор и на вкладке "Пакет запросов" дублируем "Запрос пакета 2";
  • Активизируем запрос пакета 2;
  • Создаем из него временную таблицу с названием "ВтЦеныНоменклатуры";
  • На вкладке "Таблицы и поля" удаляем временную таблицу товаров, добавляем новые требуемые поля "Номенклатура,Характеристика,ВидЦены,Цена,Упаковка", меняем текст ключа на что-то в духе "Key-optim-part-1", а также индексируем по трем измерениям.
  • Последним шагом переключаемся на "Запрос 3" пакета запросов, меняем текст ключа на "Key-optim-part-2" и выполняем подмену виртуальной таблицы на временную "ВтЦеныНоменклатуры"
  • Готово преобразование.
  • Теперь мы выполняем запрос и смотрим его результаты.  
 
 Текст оптимизированного запроса монстра

 

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

 

 

Если мы посмотрим, то увидим что ушли блоки где гонялись лишние данные при соединении временной таблицы товаров и виртуальной цен номенклатуры (Nested Loop и Materialize). Это как раз то место, которое разбивает данный запрос на де части.

Остался только блок сканирования таблицы, чтобы избавиться от этого запроса нам надо попробовать переписать запрос срез последних, но этого уже мы делать не будем. Желающие могут попробовать самостоятельно выполнить эту операцию.

 

Заключение

 

Были обнаружены и исправлены:

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

В результате решения задачи мы смогли уменьшить время выполнения запроса системы в ~300-400 раз, а в некоторых случаях улучшение достигает невероятных ~1000 пунктов).

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

Совет: Будьте в тренде, следуйте простым рекомендациям (не ленитесь) и Вы ожидаемо получите хорошие результаты. 

 

Ссылки от автора по вопросам оптимизации производительности

+82 –

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. quazare 3211 20.07.22 18:19 Сейчас в теме
Я правильно понял, что в типовом запросе не было виртуальных проиндексированных таблиц и отсутствовал одно соединение по фильтру вид цены?

Ну тогда, вероятно в запросе нужно сделать уничтожение виртуальных таблиц после их использования?
+ – Ответить
3. ivanov660 3892 20.07.22 21:57 Сейчас в теме
(1)
1. Да относительно фильтра "ВидЦены". Типовой запрос приведен в спойлере "Исходный текст запроса" и в нем отсутствует в условии фильтра поле "ВидЦены", есть только "Характеристика" и "Номенклатура", а этого не достаточно для оптимальной работы.
2. Не понял что такое виртуальная проиндексированная таблица. Попробую ответить так: мы разбили запрос на две части и в первой создали временную таблицу фактически для того чтобы "упростить жизнь" планировщику запросов. Postgre в отличии от MS SQL не такой "умный" и работает хуже. На СУБД MSSQL такой деградации производительности из-за отсутствия фильтра внутри виртуальной таблицы не происходит. Можно проверить этот факт самостоятельно.
3. Обычно удаление временных таблиц необходимо делать, когда в пакете будет использоваться таблица с таким же именем. В остальных случаях платформа подчищает хвосты самостоятельно.
ardn; +1 – Ответить
2. gzharkoj 471 20.07.22 21:39 Сейчас в теме
Нарушены два требования 1с:
1. Все отборы,которые могут установлены виртуальных таблицах должны находится в параметрах виртуальной таблицы. В запросе отбор по Виду цены находился в левом соединении, а не в виртуальной таблице
2. Не использовать соединения с подзапросами, рекомендация сформировать отдельную временную таблицу. По факту запрос к виртуальной таблице СрезПоследних цен развернется в подзапрос, поля соединения не будут проиндексированы у подзапроса. В целом так можно делать, когда количество результирующих строк виртуальной таблицы не много, до 1к, на больших данных будут просадки, что автор и показал с ~5к позициями товаров.
Дмитрий74Чел; quazare; ardn; ivanov660; +4 –1 Ответить
10. nicxxx 250 21.07.22 11:21 Сейчас в теме
(2)
2. Не использовать соединения с подзапросами, рекомендация сформировать отдельную временную таблицу.

Перейти на MSSQL, там это проблема решена :)
+ – Ответить
11. ivanov660 3892 21.07.22 11:24 Сейчас в теме
(10)
1. Не совсем так, подобную проблему вы можете словить и в этой СУБД. Она "умнее" да, но не везде и всегда.
2. Официально купить MS SQL на текущий момент вроде нет возможности для российских компаний.
+ – Ответить
4. VSvintsov1 21.07.22 05:03 Сейчас в теме
автор предлагает повторить это тестирование на стандартных конфигурациях. - верно ли я понял , что авторство запроса с конструкцией: 
.....
ИЗ
	ВременнаяТаблицаТовары КАК ВременнаяТаблицаТовары
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(
....


принадлежит разработчикам типовых конфигураций ?
+ – Ответить
5. ivanov660 3892 21.07.22 08:58 Сейчас в теме
(4) Да, и в этом нет ничего не обычного.
Дмитрий74Чел; +1 – Ответить
6. cdiamond 228 21.07.22 09:03 Сейчас в теме
(4) Видимо так. Но однозначно говорят что это криминал только вроде на курсе специалиста по платформе. На курсе по эксперту уже с оговорками и условиями ) Всё зависит от объема данных в тех или иных таблицах - здесь же очевидно авторы конфигурации не рассчитывали что номенклатуры будут десятки тысяч и на все будут устанавливать цены. В целом таких непредусмотренных ситуаций в ERP 2.4 довольно много и это отличное поле для оптимизаторов. Есть еще другая сторона вопроса - злоупотребление временными таблицами, в котором 1С является чемпионом в нашей галактике, очевидно что загонять миллионы строк во временную таблицу тоже решение так себе, за которое нужно платить большими объемами оперативной и твердотельной памяти.
Созинов; +1 – Ответить
8. ivanov660 3892 21.07.22 09:44 Сейчас в теме
(6)
1. Предположение что в продуктовой базе компании, которая будет использовать ERP, номенклатуры будет не более чем в демонстрационной базе - это, на мой взгляд, не профессиональный подход. ERP позиционируется как конфигурация для больших компаний.
2. Если в ситуации, когда нет выбора, то использовать или не использовать временную таблицу, решается практически как в данной статье. Думаю, что миллион строк при возможности работы за 3 с - это лучшее решение, чем виртуальная таблица и 1 час на открытие каждого документа (если вы так переживаете за время жизни жесткого диска, то можете сделать RAM диск под tmp файлы). С другой стороны чтобы избежать этого можно заставлять пользователя делать 100 документов для установки цен, но такой подход - это курам на смех.
papami; +1 – Ответить
12. TMV 14 21.07.22 23:06 Сейчас в теме
(8) Бывают ли у вас документы с количеством строк записей в наборе по какому-либо регистру более 100 тысяч?
+ – Ответить
9. ivanov660 3892 21.07.22 09:55 Сейчас в теме
(6) В некоторое ближайшее время, мы планируем выложим обработку, которая позволит из демонстрационной базы в относительно "сжатые сроки", сделать нормальную базу для проверки ее работы при больших объемах данных. Пока мы ее тестируем и проверяем свои задачи, но за 2-е суток удалось создать оптимальное число, законченных цепочек.
Вот тут и можно будет развернуться для проверок тех или иных списков и запросов, идей.
Прикрепленные файлы:
Дмитрий74Чел; Созинов; CAV; +3 – Ответить
17. Дмитрий74Чел 226 28.07.22 16:51 Сейчас в теме
(9) Шикарно!
+ – Ответить
7. Serg O. 209 21.07.22 09:38 Сейчас в теме
Спасибо, статья как всегда очень круто оформлена.
Максимально подробно и с красивыми картинками.
Огромный +
Sejix; Jimbo; user1559729; ubnkfl; ardn; ivanov660; +6 – Ответить
13. TMV 14 21.07.22 23:09 Сейчас в теме
(0) Имеет ли значение порядок в секции Индексировать в запросе формирования временной таблицы? В регистре сведений порядок измерений другой.
+ – Ответить
15. ivanov660 3892 22.07.22 08:45 Сейчас в теме
(13)Главный критерий - это наличие всех полей использующихся в соединениях.
TMV; +1 – Ответить
14. TMV 14 21.07.22 23:12 Сейчас в теме
Остался только блок сканирования таблицы, чтобы избавиться от этого запроса нам надо попробовать переписать запрос срез последних, но этого уже мы делать не будем
Насколько помню, эта тема очень спорная - вам удалось переписать срез последних, вообще на практике используете?
+ – Ответить
16. ivanov660 3892 22.07.22 09:10 Сейчас в теме
(14)А почему спорная? В других системах учета нет никаких виртуальных таблиц и все делается руками. На сколько я помню коллеги говорили, что использование виртуальных таблиц упрощает сам запрос и позволяет не забыть включить служебные поля типа "Активность".
Сам запрос виртуальной таблицы можно переписать, к примеру так: 
ВЫБРАТЬ
	Т.Номенклатура КАК Номенклатура,
	Т.ВидЦены КАК ВидЦены,
	Т.Характеристика КАК Характеристика,
	Т.Цена КАК Цена,
	Т.Упаковка КАК Упаковка
ИЗ
	(ВЫБРАТЬ
		МАКСИМУМ(Ц.Период) КАК Период,
		Ц.Номенклатура КАК Номенклатура,
		Ц.Характеристика КАК Характеристика,
		Ц.ВидЦены КАК ВидЦены
	ИЗ
		РегистрСведений.ЦеныНоменклатуры КАК Ц
	ГДЕ
		Ц.Активность = ИСТИНА
		И Ц.Период < &Период
	
	СГРУППИРОВАТЬ ПО
		Ц.Номенклатура,
		Ц.Характеристика,
		Ц.ВидЦены) КАК ВнТ
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК Т
		ПО (Т.Номенклатура = ВнТ.Номенклатура)
			И (Т.Характеристика = ВнТ.Характеристика)
			И (Т.ВидЦены = ВнТ.ВидЦены)
			И (Т.Период = ВнТ.Период)
ГДЕ
	Т.Активность = ИСТИНА
Показать

Если это будет более оптимальный вариант, то почему же не использовать? Да, иногда мы вместо виртуальных таблиц мы используем работу с физическими таблицами.
+ – Ответить
Оставьте свое сообщение

См. также

Подсистема 1С "Визуальные инструменты АФРОДИТА" (Панель показателей и виджетов)

Работа с интерфейсом Рабочее место Мониторинг Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Платные (руб)

Создайте свою панель показателей и виджетов в любой конфигурации 1С с помощью подсистемы 1С "Визуальные инструменты АФРОДИТА". Дашборды на начальном экране изменят ваш подход к интерфейсу и рабочему месту.

10800 руб.

20.03.2023    6909    6    17    

24

Контроль расхода памяти сервера 1С:Предприятие 8

Мониторинг Платформа 1С v8.3 Россия Платные (руб)

Обработка позволяет использовать подобные КОРП-функциональности механизмы контроля расхода памяти (сеансом на 1 вызов и рабочими процессами), реагируя завершением "тяжелых" вызовов, перезапуском рабочих процессов при чрезмерном потреблении этого важного ресурса.

3600 руб.

03.05.2023    2692    2    0    

2

Конфигурация Session Monitor

Мониторинг Инструменты администратора БД Платформа 1С v8.3 Россия Платные (руб)

Конфигурация Session Monitor предназначена для мониторинга сервера 1С с целью отслеживания чрезмерной нагрузки от конкретных сеансов и скорости реакции рабочих процессов.

1500 руб.

01.12.2020    11081    23    0    

36

Как я мониторинг разворачивал

Мониторинг Россия Абонемент ($m)

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

1 стартмани

10.05.2023    6714    andreysidor4uk    37    

127

Все консоли запросов для 1С

Запросы Бесплатно (free)

Список всех популярных обработок.

17.03.2023    11523    kuzyara    66    

115

1С и Postgres: первый серьезный опыт борьбы и противостояния, постигаем open source

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

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

27.02.2023    7977    shakun_dg    30    

107

Практическая шпаргалка по новым возможностям языка запросов 1С

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

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

21.11.2022    16523    quazare    34    

113

Утилита тестирования сервера 1С от HADGEHOGs

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

Программа для тестирования вашей инфраструктуры 1С. Анализ ключевых параметров оборудования и ПО серверов 1С и MS SQL, поиск ошибок в базах 1С на стороне MS SQL, тестирование производительности серверов MS SQL и 1С, обмен результатами замеров с сообществом, построение отчета.

21.09.2022    13392    1021    Hadgehogs    56    

132

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

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

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

29.08.2022    6448    Chernazem    44    

109

10 «заповедей» эксплуатации крупной информационной системы 1С

Управление ИТ-подразделением Внедрение ИТ-системы HighLoad оптимизация Бесплатно (free)

Крупные системы 1С давно уже перешагнули и десятки терабайт, и тысячи пользователей, но во многих случаях подход к эксплуатации таких систем остаётся не на должном уровне. Антон Дорошкевич на конференции Infostart Event 2021 Post-Apocalypse поделился более чем 10-ти летним опытом эксплуатации подобных систем, сведя его к 10 «заповедям», соблюдение которых сделает 1С надёжнее, а труд разработчика – благодарнее и благороднее.

11.07.2022    7965    a.doroshkevich    33    

86

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

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

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

14.06.2022    9374    Neti    7    

97

Исправляем проблемы производительности в конфигурации ERP - 7 примеров

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

Злободневные примеры поиска и исправления проблемных мест в конфигурациях ERP/УТ/КА на СУБД Postgres.

23.05.2022    6248    ivanov660    25    

92

Нагрузочное тестирование 5000+ пользователей онлайн — играем в игру

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

Тестируем ERP под Postgre SQL. Альтернативный нагрузочный тест.

16.05.2022    7821    ivanov660    56    

85

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

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

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

28.02.2022    13677    ivanov660    18    

147

Конвертер для преобразования текстов запросов и планов SQL в представления языка 1С

Инструментарий разработчика Запросы Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Преобразует текст запроса на языке SQL или план запроса, подставляя представления метаданных конфигурации для удобства последующего анализа.

2 стартмани

07.02.2022    10629    127    ivanov660    7    

90

Привилегированные отчеты

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

Расширение позволяет настроить для пользователей выполнение отчетов в привилегированном режиме. 1) Убирает тормоза формирования отчета, возникающие при наложении прав пользователя на запросы отчета; 2) Позволяет обойти ошибки формирования отчета из-за отсутствия прав на часть объектов у пользователя.

4 стартмани

24.01.2022    11308    27    sapervodichka    36    

102

Готовые механизмы 1С: ЗУП, представления

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

Здесь будет храниться архив запросов, которые могут помочь разработчику правильно строить отчеты и получать данные в 1С: ЗУП. Статью буду периодически дополнять.

03.11.2021    7864    Margo462    19    

92

Изыскания на тему записи в регистр сведений

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

Уважаемые коллеги, здравствуйте! Сегодня хочу поделиться с Вами своими изысканиями на тему записи в регистр сведений в контексте оптимизации одной операции. Однажды мы столкнулись со следующей проблемой: поступили жалобы от разработчиков сайта, что наш веб-сервис очень медленно реагирует, точней, обработка запроса не укладывается в таймаут 5 секунд, и сайт получает ошибку 500. Стали разбираться, и вот что выяснили.

1 стартмани

21.09.2021    14087    0    METAL    57    

104

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

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

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

07.09.2021    15871    ivanov660    26    

170

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

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

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

02.08.2021    16590    ivanov660    77    

142

Поиск причин блокировок СУБД

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

Расследование блокировок СУБД. Статья написана по мотивам вебинара Виктора Богачева.

28.04.2021    8531    vasilev2015    14    

84

Рецепты приготовления технологического журнала

Технологический журнал Бесплатно (free)

Понимание принципов событий технологического журнала позволяет решать многие проблемы производительности и стабильности работы платформы 1С. О том, как взаимосвязаны события технологического журнала и как с их помощью можно анализировать серверные вызовы 1С, на INFOSTART MEETUP Ekaterinburg.Online рассказал программист 1С из компании ДНС-Ритейл Максим Старков.

22.03.2021    24208    max_st    9    

171

Последний раз про срез последних (на каждую дату в запросе)

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

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

15.02.2021    37527    randomus    47    

155

Водопад из Техжурнала 1С

Технологический журнал Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Строим визуализацию в виде waterfall-графика по данным событий технологического журнала.

5 стартмани

23.12.2020    6518    VKislitsin    5    

91

Аналог PIVOT в запросе 1С (как выполнить транспонирование таблицы в запросе 1С)

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

В статье показывается простой метод реализации аналога оператора PIVOT в запросе 1С без использования соединений.

12.12.2020    9031    Eugen-S    25    

71

Контекст всегда важен. История проблем производительности

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

Небольшая история о проблемах производительности из-за нехватки процессорных мощностей. А также описание основных показателей работы CPU.

26.11.2020    10211    Infostart    21    

133

Итоги по объединенной совокупности группировок в запросе

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

Способ формирования итогов в запросе по совокупности группировок, объединенных в единый набор, при помощи функции АВТОНОМЕРЗАПИСИ.

18.11.2020    12656    antonivan    21    

100

Cбор и анализ ошибок при помощи Sentry, или как упростить жизнь себе и пользователям

Мониторинг Платформа 1С v8.3 Абонемент ($m)

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

1 стартмани

09.10.2020    14869    hexhoc    14    

96

Отладчик запроса 1С 8.3 (управляемые формы)

Инструментарий разработчика Запросы Платформа 1С v8.3 Управляемые формы Запросы Конфигурации 1cv8 Абонемент ($m)

По просьбам некоторых своих коллег и пользователей Инфостарта, выкладываю первую версию обработки "Отладчик запросов by Акулов А.С.", переделанной под управляемые формы. Реализованы почти все возможности из отладчика запросов, которые присутствовали в версии под обычные формы, а также добавлено немного нового.

1 стартмани

28.09.2020    19609    177    DrAku1a    31    

113

Описание почти всех событий технологического журнала

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

Краткое описание событий технологического журнала с примерами. Все для быстрого старта.

19.08.2020    56783    Infostart    41    

481

Проводим по БУ "на лету"

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

В базе ERP и КА есть форма тестировщика, которая автоматически получает из конфигурации полные тексты запросов формирования бухгалтерских проводок выбранного документа, даёт возможность модифицировать запрос и сразу проверить результат.

01.05.2020    9622    sapervodichka    1    

94

Эти занимательные временные таблицы

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

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    27438    Infostart    0    

191

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

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

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    18585    informa1555    35    

150

Анализ взаимоблокировок

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

Скрипт Bash, который выводит полную информацию взаимоблокировок по технологическому журналу. Не имеет аналогов в отечественных публикациях.

20.03.2020    9453    vasilev2015    41    

88

Подготовка и сдача на сертификат 1С:Эксперт по технологическим вопросам. Мой опыт

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

Через тернии к звездам...

12.03.2020    11564    buganov    32    

118

Нечёткий поиск "ПОДОБНО". Нюансы

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

Заметки о "ПОДОБНО" в языке запросов

23.02.2020    64271    Yashazz    34    

121

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

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

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    22505    Evil Beaver    14    

145

Держи данные в тепле, транзакции в холоде, а VACUUM в голоде

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

Чтобы база работала быстро – в ней нужен порядок. Это касается как MS SQL, так и PostgreSQL. Как настроить базу, чтобы в ней поддерживался порядок, какие регламентные операции нужно проводить, чтобы данные чистились, индексы перестраивались и оперативная память высвобождалась в своём выступлении на конференции Infostart Event 2019 Inception поделился руководитель ИТ в компании «ИнфоСофт» Антон Дорошкевич. 

07.02.2020    33120    a.doroshkevich    24    

168

[Шпаргалка] Запрос остатков по LIFO FIFO партиям приобретения поступления товаров

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

Запросом получаем остатки по партиям LIFO или FIFO.

31.01.2020    10850    rpgshnik    15    

87

Оптимизатор запроса. Часть первая

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

Работа оптимизатора запроса является ключевой для обработки данных. Знание того, как оптимизатор выстраивает свою стратегию, отлично помогает при построении запросов.

23.12.2019    14187    darkdan77    21    

91