Вход | Регистрация

  1  2   
1С:Предприятие :: 1С:Предприятие 8 общая

КА 1.1.107.4 - проблемы с архивацией на СУБД Postgres Pro

КА 1.1.107.4 - проблемы с архивацией на СУБД Postgres Pro
Я
   mgk2
 
16.10.18 - 08:52
Исходные данные :
КА 1.1.107.4 с мелкими доработками
Платформа 8.3.9.2170
СУБД Postgres Pro 9.4

Все работало стабильно почти 2 года, пока не обновил конфу на релиз 1.1.107.4 .
Заметил, что перестали восстанавливаться архивы созданные с помощью pg_dump.

Начал разбираться и выяснил, что pg_dump в процессе архивации выдает ошибки :

pg_dump: Ошибка выгрузки таблицы "config": сбой в PQgetResult().
pg_dump: Сообщение об ошибке с сервера: Р?РЁР?Р'Р?Р?:  invalid memory alloc request size 1174829507
pg_dump: Выполнялась команда: COPY public.config (filename, creation, modified,attributes, datasize, binarydata) TO stdout;

Переносил базу на другие сервера , менял версии Postgres (9.6 и 10.5), менял платформу (8.3.9.2309 и 8.3.10.2772) - результат тот же, pg_dump не может нормально создать архив.

При постановке конфы обратно на поддержку архивация начинает работать нормально.

Как можно решить проблему?
 
 
   Cool_Profi
 
1 - 16.10.18 - 08:54
Поставить нормальный скуль не предлагать?
   shuhard
 
2 - 16.10.18 - 08:54
(0)[Как можно решить проблему?]
invalid memory alloc request size 1174829507
видимо копать нужно от сюда
   Фрэнки
 
3 - 16.10.18 - 08:54
в данном контексте вот эту фразу раскрой, если не трудно
// При постановке конфы обратно на поддержку //
   mgk2
 
4 - 16.10.18 - 08:55
(3) на замок
   Фрэнки
 
5 - 16.10.18 - 08:56
(4) когда конфа на замке, то требуется грубо в два раза меньше оперативы
   mgk2
 
6 - 16.10.18 - 08:57
Проводил эксперимент:
1. Выгружаю конфу поставщика в cf.
2. Из цф создаю чистую базу.
3. Запускаю pg_dump - архивация проходит нормально.
4. В этой же конфе включаю возможность изменения.
5. Запускаю pg_dump - архивация проходит НЕ нормально.
   mgk2
 
7 - 16.10.18 - 08:58
(5) Оперативы достаточно. Пробовал компы с 16 и 32 Гб оперативки.
Postgres Pro - х64.
   mgk2
 
8 - 16.10.18 - 09:00
+(6) только цифры после invalid memory alloc request size другие.
   Фрэнки
 
9 - 16.10.18 - 09:01
(7) Был у меня клиент пару лет назад. Жаловался на похожие траблы. Поскольку ему нужно было хоть какое-то решение, то ему пришлось делать все такие штуки непосредственно в линуксе - под виндой уже не работало.
Именно с конфигой на КА 1.1 !!!
   mgk2
 
10 - 16.10.18 - 09:05
Если кто имеет возможность провести эксперимент (6), попробуйте и напишите о результате. На все про все нужно 15 минут на нормальном компе.
Я пробовал на WinServer 2008 R2 и Win7 .
 
 Рекламное место пустует
   mgk2
 
11 - 16.10.18 - 09:09
(2) Вроде как у Postgres лимиты не маленькие :

Максимальный размер таблицы - 32 TB
Максимальный размер строки - 400 Gb
Максимальный размер поля - 1 GB
   Nikoss
 
12 - 18.10.18 - 06:42
(0)
Покажи скрипт, как бэкап делается.

[проблемы с архивацией]
не путаешь понятия дампа и архива? Проблемы именно с архивацией?
   mgk2
 
13 - 18.10.18 - 07:50
set fTime=%time%
set fHour=%fTime:~0,2%
set fHour=%fHour: =0%
set fMin=%fTime:~3,2%


Set f_date=%date%
set f_year=%f_date:~6,4%
set f_month=%f_date:~3,2%
set f_day=%f_date:~0,2%
set f_name=%f_year%_%f_month%_%f_day%_%fHour%_%fMin%
"C:\Program Files\PostgresPro 1C\9.4\bin\pg_dump" -U postgres -F c -Z9 -c -f C:\arc\arc_pg\ara_backup.backup bs
ren C:\arc\arc_pg\ara_backup.backup bs_%f_name%.*
   Nikoss
 
14 - 18.10.18 - 08:15
попробуй формат старндартный
убери "-F c -Z9"
   mgk2
 
15 - 18.10.18 - 08:25
(14) Не помогло. Та же ошибка.
   Йохохо
 
16 - 18.10.18 - 08:39
тут пишут что не туда копаешь
https://www.endpoint.com/blog/2010/06/01/tracking-down-database-corruption-with
   Йохохо
 
17 - 18.10.18 - 08:43
   ansh15
 
18 - 18.10.18 - 09:36
(15) Снятие с поддержки любой другой конфигурации также приводит к такой ошибке? Или только КА указанной версии?
   Фрэнки
 
19 - 18.10.18 - 09:42
(18) немного не так - если снять с поддержки совсем, то есть без сохранения поддержки, то ошибка может исчезнуть.

з.ы. Трабл именно при снятии с "замка" и при сохранении поддержки
   mgk2
 
20 - 18.10.18 - 09:58
(18)  Именно в версиях КА 1.1.107.3 и 1.1.107.4.
В КА 1.1.106 проблемы еще нет.
Попробовал уже с типовыми демоконфами КА - все так же.
Т.е проблема не в моей базе , а в конфигурации конкретной версии.
   ansh15
 
21 - 18.10.18 - 09:59
(19) Я понимаю. У нас бухгалтерия и зарплата в таком режиме поддержки уже много лет, ничего подобного никогда не возникало. Правда, и сервер приложений и СУБД на Linux(тоже много лет).
   mgk2
 
22 - 18.10.18 - 10:03
+(20) Тут же УТ11.4 и БП3 живут без проблем.
   mgk2
 
23 - 18.10.18 - 10:13
(19) [если снять с поддержки совсем, то есть без сохранения поддержки, то ошибка может исчезнуть]

попробую
   shuhard
 
24 - 18.10.18 - 10:26
(22) а ты выгрузи Cf и посмотри его размер, скорее всего он будет больше 1.2 Гбайт
а потом сравни с  1.1.106.1 - там будет 650 Мбайт

ларчик то просто открывается
   mgk2
 
25 - 18.10.18 - 10:55
(24) Посмотрю.

[ скорее всего он будет больше 1.2 Гбайт ]

А что за ограничение в этом случае срабатывает?
   shuhard
 
26 - 18.10.18 - 11:00
(25) Я с  Postgres не работаю, а размер cf заметил в УПП 1.3.112.4 (крайний релиз)

так что дальнейшие действия у тебя на форумах Postgres
   Фрэнки
 
27 - 18.10.18 - 11:04
(25) твой же пост:
-*-
Вроде как у Postgres лимиты не маленькие :

Максимальный размер таблицы - 32 TB 
Максимальный размер строки - 400 Gb
Максимальный размер поля - 1 GB
   mgk2
 
28 - 18.10.18 - 11:08
(27) Хочешь сказать, что платформа конфу заталкивает в 1 поле?
   shuhard
 
29 - 18.10.18 - 11:14
(28) да, это один BLOB
   Nikoss
 
30 - 18.10.18 - 11:25
Вот это поворот -_-
   mgk2
 
31 - 18.10.18 - 11:38
+(25)  размер cf 1.03 гб
   Nikoss
 
32 - 18.10.18 - 11:42
(31) я бы чисто ради интереса грохнул что-нибудь из конфы, чтоб привести размер cf к 0.99Гб, и проверить еще раз бэкап. (что там есть такого, макеты с двоичными данными, какие-нибудь)
   Фрэнки
 
33 - 18.10.18 - 11:48
(32) да я ж и предлагаю - снять с поддержки полностью и размер в два раза упадет и проблема должна уйти, если это в ней причина.
 
 
   Йохохо
 
34 - 18.10.18 - 11:51
(33) а тут выяснили почему работает твое кривоватое решение, лучше же нормально сделать
   Фрэнки
 
35 - 18.10.18 - 11:57
(34) кому? Поставщикам конфиги из 1С ?
   Йохохо
 
36 - 18.10.18 - 11:57
(35) почему нет
   Фрэнки
 
37 - 18.10.18 - 11:59
(36) 1С предлагает всем бесплатный апгрейд с конфиги КА 1.1 на конфиг КА 2.х
   shuhard
 
38 - 18.10.18 - 12:17
(37) гильотина лучшее средство от перхоти (с)
   Nikoss
 
39 - 18.10.18 - 12:57
(37) а КА 2.х не >1Гб cf?
   Фрэнки
 
40 - 18.10.18 - 13:14
(39) если на замке, то 615 мб в релизе 2.4.5.24
если с вклеченными изменениями с сохранением поддержки = 1.1 гиг (до внесения каких-то изменений)

Но это ни одного там в ней изменения нет, когда вкл изм и накидать туда макетов огромных, то будет больше, конечно.

з.ы. Все-таки я думаю, что в КА 1.1 там не прямая зависимость с размером, а с самим наличием "второй копии" конфигурации, которая конфликтует с "первой" при запихивании ее в БЛОБ платформой - просто глючит в данном случае при попытке архивации баз, а так оно и в других событиях глючит тоже. При накатывании обновлений из Поддержка-Обновить конфигурацию, например.
   shuhard
 
41 - 18.10.18 - 13:24
(40) [ просто глючит в данном случае при попытке архивации баз]
+100500
проблема Postgres, с MS SQL её нет
   mgk2
 
42 - 18.10.18 - 16:38
(40) Такая же проблема должна быть и под линуксом. Ведь лимит на размер поля у Postgres одинаковый для обоих версий.
   shuhard
 
43 - 18.10.18 - 16:45
(42) [pg_dump: Ошибка выгрузки таблицы "config": сбой в PQgetResult().
pg_dump: Сообщение об ошибке с сервера: Р?РЁР?Р'Р?Р?:  invalid memory alloc request size 1174829507]

таблицы "config invalid memory alloc request size 1174829507

можно и дальше позаниматься флюдом, но тема закрыта
   shuhard
 
44 - 18.10.18 - 20:19
(43) на родственном ресурсе та же ошибка в отраслевой на базе УПП 1.3.112.4 =)
http://www.sql.ru/forum/1304093/1s-molokozavod-1-3-112-4-ne-rabotaet-bekap-sredstvami-postgresql

т.е. дело однозначно в размере cf
   mgk2
 
45 - 18.10.18 - 21:19
(44) благодарю
   ansh15
 
46 - 18.10.18 - 22:55
http://www.sql.ru/forum/1302916/problema-pri-sozdanii-rezervnoy-kopii-pg-dump  - каких-то конкретных положительных решений тоже не наблюдается.
Остается писать в 1С, пусть разбираются. Попутно можно было бы попробовать в Linux. Так, на всякий случай, чтобы убедиться, что там то же самое(или нет).
   tesseract
 
47 - 18.10.18 - 23:53
BLOB побился явно. Перезагрузить конфу прямой загрузкой.

>>Платформа 8.3.9.2170 

Ретроград?
   Фрэнки
 
48 - 19.10.18 - 08:25
(47) попробовать можно, но в тех вариантах не помогало, на которые я ссылался, что ошибки с КА 1.1 возникали в серверном режиме.
   Фрэнки
 
49 - 19.10.18 - 08:29
я сегодня проверю вариант с большой конфигой по размеру (ка_2.4) на субд постгри и сервером на винде - сглючит или нет - проверю. Не знаю только получится ли протестить, если сервер для субд будет линуксовый... долго такое городить и профита не будет чисто поэкспериментировать и прокачать экспу разве что :-)
 
 Рекламное место пустует
   Trotter
 
50 - 19.10.18 - 08:36
100 гигов, полёт нормальный.
SET PGPASSWORD=12344321

"C:\Program Files\PostgreSQL\10.3-2.1C\bin\pg_dump.exe" --host localhost --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --section pre-data --section data --section post-data --encoding UTF8 --verbose --file "D:\1cBackupNew\BUH_%date:~6,4%-%date:~3,2%-%date:~0,2%.backup" "BUH"
   Фрэнки
 
51 - 19.10.18 - 08:39
(50) а размер выгруженной одной только CF из этой базы какой?
   Фрэнки
 
52 - 19.10.18 - 08:40
(50) BUH ? - это же вероятно конфигурация БП какая-то?
   Trotter
 
53 - 19.10.18 - 08:40
(51) не проверял размер CF, БП30
   Фрэнки
 
54 - 19.10.18 - 08:42
(53) ну дык... с этими конфигами проблем нет, не было и не будет - про такие никто и не говорит.
   shuhard
 
55 - 19.10.18 - 08:58
(54) +100500
   mgk2
 
56 - 22.10.18 - 09:17
Вырезал из конфигурации несколько макетов ненужных драйверов.
cf сократил до 0,98 Гб. Но проблема с архивацией осталась.
   Nikoss
 
57 - 22.10.18 - 09:28
(56) полностью снятие с поддержки (чтоб конфа была 600мб) тоже не помогает?
   Фрэнки
 
58 - 22.10.18 - 09:34
(56) а какую теперь ошибку пишет?
   mgk2
 
59 - 22.10.18 - 09:37
(58) Ту же самую.
   mgk2
 
60 - 22.10.18 - 09:39
(57) Этот вариант на крайний случай. Боюсь проблем с обновлениями.
   Фрэнки
 
61 - 22.10.18 - 09:39
(59) ???  invalid memory alloc request size 1174829507
   mgk2
 
62 - 22.10.18 - 09:43
(61) Да. Только циферки немного другие , поскольку на демобазе эксперименты ставлю.
   Йохохо
 
63 - 22.10.18 - 09:58
просто для теста пг_дамп с 
--exclude-table-data=public.config
пройдет?
   mgk2
 
64 - 22.10.18 - 10:08
(63) так архивация проходит без ошибок.
   Йохохо
 
65 - 22.10.18 - 10:20
(64) гугл упорно говорит, что таблица битая. Я бы уменьшил ее еще, но значительно - до 500мб, например, и еще раз пг_дамп. Это подтвердит битая или нет
   Фрэнки
 
66 - 22.10.18 - 11:06
можно предположить, что источником ошибки и вовсе окажется некий конкретный объект метаданных, только сколько раз надо провернуть все-все-все манипуляции, чтоб найти такой объект. Причем, сбоить этот объект начинает в процессе клонирования конфиги поставщика в подкопию основной ЦФ-конфиги
   Вафель
 
67 - 22.10.18 - 11:08
постгре под виндой чтоли?
   mgk2
 
68 - 22.10.18 - 11:12
(65) Ставлю конфу на замок , или снимаю ее с поддержки - проблема уходит.
   mgk2
 
69 - 22.10.18 - 11:14
(67) см (24)-(31) - судя по всему такая же проблема возможна и под linux.
   Йохохо
 
70 - 22.10.18 - 11:21
(69) тогда бы гугл знал о ней, 1гб сейчас не то чтобы много
   mgk2
 
71 - 22.10.18 - 11:25
(70) уже знает - в (44) (46) есть ссылки.
   Фрэнки
 
72 - 22.10.18 - 11:28
(71) извини, но это ссылки практически такого уровня, как на ветки на нашей же мисте
   Йохохо
 
73 - 22.10.18 - 11:32
(71) вероятно они твои)
https://pgconf.ru/media/2018/02/14/DBeaver_PgConf-Russia-2018.pdf
будешь дальше копать или альтернативу искать?
   mgk2
 
74 - 22.10.18 - 16:53
(66) Похоже ты прав.
Развернул демоконфу КА2, включил возможность изменения - в результате  cf размером 1,2 Гб.

Архивация проходит без проблем.
   Колянович
 
75 - 24.10.18 - 10:41
Такая же проблема. dt делается. в копию серверную(Postgres pro 9.6) не грузится, ругается на память, а в файловую загрузился. Пытаюсь определить проблемный объект в метаданных. Попутно попробую в mssql 2008 загрузить dt.
   Фрэнки
 
76 - 24.10.18 - 11:19
(75) А я бы просто оставил базу с полностью снятой с поддержки, а обновления заготавливал по мере необходимости из файлового режима. Какая разница, если развернута тестовая копия и завершить процедуру обновления все равно нужно только на тестовой, а затем уже из тестовой забирать CF и обновлять продакшн базу сравнением/объединением.
   Колянович
 
77 - 24.10.18 - 11:37
(76) как сейчас решение да, но причина явно не устранена. попробую 107.5 накатить на файле и перенести на серверную.
   Колянович
 
78 - 24.10.18 - 14:03
В MsSQL действительно все загружается без ошибок. Проблема на стороне Postgres, попробую покопать настройки. Ни у кого нет опыта тонкой настройки? Не хочется верить, что Postgres настолько не продуман.
   mgk2
 
79 - 24.10.18 - 14:20
в релиз КА 1.1.107.5 этот косяк не убрали.
   Фрэнки
 
80 - 24.10.18 - 15:17
(78) никто и не заставляет. Только две конфиги КА 1.1 и УПП 1.3 - с остальными проблем нет. с КА 2.4 тоже проблем нет.

(79) этому косяку уже много лет.
   mgk2
 
81 - 24.10.18 - 15:47
(80) Но воспроизводится он только на демоконфигурациях версий 1.1.107.х.
   gae
 
82 - 25.10.18 - 06:50
Раньше была проблема на 32-ух битных версиях PostgreSQL, не хватало им памяти для больших конфигураций. Приходилось снимать с поддержки  конфу, чтобы работать.  С появлением 64-битной проблема ушла.
И вот опять что-то похожее.
   МимохожийОднако
 
83 - 25.10.18 - 07:14
(0) Какая операционная система?
   Nikoss
 
84 - 25.10.18 - 07:16
(83) вин
   МимохожийОднако
 
85 - 25.10.18 - 07:18
(84) Ты не автор. "вин" бывает разный.
   mgk2
 
86 - 25.10.18 - 10:50
(83) win7, win10, win2008r2
   Колянович
 
87 - 31.10.18 - 10:50
Насколько я разобрался 1С пихает файл конфигурации в поле. Поле имеет ограничение 1 Гб. Размер конфы закрытой для ред. и снятой с поддержки не превышает 1 Гб, а частично дописанная превышает. 1С рекомендует (прочитал на форуме SQL) снимать с поддержки полностью или использовать pg_basebackup. Снял на тестовой с поддержки - дамп отработал без ошибок.
   Nikoss
 
88 - 31.10.18 - 11:10
(87) см (74)
   Фрэнки
 
89 - 31.10.18 - 11:15
(87) Просто рекомендация 1С не совсем честная. Если снять конфу КА 1.1 с поддержки или УПП 1.3 с поддержки, то проблема действительно пропадает. Однако, есть другие конфы, с которыми этой проблемы в принципе нет - см (74),
а так же и другие.
   Колянович
 
90 - 31.10.18 - 13:40
(89) и решения от 1с скорее всего не дождемся. Работу с данными в этом случае организует кластер серверов 1с? имею в виду структуру таблиц.
   mgk2
 
91 - 06.11.18 - 10:44
(87) На каком варианте остановился?
   kook
 
92 - 07.11.18 - 21:14
(87)В тему: те же проблемы с УПП 1.3.112.4 на pg 9.6:
-при архивировании средствами pg - описанная выше ошибка
-при обновлении - вылетает

При анализе выяснилось, что ошибка возникает с таблицей config (конфигурация БД), при обработке определенной строки таблицы, подробности ниже.
1. Просмотрел таблицу config, поля: filename (строка), creation (датавремя), modified(датавремя), attributes(целое), datasize(целое), binarydata(bytea).
2. Строк 34017.
3. Сумма размера бинарных полей примерно 98% размера файла .cf (остальное занимают оставшиеся поля), т.е. в binarydata хранится конфигурация.
4. Проверил: для любой строки размер binarydata не более 100МБ. Кроме одной, там размер binarydata 555МБ. И именно в этой строке возникает ошибка. Выяснил, что в данной строке, в одном поле хранится конфигурация поставщика.
5. Поэтому при снятии с поддержки или запрете изменений (замок) ошибка исчезает, т.к. при этом удаляется строка по п.4.
Суммируя вышеизложенное: максимальный размер данных, внесенных в ОДНО поле - 0,55ГБ (см. п.4.), что не дотягивает до озвученного лимита объема данных в ОДНОМ поле 1ГБ.

Вывод: либо лимит объема ОДНОГО поля около 0,5ГБ, либо причина в другом.

Пробовал играть настройками конфигурации pg (размеры буферов памяти и т.п.) - ошибка не исчезла.
   kook
 
93 - 07.11.18 - 21:47
(92)Кстати, и обычный select средствами pg вызывает эту же ошибку, если в его результате содержится поле Binarydata с конфигурацией поставщика (555МБ) - еще одно подтверждение что ограничение 1ГБ ни при чем.
   mgk2
 
94 - 07.11.18 - 21:51
(93) да. конфа ка2 нормально переносит снятие с замка.
   spectre1978
 
95 - 07.11.18 - 22:46
(0) ровно та же проблема у меня была с УПП в 2012 году - с той же ошибкой pg_dump грохался. Стабильность - признак мастерства, чо... Сколько лет прошло, а ничего не меняется.
   timurhv
 
96 - 08.11.18 - 00:41
(95) Так поди все на форумах пошушукались и разработчикам никто не отписал.
   Garykom
 
97 - 08.11.18 - 01:22
shared_buffers = 512Mb ?
   Фрэнки
 
98 - 08.11.18 - 08:37
(96) отписывались. Я помню об этих глюках примерно с 2011-2012 годов. Когда это поперло, то начали откладывать на ИТС полные дистрибы КА 1.1 и УПП 1.3 , т.к. реально был всплеск обращений, что не проходит процедура обновления конфиги апдейтами.
   mgk2
 
99 - 08.11.18 - 10:25
(97) shared_buffers = 768MB
   mgk2
 
100 - 08.11.18 - 10:29
(96) Я две недели назад написал на v8@1c.ru.
Отписались, что проблема передана разработчикам, и, пока, все.
  1  2   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует