Имя: Пароль:
1C
 
Странное поведение 1C на Postgres
0 Oleg5482
 
15.09.15
16:37
Есть платформа 8.2.19 постгрес 9.1.9 с сайта 1с на Win2008
Есть не типовая конфигурация полностью на управляемых блокировках без РЛС.

Запускаем в базе произвольную обработку на массовое добавление и/или модификацию данных в базе (перепроведение документов). Изначально все идет замечательно. Однако после накопления некоторой критической массы 1c начинает дико тормозить на элементарном МенеджерЗаписи.Записать();

Никакие манипуляции и рекомендации по postgres.conf не помогают решить проблему. Переиндексация вакуум с любыми комбинациями настроек - без толку. Помогает только перезапуск службы Postgres и далее все по кругу. Воспроизводится на разных серверах

Даже не знаю куда уже копать.
Сегодня попробую воспроизвести на типовой БП2.

ЗЫ. Критическая масса наступает где то за день работы обработки.
Получив базу в таком состоянии тормозя проявляются при записи во всех таблицах. Например открываем форму списка любого регистра сведений или справочника попробуем вручную добавить новую строку - видим тормоза. Даже если там нет обвязки кода 1с. Тобишь дело не в коде

Подскажите хотя бы куда копать
Спасибо
1 Cyberhawk
 
15.09.15
16:43
Итоги отключи, а разделение включи
2 ansh15
 
15.09.15
16:43
Серверу памяти, наверное, не хватает.
3 Cyberhawk
 
15.09.15
16:44
Вернее разделение выключи
4 Oleg5482
 
15.09.15
16:47
(3) отключил разделение - тоже самое. Проблема проявляется даже в справочниках. Не понял какая связь с итогами?
5 Vovan1975
 
15.09.15
16:49
(1) интересно как будет проводиться документ при отключенных итогах?
6 Vovan1975
 
15.09.15
16:51
я может отстал от жизни, но мне непонятен смысл управляемых блокировок на постре. Какой в них смысл, разве постря уже научился блокировать записи а не таблицы?
7 Oleg5482
 
15.09.15
16:55
(6) конфигурация написана изначально для работы на ms sql на одном и том же наборе данных на скуле работает идеально. Никаких нареканий на производительность и тем более подвисаний никогда не было, а на пострге с полоборота такое.
8 Гёдза
 
15.09.15
16:57
(6) В этом и есть смысл УПРАВЛЯЕМЫХ блокировок
9 ДенисЧ
 
15.09.15
17:06
Понаставят студенческих под(д)елок....
10 Гёдза
 
15.09.15
17:09
может стоит обновить постгре? сейчас 9.4.2 актуальная
11 Гёдза
 
15.09.15
17:10
да и платформу тоже неплохо бы обновить
12 Oleg5482
 
15.09.15
17:17
уже тестирую на 8.3.5. Постгри пока нет возможности проверить 9.4.2
13 Cyberhawk
 
15.09.15
17:17
(5) см. (3)
(4) при включенном разделении таблица итогов пухнет быстрее (больше), чем при выключенном
14 Serg_1960
 
15.09.15
17:38
Стесняюсь спросить банальное "А вы в настройке конфигурации postgresql.conf параметры изменяли, например, effective_cache_size?" Обычно рекомендуют половину памяти ему отдавать.
15 Vovan1975
 
15.09.15
17:47
(8) да ну? и че, в управляемых блокировках на постгре можно запись заблокировать, да?
16 Oleg5482
 
15.09.15
17:48
(14) конечно!

руководтствовались всеми рекомендациями 1с
http://its.1c.ru/db/metod8dev#browse:13:-1:1981:1987
17 Necessitudo
 
15.09.15
17:49
(6) В версионниках на автоматических блокировках минимальная гранулярность - таблица.
18 Vovan1975
 
15.09.15
17:55
(17) а на управляемых?
19 Necessitudo
 
15.09.15
17:56
(18) Запись собственно.
20 Oleg5482
 
16.09.15
17:13
8.3.6.2152 эффект тот же самый (
21 DS
 
16.09.15
17:32
(15) Можно.
22 DS
 
16.09.15
17:34
(20) субд бы обновить.
23 ansh15
 
16.09.15
20:02
(20) Посмотри, все-таки, потребление памяти на сервере, Windows может файл подкачки активно использовать, когда и PostgreSQL и сервер приложений себе памяти нахватают.
Хотя бы для того, чтобы знать, тормоза не из-за нехватки памяти.
Postgre обычно сразу плохо работает, если ему что-то не нравится, неоптимальные планы запросов или еще что.
Советы обновить СУБД уже были.