Ошибка загрузки большого архива 1Cv8.dt в PostgresSQL на платформе 1С 8.3.19

14.10.22

База данных - Администрирование СУБД

1С для платформы 8.3.19 ускорили загрузку dt-файлов за счет разбивки на несколько фоновых заданий. В итоге словили ошибку блокировки при загрузке в СУБД PostgresSQL большого 1cv8.dt-файла размером 25 Gb "ERROR: canceling statement due to lock timeout". Напишу, как в итоге загрузили этот dt-файл.

Проблемная ситуация (предыстория):

Получили новый железный сервер: СУБД PostgreSql-13.4-6.1C x64 + Сервер 1С 8.3.19.1467 х64. Нужно было перенести базы со старого сервера (там была СУБД MS SQL + 1C 8.3.16.1876). Базы переносили через dt-файлы. При загрузке dt-файлов небольшого размера до 3 Gb проблем не проявилось. Но когда решили переносить базу 1С:УПП, у которой dt-файл был размером 25 Gb, то не смогли его загрузить. По логу PostgresSQL стали анализировать ошибки. Меняли конфигурационные файлы Postgres'а, где пробовали отлючать/включать/изменять всё что знали (знаем не всё) или нашли на профессиональных форумам. Перезапускали сервис postgres'a, пробовали загрузку снова и снова, но всё равно натыкались на ошибку:

 

 

Ошибка загрузки информационной базы. В информационную базу загружены не все данные
по причине:
Конфликт блокировок при выполнении транзакции:
55P03: ERROR:  canceling statement due to lock timeout
CONTEXT:  COPY _accrgat21396, line 7000

При загрузке то таблиц субконто, то таблиц с бухгалтерскими итогами, на разных строках вылетала ошибка и загрузка dt-файла прерывалась.

Примечание: Большую часть решений по ошибкам в логах и настройках Postgres'а вы сможете найти на форумах и тут на Инфостарте (все действия, которые мы делали я тут не привожу подробно, т.к. статья не руководство по настройке и установке, а разбор конкретной проблемы с платформой 1С 8.3.19).

В итоге большее время заняли 2 ошибки: 

  • LOG: Could not rename temporary statistics file "pg_stat_tmp/global.tmp" to "pg_stat_tmp/global.stat": Permission denied - как оказалось, являлась ошибкой установленного релиза PostgreSql-13.4-6.1C_x64, которая потребовала переустановки другого релиза PostgresPro_13.5.1_64bit_Setup. Переустановили, ошибка ушла, сама она описана на форумах, решается либо патчами либо установкой подходящего релиза PostgresPro.
< 2022-01-27 21:53:59.443 MSK >LOG:  starting PostgreSQL 13.4, compiled by Visual C++ build 1800, 64-bit
< 2022-01-27 21:53:59.445 MSK >LOG:  listening on IPv4 address "0.0.0.0", port 5432
< 2022-01-27 21:53:59.575 MSK >LOG:  database system was shut down at 2022-01-27 21:53:50 MSK
< 2022-01-27 21:53:59.594 MSK >LOG:  database system is ready to accept connections
< 2022-01-27 22:04:14.761 MSK >LOG:  could not rename temporary statistics file "pg_stat_tmp/global.tmp" to "pg_stat_tmp/global.stat": Permission denied
  • ERROR:  canceling statement due to lock timeout - основная ошибка блокировки, которую многократными манипуляциями с переконфигурированием Postgres'а нам не удавалось решить.
< 2022-01-28 18:41:29.405 MSK >СООБЩЕНИЕ:  запускается PostgreSQL 13.5, compiled by Visual C++ build 1925, 64-bit
< 2022-01-28 18:41:29.408 MSK >СООБЩЕНИЕ:  для приёма подключений по адресу IPv4 "0.0.0.0" открыт порт 5432
< 2022-01-28 18:41:29.561 MSK >СООБЩЕНИЕ:  система БД была выключена: 2022-01-28 18:41:24 MSK
< 2022-01-28 18:41:29.581 MSK >СООБЩЕНИЕ:  система БД готова принимать подключения
< 2022-01-28 18:54:48.036 MSK >ERROR:  canceling statement due to lock timeout
< 2022-01-28 18:54:48.036 MSK >CONTEXT:  COPY _accrg1375, line 1000

Стали копать в 1С:Платформу....

прочитали, что в новых особенностях платформы 8.3.19 есть:

Ускорена загрузка из .dt-файла в клиент-серверном варианте информационной базы за счет использования для загрузки нескольких фоновых заданий. Для получения существенного ускорения желательно, чтобы кластер серверов и СУБД располагались на одном компьютере или чтобы кластер серверов и СУБД были связаны каналом с высокой пропускной способностью (1 Гбайт/с и выше).

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

Для команды пакетного запуска конфигуратора /RestoreIB реализован параметр -JobsCount, позволяющий управлять количеством используемых фоновых заданий.

 

 

Запустили конфигурацию с нужным ключом, для загрузки принудительно в одном потоке

/RestoreIB "C:\MK_HOLD_12_01_2022.dt" -JobsCount 1

 

 

 

Успех!!! dt-файл 25 Gb развернулся в базу 300 Gb .... А товарищ, резюмировал: "Опять привет от 1С, перемудрили"... 

Коллеги, надеюсь, эта статья обратит ваше внимание на новую особенность регулирования потоков загрузки dt-файлов 1С в нескольких потоках, где-то это может и вам пригодиться. 

Спасибо, коллеге, STRAV.

 
 Другие публикации автора

Ссылка на компетенции по 1С:ERP - команда со знаниями, умениями и успешными проектами.

ERROR: canceling statement due to lock timeout Postgres ошибка

См. также

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

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

вчера в 08:00    216    artly2000    6    

3

Администрирование СУБД Системный администратор Программист

В крупных компаниях, где много типовых и сильно доработанных баз с режимом работы 24/7, переход с MS SQL на PostgreSQL затягивается. Получается гетерогенная структура – когда прод уже на PostgreSQL, а разработка и тестирование – пока на MS SQL. О том, какие варианты помогут постепенно перевести прод с несколькими базами MS SQL на PostgreSQL, не сломав среду тестирования и разработки, пойдет речь в статье.

21.11.2024    3197    a.doroshkevich    7    

15

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

Мы исследуем проблему долгого выполнения запросов PostgreSQL при использовании конструкции VALUES: когда она возникает, как на нее можно повлиять, а главное, почему ее продуманная отработка важна для более быстрого функционирования решений на базе 1С

12.11.2024    1092    Tantor    20    

15

HighLoad оптимизация Администрирование СУБД Механизмы платформы 1С Программист Платформа 1С v8.3 ИТ-компания Россия Бесплатно (free)

В данной статье мы рассмотрим, как работает механизм временных таблиц на postgres на платформе 8.3.23 и что изменилось в нем при добавлении новых возможностей в платформе 8.3.25. А также на примере покажу, как понимание работы платформы позволяет оптимизировать СУБД для работы с 1С.

29.10.2024    3708    Tantor    38    

35

Администрирование СУБД Системный администратор Программист Бесплатно (free)

CDC - очень мощный механизм, который можно использовать во многих сценариях, возможность развернуть его в Docker показывает простоту и лёгкость данной технологии.

08.10.2024    922    AlexSvoykin    1    

7

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

Анализ и решение ошибок СУБД. Во время реиндексации базы Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Не удалось найти объект "ИмяБазы.dbo._RefSInf21806", так как он не существует, или отсутствуют разрешения. Во время проверки целостности Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Недопустимое имя объекта "dbo._RefSInf21806".

19.09.2024    4823    Xershi    10    

17

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

Бэкап в Postgres состоит из набора граблей, которые нужно обойти для успешного восстановления. Они заложены в самых неожиданных местах от предмета резервного копирования (база или кластер) до структуры каталогов. Один неверный шаг и восстановление будет невозможным. Почему нельзя было сделать проще, как в MS SQL или Oracle? Почему бэкап в Postgres оставляет впечатление чьей-то лабораторной работы? Статья адресована прежде всего специалистам 1С, избалованным комфортом в MS SQL, в суровых буднях импортозамещения на Postgres.

13.08.2024    3134    1CUnlimited    9    

5
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. frkbvfnjh 805 30.01.22 11:49 Сейчас в теме
Блииин, спасибо! Я бы даже не знал куда рыть. Обязательно напишите об этом в багтрекер, иначе скоро, я так полагаю, загрузить архив в 1С будет что то из разряда плясок с бубнами.
baracuda; cleaner_it; mrChOP93; criptid; marsohod; +5 Ответить
17. NoRazum 29 31.01.22 11:43 Сейчас в теме
(1) у 1С вроде написано что DT не гарантирует обратную загрузку.
Пользуйтесь еще другими средствами.

1С она такая.
31. пользователь 01.02.22 08:58
Сообщение было скрыто модератором.
...
2. zhuravlev_as 437 30.01.22 13:51 Сейчас в теме
3. quazare 3835 30.01.22 14:26 Сейчас в теме
я так понимаю, что на платформе ниже 19-ой проблемы бы не было. и еще - а вам не кажется, что дт-шник 25 гб для базы в 300 большеват? тем более для старенькой УПП?????
4. sapervodichka 6918 30.01.22 14:37 Сейчас в теме
(3)
я так понимаю, что на платформе ниже 19-ой проблемы бы не было
- наверное, судя по справке загрузка архива в нескольких потоках появилась в 8.3.19, но на сервере кроме УПП 1.3 еще требовалась база 1С:Управление холдингом, релиза 3.1.15.4 предназначенная для использования с версией технологической платформы 1С:Предприятие 8 не ниже 8.3.19.1467, поэтому ниже платформу не могли поставить.
что дт-шник 25 гб для базы в 300 большеват
- до загрузки на диске было 1.62 Тб свободно, после загрузки стало 1.33 Тб, может немного поменьше 300 Гб
5. sapervodichka 6918 30.01.22 15:23 Сейчас в теме
(4) да, уточню, что база УПП клиентская, поэтому как она жила и чем разрасталась до такого размера не могу сказать, наша задача сейчас на проекте с УПП 1.3 перейти на Управление холдингом 3.1.
6. ivanov660 4583 30.01.22 19:42 Сейчас в теме
(5) А что там с быстродействием на постгре (по моему опыту все печально)? Народу много в базе? Данных судя по всему там порядочно, т.ч. если заказчик был на мелкософте, от будет неприятно удивлен.
7. starik-2005 3091 30.01.22 20:39 Сейчас в теме
(6)
по моему опыту все печально
Разный опыт. Что-то быстрее даже, что-то медленнее. Ну и крутить надо хотя бы pg_tune + на 13+ вырубить JIT-компиляцию (реально помогает).
9. ivanov660 4583 30.01.22 21:12 Сейчас в теме
(7) Да, иногда jit на удивление не помогал, а казалось наоборот добавлял. Но тут надо смотреть как эти запросы без него работать будут.

pgtune на мой взгляд - это грубый старт далеко лежащий от 1Сных особенностей.

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

А что-то вообще покрутить похоже нельзя, т.к. 1С переопределяет эти настройки при установке соединения. Замечали, что в планах постгрес никогда не встречается MergeJoin? Вспоминается статья Гилева определенной давности, где он советует отключить сканы (я так понимаю на момент закрытия месяца), тогда у нас вообще останется один только HashJoin (да Bitmap внезапно везде начинает вылезать взамен)
А работа с индексами в некоторых случаях, оператором "В" (на больших базах с более чем миллионами записей по регистрам) заставила меня серьезно взгрустнуть( Скоро доготовлю пример отправлю в 1С, посмотрим что скажут.
10. starik-2005 3091 30.01.22 21:15 Сейчас в теме
(9)
один только HashJoin
А чем nested loop мешает? Отличный оператор. А по поводу цены, то в том же pg_tune есть опция на тему диска, и для SSD предлагается как раз сильно снизить цену некоторых операций.
13. ivanov660 4583 30.01.22 21:44 Сейчас в теме
(10) Мне не мешает, я экспериментировал и внезапно наткнулся на гилева.

Посмотрел. Два параметра меняется (ssd и hdd): random_page_cost и соответственно effective_io_concurrency.
Увеличение random_page_cost ведет к росту использования операторов bitmap, что логично - вместо единичного, заставляет использовать пакет. А второй оператор сейчас влияет как раз на сканирование по этой битовой карте. Так вот, на мой взгляд, для маленьких табличек по замерам выгоднее все же использовать сканы, а битмапы хороши для случаев когда данных много и их большая часть идет дальше.
59. ProstoProgrammist 6 18.04.23 23:48 Сейчас в теме
(6) С быстродействием в постгрессе все отлично. Еще В 2015 году была база на 800 одновременно работающих пользователей. Часть веб интерфейс + реактивность, часть в тонком, часть в толстом. Все отлично. На MSSQL были проблемы, поэтому и перешли на постге еще в 2012.
А сейчас вышли новые версии, все стало еще лучше, раньше были ньансы, нельзя было криво писать запросы, нужно было настроить сам постгрес, тонкой настройкой, но сейчас опыт показывает что все адекаватно работает из коробки.
8. anosin 29 30.01.22 21:08 Сейчас в теме
А перенос средствами sql backup/restore уже неактуален?
11. Dream_kz 129 30.01.22 21:21 Сейчас в теме
(8) Расскажите, как это сделать при переходе с MS SQL на PostgreSQL?
bocharovki; veselon; alxarz; BigB; IgorS; MrFlanker; Sedaiko; +7 Ответить
21. cdiamond 236 31.01.22 13:13 Сейчас в теме
(11) Теоретически ничего абсурдного в этом нет. Делаешь Script database to file, далее скорее всего необходим переводчик с одного диалекта языка SQL на другой диалект, и скормить полученный файл pg. Специально такой переводчик я не искал, но даже если в природе существует такой то вряд ли учитывает патчи от 1С.
29. anosin 29 31.01.22 17:44 Сейчас в теме
(21) тогда проще конвертацией, вот только насколько это реально по времени )
22. strav 31.01.22 13:45 Сейчас в теме
(8) А это как?
Был MSSQL стал PostgreSQL
28. anosin 29 31.01.22 17:43 Сейчас в теме
(22) забей, сначала не увдел когда листал в смартфоне, что перенос между разными скулями.
12. Painted 49 30.01.22 21:22 Сейчас в теме
Че-то резко, то 0, то сразу 1. А поиграться - 2,3,4....?
14. user1342811 19 30.01.22 23:29 Сейчас в теме
(12)
А смысл поигратся? У человека была разовая задача перенести базу с одного сервера на другой. А не определять при каком максимальном количестве JobsCount, это заработает на его железе, OS, SQL.
IgorS; sapervodichka; Antoska; mrChOP93; +4 Ответить
15. Painted 49 31.01.22 07:52 Сейчас в теме
(14)Было бы интересней, полноценное исследование.
16. sirbusby 31.01.22 10:07 Сейчас в теме
(15)
Размер dt - 73 Гб.
Размер базы - 733 Гб.
-JobsCount 1 - 5 часов 22 минуты.
-JobsCount 4 - 2 часа 8 минут.
imaster; EugeneSemyonov; sapervodichka; Painted; +4 Ответить
18. Nexoid 31.01.22 12:54 Сейчас в теме
кпривет все м , кто сталкивался плиз ! ткните куда копать !! :)
схожая проблема связка 1с и постгрес - маленькие базы 2-3гб разворачивает нормалльно , все что больше - были 9 были 16 итд - одна ошибка - "ошибка принимающей стороны"
Передача данных прервана по инициативе принимающей стороны.
server_addr=tcp://audit1c:1561 descr= line=2075 file=src\DataExchangeTcpClientImpl.cpp
варианты "лечения" выше не помогают
19. sapervodichka 6918 31.01.22 13:10 Сейчас в теме
(18) это 1С такую ошибку пишет, а есть файл log с PostgresSQL?
20. sapervodichka 6918 31.01.22 13:12 Сейчас в теме
(19) ну и лучше не тут писать, конечно, а в ветке форума создать вопрос
23. Painted 49 31.01.22 13:59 Сейчас в теме
(18)У нас такое было, когда ресурсов сервера не хватало. Тяжелая операция, sql долго не отвечает, 1c закрывается по таймауту. Помогло перенести базу на быстрый диск SSD PCI-e, но не надолго. Окончательно решил проблему новый сервер.
25. strav 31.01.22 14:12 Сейчас в теме
(23)

Лучше PostgreSQL разместить на отдельном сервере (не любит он жадных до памяти и диска соседей - типа 1С) и
под управлением Linux.
cdiamond; +1 Ответить
26. cdiamond 236 31.01.22 15:11 Сейчас в теме
(23) При переносе базы на NVMe под линуксом крайне рекомендую ознакомится с темой планировщика очереди диска и соответствующим образом настроить его, т.к. многие ядра по умолчанию для nvme включают планировщик none, который по сути реализует тупейший fifo в надежде на скорость, что при многопоточности не есть хорошо
24. strav 31.01.22 14:09 Сейчас в теме
(18)

Нужен лог постгрес для оценки проблемы
50. Maden 14.12.22 11:51 Сейчас в теме
(2)Ком это т
(18)Нужно загрузить на постгри дт 68гб. Не грузиться при выделения памяти 4гб на rphost.exe, последний успешно перезапускается. Настройки памяти на сервере 1с для раб. процессов не влияют. Ставил 50гб. В расположении постгри дискового пространства достаточно. База успевает развернуться на 10гб.
На mssql загружается.
27. user716065 20 31.01.22 16:40 Сейчас в теме
Спасибо, за информацию.
30. w.r. 650 01.02.22 06:10 Сейчас в теме
Блокировки в Postgres - довольно не редкое явление. Много раз сталкивался. Кодинг предполагает ставить их в управляемом режиме при записи большого объема данных, чтобы не нарваться на взаимоблокировки. В данном случае, видимо, помогает только однопоточная загрузка DT
32. IT_Magnit 01.02.22 16:34 Сейчас в теме
Грузили ДТшники по 500-600 Гб в 12 потоков как раз на новой платформе, проблем не было.
33. w.r. 650 01.02.22 16:48 Сейчас в теме
51. Maden 14.12.22 11:53 Сейчас в теме
(32)На пострги? Какая версия?
34. IT_Magnit 01.02.22 16:53 Сейчас в теме
(33) Да, из скуля в постгрес
35. sapervodichka 6918 01.02.22 17:34 Сейчас в теме
(34) ну там видишь может это из-за УПП, блокировка была всегда на разворачивании таблиц бухгалтерских итогов, а сама по себе база УПП вся с автоматическими блокировками. Возможно архивы больших баз из новых релизов с управляемыми блокировками по другому реагируют, а возможно Postgres сконфигурирован у тебя по другому, у меня когда ERP (оно с управляемыми) грузил на Postgres dt 20 Гб тоже проблемы не возникло.
37. w.r. 650 02.02.22 00:19 Сейчас в теме
(35) у человека может стоять большое значение параметра max_locks_per_transaction. Плюс большое значение deadlock_timeout
sapervodichka; +1 Ответить
38. sapervodichka 6918 02.02.22 00:29 Сейчас в теме
(37) может быть, у меня они по умолчанию стояли, я их не менял
39. w.r. 650 02.02.22 10:52 Сейчас в теме
(38) можно конечно поиграться ради эксперимента. Может подберёшь для себя оптимальные. Суть Postgres в настройке эмпирическим путём
36. w.r. 650 02.02.22 00:11 Сейчас в теме
(34) настройки базы можно тогда посмотреть?
40. IT_Magnit 02.02.22 14:57 Сейчас в теме
(35) Вы базу на авто блокировках переводили на постгрес?
41. sapervodichka 6918 02.02.22 15:19 Сейчас в теме
(40) 1С УПП 1.3 - это сама конфигурация на автоматических блокировках построена (блокировки регулируются на уровне СУБД, в данном случае PostgresSQL). Новые решения типа 1С:ERP на управляемых (Блокировки регулируются на уровне Сервера 1С).
42. IT_Magnit 04.02.22 22:21 Сейчас в теме
(41) погугли еще, чем версионник отличается от блокировочника, будет полезно.
43. sapervodichka 6918 05.02.22 11:38 Сейчас в теме
(42) смешной совет =) надо придумать под него подходящую публикацию
44. sapervodichka 6918 05.02.22 11:45 Сейчас в теме
(43) имелось ввиду, что на одном и том же сервере, в зависимости от продукта 1С блокировками занимается в основном СУБД в случае старенького продукта 1С:УПП, и сервер 1С в случае, например, продукта 1С:ERP. (разделение СУБД на блокировочная или версионную в этом утверждении не важно). Ты вот написал, что загружал dt, у тебя какой продукт 1С?
45. b00ker 5 16.02.22 00:41 Сейчас в теме
Грузил УСЦ из dt весом 25гб на платформе 8.3.20 в базу MSSQL - 55 часов, тот же файл в Postgres на 8.3.17 - 6 часов. Что-то оптимизация в новых релизах платформы ммм.... странная
sapervodichka; w.r.; +2