Странное поведение 1C на Postgres #753287

Есть платформа 8.2.19 постгрес 9.1.9 с сайта 1с на Win2008 Есть не типовая конфигурация полностью на управляемых блокировках без РЛС. Запускаем в базе произвольную обработку на массовое добавление и/или модификацию данных в базе (перепроведение документов). Изначально все идет замечательно. Однако после накопления некоторой критической массы 1c начинает дико тормозить на элементарном МенеджерЗаписи.Записать; Никакие манипуляции и рекомендации по postgres.conf не помогают решить проблему. Переиндексация вакуум с любыми комбинациями настроек - без толку. Помогает только перезапуск службы Postgres и далее все по кругу. Воспроизводится на разных серверах Даже не знаю куда уже копать. Сегодня попробую воспроизвести на типовой БП2. ЗЫ. Критическая масса наступает где то за день работы обработки. Получив базу в таком состоянии тормозя проявляются при записи во всех таблицах. Например открываем форму списка любого регистра сведений или справочника попробуем вручную добавить новую строку - видим тормоза. Даже если там нет обвязки кода 1с. Тобишь дело не в коде Подскажите хотя бы куда копать Спасибо

Итоги отключи, а разделение включи

Серверу памяти, наверное, не хватает.

Вернее разделение выключи

отключил разделение - тоже самое. Проблема проявляется даже в справочниках. Не понял какая связь с итогами?

интересно как будет проводиться документ при отключенных итогах?

я может отстал от жизни, но мне непонятен смысл управляемых блокировок на постре. Какой в них смысл, разве постря уже научился блокировать записи а не таблицы?

конфигурация написана изначально для работы на ms sql на одном и том же наборе данных на скуле работает идеально. Никаких нареканий на производительность и тем более подвисаний никогда не было, а на пострге с полоборота такое.

В этом и есть смысл УПРАВЛЯЕМЫХ блокировок

Понаставят студенческих под(д)елок....

может стоит обновить постгре? сейчас 9.4.2 актуальная

да и платформу тоже неплохо бы обновить

уже тестирую на 8.3.5. Постгри пока нет возможности проверить 9.4.2

см. при включенном разделении таблица итогов пухнет быстрее (больше), чем при выключенном

Стесняюсь спросить банальное "А вы в настройке конфигурации postgresql.conf параметры изменяли, например, effective_cache_size?" Обычно рекомендуют половину памяти ему отдавать.

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

конечно! руководтствовались всеми рекомендациями 1с

В версионниках на автоматических блокировках минимальная гранулярность - таблица.

а на управляемых?

Запись собственно.

8.3.6.2152 эффект тот же самый (

Можно.

субд бы обновить.

Посмотри, все-таки, потребление памяти на сервере, Windows может файл подкачки активно использовать, когда и PostgreSQL и сервер приложений себе памяти нахватают. Хотя бы для того, чтобы знать, тормоза не из-за нехватки памяти. Postgre обычно сразу плохо работает, если ему что-то не нравится, неоптимальные планы запросов или еще что. Советы обновить СУБД уже были.