Скорость выполнения отчета в самописной базе очень низкая
Внимание! Тема закрыта. Добавлять сообщения в закрытую тему запрещено.
Добрый день, коллеги! У нас есть самописная база на основе БСП с одним документом типа "Документ" и с одним регистром "Регистр 1") типа "Регистр остатков". У регистра измерение1, Измерения2 и ресурс Количество. Измерения - это Справочник 1 и Справочник 2. В базе около 2 млн записей по "Регистру 1"
Делаю отчет на СКД - в запросе виртуальная таблица - отбор на параметры внутри виртуальной таблицы, в качестве полей получаю Справочник.Наименование.
Отчет за год без отборов первый раз строится 12 минут, следом запускаешь - зависает на 1,5 часа, если подождать 3-5 минут то отчет формируется за 12 минут. Опытным путем замечено, когда rphost сдувается до 0, тогда отчет формируется 12 минут.
Мы спустились до платформы 8.3.14.1694 чтобы сделать настройки сервера 1с до ограничений 9 сентября 2019 года
Вопрос: как ускорить формирование отчета до 30 секунд. Количество выводимых записей может достигать 10 000
Делаю отчет на СКД - в запросе виртуальная таблица - отбор на параметры внутри виртуальной таблицы, в качестве полей получаю Справочник.Наименование.
Отчет за год без отборов первый раз строится 12 минут, следом запускаешь - зависает на 1,5 часа, если подождать 3-5 минут то отчет формируется за 12 минут. Опытным путем замечено, когда rphost сдувается до 0, тогда отчет формируется 12 минут.
Мы спустились до платформы 8.3.14.1694 чтобы сделать настройки сервера 1с до ограничений 9 сентября 2019 года
Вопрос: как ускорить формирование отчета до 30 секунд. Количество выводимых записей может достигать 10 000
Прикрепленные файлы:
По теме из базы знаний
Найденные решения
На самом деле можно и довести выполнение до 30 секунд или и меньше. 2 млн строк - это при правильной организации данных ни о чем. По сути сделать мини OLAP куб. Или иначе создать сущность данных, содержащую в виде нужных срезов готовые агрегированные данные. И из нее тащить отборами по индексам в СКД. А так на пальцах получается серверы получая данные помещают их в оперативную память бездушно выжырая ее. И когда следует очередной вызов запроса за небольшое время происходит утечка памяти и свопинг на диск. А это очень медленная операция. О чем и говорит картинка. Если делаем запрос, через время - сервер уже сам отпустил кеш. И еще "Вангую" - 1С сервер 32 битный. И возможно сервера развернуты на виртуалках.
В общем нужно смотреть на ситуацию в комплексе. Для начала все мониторить начиная с поведения железа (примитивные метрики ресурсов сервера память, диск (инпут/оутпут) ) - проц седается редко. Ну и какие запросы сыпятся на скуль. Прочие рекомендации по оптимизации уже сказаны в обсуждении выше. А вообще - задача выглядит как тест на собеседовании.
В общем нужно смотреть на ситуацию в комплексе. Для начала все мониторить начиная с поведения железа (примитивные метрики ресурсов сервера память, диск (инпут/оутпут) ) - проц седается редко. Ну и какие запросы сыпятся на скуль. Прочие рекомендации по оптимизации уже сказаны в обсуждении выше. А вообще - задача выглядит как тест на собеседовании.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
больного ни базы, ни отчета... вы большой оптимист!
Можно попробовать произнести волшебное заклинание "Сим-салабим-ахалай-махалай!" 24 раза (12/0,5), а если не поможет... искать другое заклинание! ;)
У нас есть самописная база на основе БСП с одним документом типа "Документ" и с одним регистром "Регистр 1") типа "Регистр остатков". У регистра измерение1, Измерения2 и ресурс Количество. Измерения - это Справочник 1 и Справочник 2. В базе около 2 млн записей по "Регистру 1"
Делаю отчет на СКД - в запросе виртуальная таблица - отбор на параметры внутри виртуальной таблицы, в качестве полей получаю Справочник.Наименование.
Хорошее словесное описание фотографии больного, проблем с выбором лечения возникнуть не должно. :)
Делаю отчет на СКД - в запросе виртуальная таблица - отбор на параметры внутри виртуальной таблицы, в качестве полей получаю Справочник.Наименование.
Вопрос: как ускорить формирование отчета до 30 секунд.
С 12 минут (в лучшем случае) до 30 секунд? Не видя Можно попробовать произнести волшебное заклинание "Сим-салабим-ахалай-махалай!" 24 раза (12/0,5), а если не поможет... искать другое заклинание! ;)
(1)
Вот и корень проблемы. Виртуальная таблица "Обороты" в РН с видом регистра "Остатки" не использует таблицу итогов оборотов и все данные получает из таблицы "Движения".
Нужно переделывать РН в вид "Обороты".
Да и подозреваю, что сам регистр никогда не сводится, а только накапливается.
У нас есть самописная база на основе БСП с одним документом типа "Документ" и с одним регистром "Регистр 1") типа "Регистр остатков".
Вот и корень проблемы. Виртуальная таблица "Обороты" в РН с видом регистра "Остатки" не использует таблицу итогов оборотов и все данные получает из таблицы "Движения".
Нужно переделывать РН в вид "Обороты".
Да и подозреваю, что сам регистр никогда не сводится, а только накапливается.
Без самого запроса и структуры базы достаточно сложно что-то сказать. 2 млн записей - это не так и много. 12 минут - это скорее всего говорит или о том, что индексы в запросе не используются, или о том, что СУБД не обслуживается.
Если более подробно расскажете, то вполне можно помочь выяснить направление.
Ну и очевидный совет - через ТиИ запустите реструктуризацию таблиц, обновите статистику, дефрагментируйте индексы.
Если более подробно расскажете, то вполне можно помочь выяснить направление.
Ну и очевидный совет - через ТиИ запустите реструктуризацию таблиц, обновите статистику, дефрагментируйте индексы.
(7) Очевидные вещи делали через SQL
Ниже текст запроса отчета
Ниже текст запроса отчета
ВЫБРАТЬ
ПродажиОбороты.Продавец КАК Продавец,
ПродажиОбороты.Покупатель КАК Покупатель,
ПродажиОбороты.Номенклатура КАК Номенклатура,
СУММА(ПродажиОбороты.КоличествоОборот) КАК Количество,
ПродажиОбороты.Период КАК Период,
СУММА(ПродажиОбороты.Цена * ПродажиОбороты.КоличествоОборот) КАК Стоимость,
СУММА(ПродажиОбороты.ОбъемПродукцииОборот) КАК ОбъемПродукцииОборот
ПОМЕСТИТЬ ВТ_СредниеЦены
ИЗ
РегистрНакопления.Продажи.Обороты(, , Месяц, ) КАК ПродажиОбороты
СГРУППИРОВАТЬ ПО
ПродажиОбороты.Продавец,
ПродажиОбороты.Покупатель,
ПродажиОбороты.Номенклатура,
ПродажиОбороты.Период
;
//////////////////////////////////////////////////////////// Показать
(13)
1. А зачем тут временная таблица?
2. А зачем тут агрегация?
3. Период в данном случае - это секунда. В чем смысл за секунду собирать данные? Если бы это был целый месяц, тогда смысл бы имела и агрегация (типа "НАЧАЛОПЕРИОДА(Период, МЕСЯЦ) КАК Период") - это существенно сократило бы количество значений в выборке и временная таблица могла бы тут быть полезной (да и то вряд ли, ибо она дальше на 100% вся целиком используется. Я так понимаю, что Вы потом это все еще раз сворачиваете в СКД, из-за этого действительно все может долго работать, ибо вытягивает из базы 2кк записей, соединяет их с номенклатурой и контрагентами, бесмысленно агрегирует, а потом еще раз все усредняет в СКД (но могу и ошибиться тут с периодом, если он указан как "Месяц" - надо смотреть, но если и так, то агрегация тут не нужна).
4. В данном случае разыменоывание (обращение через точку) не должно снижать производительность, но только в том случае, если в покупателе, продавце и номенклатуре не любая ссылка, а только контрагенты и товары.
1. А зачем тут временная таблица?
2. А зачем тут агрегация?
3. Период в данном случае - это секунда. В чем смысл за секунду собирать данные? Если бы это был целый месяц, тогда смысл бы имела и агрегация (типа "НАЧАЛОПЕРИОДА(Период, МЕСЯЦ) КАК Период") - это существенно сократило бы количество значений в выборке и временная таблица могла бы тут быть полезной (да и то вряд ли, ибо она дальше на 100% вся целиком используется. Я так понимаю, что Вы потом это все еще раз сворачиваете в СКД, из-за этого действительно все может долго работать, ибо вытягивает из базы 2кк записей, соединяет их с номенклатурой и контрагентами, бесмысленно агрегирует, а потом еще раз все усредняет в СКД (но могу и ошибиться тут с периодом, если он указан как "Месяц" - надо смотреть, но если и так, то агрегация тут не нужна).
4. В данном случае разыменоывание (обращение через точку) не должно снижать производительность, но только в том случае, если в покупателе, продавце и номенклатуре не любая ссылка, а только контрагенты и товары.
(19)
1. Временная таблица нужна, чтобы на втором проходе посчитать средневзвешенную цену, в связи с этим агрегация исопользуется
Ниже код расчета цены по данным временной таблицы
2. Период -это месяц, см скрин в приложении.
1. Временная таблица нужна, чтобы на втором проходе посчитать средневзвешенную цену, в связи с этим агрегация исопользуется
Ниже код расчета цены по данным временной таблицы
ВЫБОР
КОГДА ПродажиОбороты.Количество = 0
ТОГДА 0
ИНАЧЕ ПродажиОбороты.Стоимость / ПродажиОбороты.Количество
КОНЕЦ2. Период -это месяц, см скрин в приложении.
Прикрепленные файлы:
Двойка за точки, выбирай данные через точку ранее, и через соединение, а не в результирующей выборке. В этом случае скуль делает свои дополнительные запросы и соединения и часто не оптимальные. это для затравки
ПродажиОбороты.Покупатель.ИНН КАК ПокупательИНН,
ПродажиОбороты.Покупатель.Регион КАК Регион,
ПродажиОбороты.Покупатель.Родитель КАК КаналПродаж,
ПродажиОбороты.Продавец.ИНН КАК ПродавецИНН,
ПродажиОбороты.Покупатель.Наименование КАК _Покупатель,
ПродажиОбороты.Номенклатура.Сорт КАК Сорт
СУММА(ПродажиОбороты.Цена * ПродажиОбороты.КоличествоОборот) КАК Стоимость, - существует вероятность деления на ноль, это все таки оборотная таблица.
Самописная база, да? Цену лучше сделать не измерением, а ресурсом, ну это так имхо =)
ПродажиОбороты.Покупатель.ИНН КАК ПокупательИНН,
ПродажиОбороты.Покупатель.Регион КАК Регион,
ПродажиОбороты.Покупатель.Родитель КАК КаналПродаж,
ПродажиОбороты.Продавец.ИНН КАК ПродавецИНН,
ПродажиОбороты.Покупатель.Наименование КАК _Покупатель,
ПродажиОбороты.Номенклатура.Сорт КАК Сорт
СУММА(ПродажиОбороты.Цена * ПродажиОбороты.КоличествоОборот) КАК Стоимость, - существует вероятность деления на ноль, это все таки оборотная таблица.
Самописная база, да? Цену лучше сделать не измерением, а ресурсом, ну это так имхо =)
(17) Отчет после изменений за год сфомировался за 25 минут, это ни о чем не говорит, изменения по точка не дали ожидаемого результата. Вероятность деления на ноль будет только в том случае, если есть знак деления в запросе и нет проверки на ноль количество. В моем запросе есть проверка:
ВЫБОР
КОГДА ПродажиОбороты.Количество = 0
ТОГДА 0
ИНАЧЕ ПродажиОбороты.Стоимость / ПродажиОбороты.Количество
КОНЕЦ
ВЫБОР
КОГДА ПродажиОбороты.Количество = 0
ТОГДА 0
ИНАЧЕ ПродажиОбороты.Стоимость / ПродажиОбороты.Количество
КОНЕЦ
(29) все, пора в отпуск - *, принял за "/". Мой косяк, но тем не менее, если есть выборка через точку, то лучше делать соединение к профильным таблицам.
Выбрать
Регистр.покупатель,
Регистр.продавец,
Регистр.товар,
спрТовар.Качество
Из
Регистр как Регистр
Левое Соединение спрТовары Как спрТовар
По Регистр.Товар = спрТовар.Ссылка
Показать
Этот запрос в консоли сколько выполняется?
ВЫБРАТЬ
ПродажиОбороты.Продавец КАК Продавец,
ПродажиОбороты.Покупатель КАК Покупатель,
ПродажиОбороты.Номенклатура КАК Номенклатура,
СУММА(ПродажиОбороты.КоличествоОборот) КАК Количество,
ПродажиОбороты.Период КАК Период,
СУММА(ПродажиОбороты.Цена * ПродажиОбороты.КоличествоОборот) КАК Стоимость,
СУММА(ПродажиОбороты.ОбъемПродукцииОборот) КАК ОбъемПродукцииОборот
ИЗ
РегистрНакопления.Продажи.Обороты(, , Месяц, ) КАК ПродажиОбороты
СГРУППИРОВАТЬ ПО
ПродажиОбороты.Продавец,
ПродажиОбороты.Покупатель,
ПродажиОбороты.Номенклатура,
ПродажиОбороты.Период Показать
(20) Ваш запрос уже 10 минут висит в консоли запросов
ВЫБРАТЬ
ПродажиОбороты.Продавец КАК Продавец,
ПродажиОбороты.Покупатель КАК Покупатель,
ПродажиОбороты.Номенклатура КАК Номенклатура,
СУММА(ПродажиОбороты.КоличествоОборот) КАК Количество,
ПродажиОбороты.Период КАК Период,
СУММА(ПродажиОбороты.Цена * ПродажиОбороты.КоличествоОборот) КАК Стоимость,
СУММА(ПродажиОбороты.ОбъемПродукцииОборот) КАК ОбъемПродукцииОборот
ИЗ
РегистрНакопления.Продажи.Обороты(, , Месяц, ) КАК ПродажиОбороты
СГРУППИРОВАТЬ ПО
ПродажиОбороты.Продавец,
ПродажиОбороты.Покупатель,
ПродажиОбороты.Номенклатура,
ПродажиОбороты.Период
ПоказатьПродажиОбороты.Продавец КАК Продавец,
ПродажиОбороты.Покупатель КАК Покупатель,
ПродажиОбороты.Номенклатура КАК Номенклатура,
СУММА(ПродажиОбороты.КоличествоОборот) КАК Количество,
ПродажиОбороты.Период КАК Период,
СУММА(ПродажиОбороты.Цена * ПродажиОбороты.КоличествоОборот) КАК Стоимость,
СУММА(ПродажиОбороты.ОбъемПродукцииОборот) КАК ОбъемПродукцииОборот
ИЗ
РегистрНакопления.Продажи.Обороты(, , Месяц, ) КАК ПродажиОбороты
СГРУППИРОВАТЬ ПО
ПродажиОбороты.Продавец,
ПродажиОбороты.Покупатель,
ПродажиОбороты.Номенклатура,
ПродажиОбороты.Период
(17) Запрос изменил, выполнение висит уже более 10 минут- отбор 1 год.
(23)
ВЫБРАТЬ
ПродажиОбороты.Продавец КАК Продавец,
ПродажиОбороты.Покупатель КАК Покупатель,
ПродажиОбороты.Номенклатура КАК Номенклатура,
СУММА(ПродажиОбороты.КоличествоОборот) КАК Количество,
ПродажиОбороты.Период КАК Период,
СУММА(ПродажиОбороты.Цена * ПродажиОбороты.КоличествоОборот) КАК Стоимость,
СУММА(ПродажиОбороты.ОбъемПродукцииОборот) КАК ОбъемПродукцииОборот,
ПродажиОбороты.Покупатель.ИНН КАК ПокупательИНН,
ПродажиОбороты.Покупатель.Регион КАК ПокупательРегион,
ПродажиОбороты.Покупатель.Родитель КАК ПокупательРодитель,
ПродажиОбороты.Продавец.ИНН КАК ПродавецИНН,
ПродажиОбороты.Покупатель.Наименование КАК ПокупательНаименование,
ПродажиОбороты.Номенклатура.Сорт КАК НоменклатураСорт
ПОМЕСТИТЬ ВТ_СредниеЦены
ИЗ
РегистрНакопления.Продажи.Обороты(, , Месяц, ) КАК ПродажиОбороты
СГРУППИРОВАТЬ ПО
ПродажиОбороты.Продавец,
ПродажиОбороты.Покупатель,
ПродажиОбороты.Номенклатура,
ПродажиОбороты.Период
;
//////////////////////////////////////////////////////////// Показать(23)
(25) Я про то, что в результате может получиться большой объем данных. Если выполнять в консоли, основное время тратится на вывод результата. А если поля ссылочного типа, так еще и на получение представлений для них.
Кстати, каково количество записей в результате запроса?
Кстати, каково количество записей в результате запроса?
(3) у нас версия 1С 1С:Предприятие 8.3 (8.3.16.1148)
(37) Это не ускоряет отчет. Помогает сокращение количество выводимых группировок, например без номенклатуры и контрагентов отчет формируется до 30 секунд, как только добавляем группировки - время значительно увеличивается. получается у 1С слабый участок на вывод большого массива информации в табличный вид.
(37) Это не ускоряет отчет. Помогает сокращение количество выводимых группировок, например без номенклатуры и контрагентов отчет формируется до 30 секунд, как только добавляем группировки - время значительно увеличивается. получается у 1С слабый участок на вывод большого массива информации в табличный вид.
А что мешает в SQL Profiler ситуацию проанализировать. Сразу станет понятней.
Кстати - СКД та еще "штучка" , особенно в умелых руках пользователей бездумно добавляющих отборы и группировки. По этому для "тяжелых" запросов лучше лучше контролировать процесс формирования запроса самому и только результат пихать в СКД, для постобработки и отображения .
Кстати - СКД та еще "штучка" , особенно в умелых руках пользователей бездумно добавляющих отборы и группировки. По этому для "тяжелых" запросов лучше лучше контролировать процесс формирования запроса самому и только результат пихать в СКД, для постобработки и отображения .
На самом деле можно и довести выполнение до 30 секунд или и меньше. 2 млн строк - это при правильной организации данных ни о чем. По сути сделать мини OLAP куб. Или иначе создать сущность данных, содержащую в виде нужных срезов готовые агрегированные данные. И из нее тащить отборами по индексам в СКД. А так на пальцах получается серверы получая данные помещают их в оперативную память бездушно выжырая ее. И когда следует очередной вызов запроса за небольшое время происходит утечка памяти и свопинг на диск. А это очень медленная операция. О чем и говорит картинка. Если делаем запрос, через время - сервер уже сам отпустил кеш. И еще "Вангую" - 1С сервер 32 битный. И возможно сервера развернуты на виртуалках.
В общем нужно смотреть на ситуацию в комплексе. Для начала все мониторить начиная с поведения железа (примитивные метрики ресурсов сервера память, диск (инпут/оутпут) ) - проц седается редко. Ну и какие запросы сыпятся на скуль. Прочие рекомендации по оптимизации уже сказаны в обсуждении выше. А вообще - задача выглядит как тест на собеседовании.
В общем нужно смотреть на ситуацию в комплексе. Для начала все мониторить начиная с поведения железа (примитивные метрики ресурсов сервера память, диск (инпут/оутпут) ) - проц седается редко. Ну и какие запросы сыпятся на скуль. Прочие рекомендации по оптимизации уже сказаны в обсуждении выше. А вообще - задача выглядит как тест на собеседовании.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот