Загрузка файла XML большого объема. Очень долго
Имеется 1С:БП 3.0, работает в режиме клиент-сервер.
СУБД PostgresSQL.
СУБД и сервер 1С установлена одном сервере-ПК. Диски на сервере SSD, ОЗУ - 128ГБ.
Платформа 8.3.20.1710 с разрядностью х64.
Мы осуществляем загрузку данных в 1С:БП файла XML размером примерно 32Гб.
Обмен производится через типовую обработку "Универсальный обмен данными в формате XML"
В файле находятся данные с документами и их движения. Никаких сложных алгоритмов загрузки не производится.
Файл выгрузки сформирован с помощью правил обмена данными написанными на КД 2.0.
Файл выгрузки загружается в 1С:БП порядка 30часов.
Саму загрузку производим непосредственно на сервере-ПК.
Нагрузки на сервер-ПК при этом никакой фактически нет: ни на диски, ни на процессор (5-7% нагрузки), ни на ОЗУ (50% свободно).
Подскажите, есть ли какие-либо рекомендации по решению вопроса ускорения загрузки файлов большого объема. Смена средств обмена не предлагается.
Спасибо.
СУБД PostgresSQL.
СУБД и сервер 1С установлена одном сервере-ПК. Диски на сервере SSD, ОЗУ - 128ГБ.
Платформа 8.3.20.1710 с разрядностью х64.
Мы осуществляем загрузку данных в 1С:БП файла XML размером примерно 32Гб.
Обмен производится через типовую обработку "Универсальный обмен данными в формате XML"
В файле находятся данные с документами и их движения. Никаких сложных алгоритмов загрузки не производится.
Файл выгрузки сформирован с помощью правил обмена данными написанными на КД 2.0.
Файл выгрузки загружается в 1С:БП порядка 30часов.
Саму загрузку производим непосредственно на сервере-ПК.
Нагрузки на сервер-ПК при этом никакой фактически нет: ни на диски, ни на процессор (5-7% нагрузки), ни на ОЗУ (50% свободно).
Подскажите, есть ли какие-либо рекомендации по решению вопроса ускорения загрузки файлов большого объема. Смена средств обмена не предлагается.
Спасибо.
Ответы
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(10) несколько интересных инструкций:
под SSD нужно ещё параметр = стоимости рандомного обращения выставить равным стоимости последовательного обращения к диску. об этом во втором файле указано
под SSD нужно ещё параметр = стоимости рандомного обращения выставить равным стоимости последовательного обращения к диску. об этом во втором файле указано
Прикрепленные файлы:
Измененные настройки в postgresql.conf 2018.10.01 ТЕХКОМПЛЕКТ .xlsx
Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз.pdf
Настройка PostgreSQL под Linux.pdf
(1)
Коллеги, изменение параметров Postgres, копирование файлов на RAM-диск (баз данных, самого Postgres, так и файлов загрузки) и т.д., не дало положительных результатов увеличения производительности.
Файл порядка 460Мб грузится 40минут, в нем находятся только элементы Справочников, порядка 294000 элементов.
Начал смотреть программный код по анализу замера производительности, это привело к большому объему по времени (порядка 25минут) по записи объекта элементов справочников:
но анализ не дал никакого результата:
- в модуле объекта события записи стандартно указано
- в самой обработке Универсального обмена также стоит галка "Загружать данные в режиме обмена", а также "Оптимизированная запись объектов"
- версионирование (БСП) для объектов не включено
- история данных платформенная также не используется
- подписок на события нет
Куда можно еще копать на стороне 1С и/или Postgre?
Спасибо.
Коллеги, изменение параметров Postgres, копирование файлов на RAM-диск (баз данных, самого Postgres, так и файлов загрузки) и т.д., не дало положительных результатов увеличения производительности.
Файл порядка 460Мб грузится 40минут, в нем находятся только элементы Справочников, порядка 294000 элементов.
Начал смотреть программный код по анализу замера производительности, это привело к большому объему по времени (порядка 25минут) по записи объекта элементов справочников:
Объект.Записать();но анализ не дал никакого результата:
- в модуле объекта события записи стандартно указано
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;- в самой обработке Универсального обмена также стоит галка "Загружать данные в режиме обмена", а также "Оптимизированная запись объектов"
- версионирование (БСП) для объектов не включено
- история данных платформенная также не используется
- подписок на события нет
Куда можно еще копать на стороне 1С и/или Postgre?
Спасибо.
рекомендаций по файлу - нет,
загрузка файлов от КД2 очень медленная операция,
как правило такие большие объемы не грузят, обычно используют в обменах,
а зачем еще движения грузите, создавайте одни документы а затем проводите (хотя тоже все не быстро будет)
еще есть вариант соединяться по СОМ соединению и напрямую в базе приемника создавать документы
ну и для самых продвинутых, получите структуру таблиц СУБД и ее средствами грузите подготовленные данные
(вот на примере СКЛ загрузка нескольких Гигов происходит за несколько минут)
загрузка файлов от КД2 очень медленная операция,
как правило такие большие объемы не грузят, обычно используют в обменах,
а зачем еще движения грузите, создавайте одни документы а затем проводите (хотя тоже все не быстро будет)
еще есть вариант соединяться по СОМ соединению и напрямую в базе приемника создавать документы
ну и для самых продвинутых, получите структуру таблиц СУБД и ее средствами грузите подготовленные данные
(вот на примере СКЛ загрузка нескольких Гигов происходит за несколько минут)
Получается, что это проблема сугубо платформенная 1С и надо менять саму методику выгрузки/загрузки.
Нет возможности поменять схему в короткие сроки.
А вот поменять что-то на сервере есть. Имеется ввиду настройки аппаратной части и/или ПО сервера, 1С.
Нет возможности поменять схему в короткие сроки.
А вот поменять что-то на сервере есть. Имеется ввиду настройки аппаратной части и/или ПО сервера, 1С.
(3)
2. Если включена - запустите замер производительности.
3. Посмотрите, что занимает основное время.
4. Если это запись объектов, то там есть возможность подкрутить настройки. Ищите инфу или попросите кого-нить, кто в этом понимает, помочь вам.
5. Начните делать бэкап базы минимум раз в день. А то я сколько народу видел, у которых что-то сломалось и они это неделями восстанавливали, потом плевали и ручками со старого древнего бэкапа весь учет вводили. Особенно когда постгрес на винде развернут.
ЗЫ: также есть проблемы и с самой 1С. Например, снижение производительности в ряде кейсов с течением времени. Это требует обновить платформу. Т.е. если первые 100 записей записались за 100 сек, а последние записи уже требуют по минуте, то есть куда задуматься.
А вот поменять что-то на сервере есть.
1. Посмотрите, включена ли на сервере отладка.
2. Если включена - запустите замер производительности.
3. Посмотрите, что занимает основное время.
4. Если это запись объектов, то там есть возможность подкрутить настройки. Ищите инфу или попросите кого-нить, кто в этом понимает, помочь вам.
5. Начните делать бэкап базы минимум раз в день. А то я сколько народу видел, у которых что-то сломалось и они это неделями восстанавливали, потом плевали и ручками со старого древнего бэкапа весь учет вводили. Особенно когда постгрес на винде развернут.
ЗЫ: также есть проблемы и с самой 1С. Например, снижение производительности в ряде кейсов с течением времени. Это требует обновить платформу. Т.е. если первые 100 записей записались за 100 сек, а последние записи уже требуют по минуте, то есть куда задуматься.
(4)
Задача разовая и хотелось найти быстрое решение...но покопавшись в деталях понял, что на это надо больше времени для понимания "как это устроено", чего сейчас позволить не могу...
Про 4 пункт понял, буду на это обращать внимание в будущем
По платформе - "свежак" стоит - 8.3.20)))
Задача разовая и хотелось найти быстрое решение...но покопавшись в деталях понял, что на это надо больше времени для понимания "как это устроено", чего сейчас позволить не могу...
Про 4 пункт понял, буду на это обращать внимание в будущем
По платформе - "свежак" стоит - 8.3.20)))
Большие объемы - всегда долго прогружаются.
Мы когда 7 баз УПП объединяли в одну большую 320Гб платформа не вытягивала такие объемы, падала.
Мы фиксировали выгруженные данные в РС, затем довыгружали следующие порции.
Уменьшить объем никак нельзя?
Состав документов загружаемых в части оптимизации кода загрузки есть вариант рассмотреть?
Мы когда 7 баз УПП объединяли в одну большую 320Гб платформа не вытягивала такие объемы, падала.
Мы фиксировали выгруженные данные в РС, затем довыгружали следующие порции.
Уменьшить объем никак нельзя?
Состав документов загружаемых в части оптимизации кода загрузки есть вариант рассмотреть?
Как вариант - перед загрузкой: запретите выполнение фоновых заданий у целевой базы; (а лучше у всех баз на сервере) Затем сделайте рестарт служб; Еще на всякий случай - отключите соединение с интернетом (с внешним миром)
Пробуйте загружать; Не забудьте вернуть фоновые задания и включить интернет.
Пробуйте загружать; Не забудьте вернуть фоновые задания и включить интернет.
Неоднократно, возникала подобная ситуация, добивался результата разрезанием файла. Писал сам обработку, при помощи которой резал, но необходимо знать какие узлы содержаться. Уверен, что можно сделать какой-то универсальный алгоритм. В моем случае, данные были однотипные.
(31) Пытаюсь сделать так:
1. Сначала выгружаются справочники
2. После идет выгрузка РС и т.д.
так вот есть проблема: не получается при выгрузке данных РС выгружать только ссылку на реквизит РС, выгрузка идет полностью реквизита и дальше перезапись объекта при Загрузке в приемнике.
Что делал: в ПКС реквизита писал "ВыгрузитьТолькоСсылку = Истина;"
т.е. я хотел бы при выгрузке РС не загружать справочник заново(или перезаписывать его), т.к. он уже ранее был выгружен
1. Сначала выгружаются справочники
2. После идет выгрузка РС и т.д.
так вот есть проблема: не получается при выгрузке данных РС выгружать только ссылку на реквизит РС, выгрузка идет полностью реквизита и дальше перезапись объекта при Загрузке в приемнике.
Что делал: в ПКС реквизита писал "ВыгрузитьТолькоСсылку = Истина;"
т.е. я хотел бы при выгрузке РС не загружать справочник заново(или перезаписывать его), т.к. он уже ранее был выгружен
(33)В ПКО регистра "не выгружать объекты по ссылкам"/"выгружать только ссылку", только нужно быть уверенным, что при записи в БД используется именно переданная из источника ссылка, а не присваивается новая, как любят это делать 1С в типовых конфигурациях, не редко просто так.
Всем привет.
Доработкой правил обмен данными получилось сократить время загрузки с 40 до 15минут.
Анализ производительности показывал большое время на запись объектов.
По документам и регистрам: реквизиты ссылочного типа не выгружаем полностью, а только их ссылки.
Дальше будем пробовать ставить параллельно СУБД MS SQL и тестировать скорость загрузки на нем, возможно и тут будет ускорение.
Доработкой правил обмен данными получилось сократить время загрузки с 40 до 15минут.
Анализ производительности показывал большое время на запись объектов.
По документам и регистрам: реквизиты ссылочного типа не выгружаем полностью, а только их ссылки.
Дальше будем пробовать ставить параллельно СУБД MS SQL и тестировать скорость загрузки на нем, возможно и тут будет ускорение.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот