postgresql-9.4.2-1.1C_x64 + 1с 8.3.9.2033 + УТ 11.1.2.27 = блокировки #787712

Было: postgresql-9.3.4.1-1C_x64 1с 8.3.8.1652, сервер 1с х32 Конф. УТ 11.1.2.27 Обновил 1с платформу, сервер 1с и postgresql до последних релизов: postgresql-9.4.2-1.1C_x64 1с 8.3.9.2033, сервер 1с х32 Конф. УТ 11.1.2.27 Стало вылазить блокировка таблиц при попытки сделать синхронизацию РИБ. Как при выгрузки данных так и при загрузки. Или если открыть обработкой план обмена и выбрать узел, то та же ошибка. Ошибка: Ошибка чтения файла сообщения обмена: {Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта}: Ошибка при вызове метода контекста (ПрочитатьИзменения): Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки Перезагрузки, монопольный режим, отключение регл. заданий, очищение сеансов на сервере 1с, рестарты служб агента сервера 1с и постгре не помогли. В обычной работе юзеров (около 10 человек) проблем нету. Все открывается, записывается, проводится.

postgresql нужно уметь "готовить". Поэтому делаем так: сносим его нафиг и ставим MS SQL.

Оно было уже "приготовлено" и работало. Проблема возникла после обновления. После апдейта файл postgresql.conf отредактирован так же как и в старом релизе.

Сервер 1с 32 может на 64 заменить?

лицензия

останавливается на строке ТаблицаДанных = Запрос.Выполнить.Выгрузить но не сразу, много данных получает, и на некоторых справочниках стопорится. Функция ПолучитьКоличествоЗарегистрированныхОбъектовДляМетаданногоПоУзлу(МетаданныеОбъекта)

3 раза запускал и глядел отладчик, Два раза стопорился на справочнике НаборыУпаковок, один раз на справочнике РолиПартнеров Но если открыть потом эти справочники вручную - проблем нет, записать - тоже ни каких тебе блокировок

эта функция происходит в обработке РегистрацияИзмененийДляОбмена8_2. Выбираешь план обмена, узел , дальше немного соображает и вылазит ошибка блокировок

получается не могут быть прочитаны все объекты узла

вот же все расписано и даже комменты есть:

упс..  не та ссылка:

Что за...  ???  ____

на инфостарте ищи.  325482

статья о конфигурировании PostgreSQL. Там много чего написано. Но меня интересует решение проблемы блокировки

я её читал ранее и пользовался при начальном конфигурировании

единственно, что приходит в голову, что зря обновил все одновременно и теперь не знаешь в чем собака зарылась Я подозреваю, что проблема в связке именно последних релизов всего сразу между собой. Конф УТ не менял. Значит платформа забрасывает состав блокировок как-то иначе. Что еще можно попробовать... Не смотрел насколько много релизов было после твоей УТ 11 и не смотрел на ее требования к платформе. Поэтому (в порядке, на авось) попробую на режим совместимости в конфигурации глянуть. А ось на сервере какая? Для тестирования старого скл поставить уже не можешь, чтоб другое сочетание взять и сделать не все релизы самыми последними?

Windows server 2008 R2 Вечером буду пробовать понизить релиз платформы 1с и сервера 1с

Windows server 2008 R2  х64

может быть не сразу одновременно понизить, а что-то из двух. Но может быть в релизе платформы. Было какое-то сообщение недавно, что для какой-то из конфигураций (не уверен, возможно, что для Розницы) выскочила рекомендация самые последние релизы платформы не ставить.

Можно, в качестве тестирования, попробовать развернуть базу на MS SQL. Если проблем не будет - значит дело в postgresql. Еще вариант, раз пошла такая пьянка (Обновил 1с платформу, сервер 1с и postgresql) - сразу перейти на 11.2.  11.1 как никак уже "на ладан дышит".

база не типовая, переписана много.

это самописный код? нафига Выгрузить, если по факту нужна первая одна строка?

можно попробовать, но... типовой - одна из старых версий - обработка взята из конфигурации КД2. Там суть в том что запрос не отрабатывает. При синхронизации там другой код идёт, но он тоже обращается к объектам плана обмена узла. И получает блокировку

нет блокировка так же выскакивает.

Попробуй время на блокировку увеличить - Ну допустум до 360 секунд

а что в технологическом журнале?

не работал с ним раньше, настраивать надо его, нет времени сейчас обучаться. Да и мало надежд на него. увеличивал до 40, ради интереса попробую побольше поставить, посмотрим

хотя это правильный путь

сам недавно веду УТ 11 на постгри, помог рестарт postgresql и вакуум с реиндексом на выходных.

в смысле у тебя были схожие симптомы?

Поставь вообще много для теста время на блокировку 600 или 10000 даже. Проверить как отреагирует. Может быть запросы в транзакции суммарно просто не успевают и их откатывают. В любом случае это ничего не сломает и можно вернуть в любое время. Я так тестировал на sql на нагруженных базах. Это запросы тупят по времени. Или реально блокировка. Потому что борьба разная. Если тупят по времени то надо смотреть длинные запросы. Если блокировка то надо смотреть операции на запись. И сдвигать их в конец транзакции.

Вакуум и реиндекс делал, не помогло

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

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

помог рестарт postgresql и вакуум с реиндексом на выходных.

вот поэтому мало надежд на техн. журнал. Ибо то что могло помочь в этом случае уже сделано.

ну, пальцем в небо. разверни копию базы, и попробуй запустить перепроведение документов массово. если ошибка повторяется - то значит дело в самой базе, а не глюк связки PostgreSQL и 1С.

судя по тексту ошибки, таймаут происходит на управляемой блокировке, зачем в этом случае нужно крутить СУБД? Правильный способ решения заключается в анализе управляемых блокировок в технологическом журнале

Первый вариант - откат всех обновлений. Второй вариант (пальцем в небо) - Попробовать сборки от PostgresPro Разработчики утверждают, что их сборки уже на 90% оптимизированы под работу с 1С. То есть никаких дополнительных действий после установки делать не нужно, кроме уж каких-то совсем эксклюзивных настроек. Кроме того в них содержится большое количество патчей под 1С, которых просто нет в тех сборках, которые публикуются на сайте 1С. Версия с сайта 1С 9.4.2-1.1C была опубликована в июне 2015-го года, когда платформы 8.3.9 еще и в проекте не было. Причем для Windows доступны уже сборки версии 9.5.5 и 9.6.1. Про последнюю не знаю, а 9.5 имеет статус "для тестирования" чисто формально только из-за того, что не могут договориться о её официальной поддержке со стороны 1С.

а от блокировок это не спасает. я использую PostgreSQL 9.4.10 с отсюда беру 64-битный сервер, отдельно загружал 64-битный клиент pg_myadmin.

ссылки битые. если надо, могу скинуть 64-битный дистрибутив 9.4.10

не помогло. Начну с понижения сервера 1с и платформы. Отпишусь учту, пока не надо

"от поэтому мало надежд на техн. журнал. Ибо то что могло помочь в этом случае уже сделано." Это не так, для решения данной проблемы еще не сделано ничего от слова "совсем" :) Твой единственный способ решить эту проблему - определить, что именно накладывает несовместимую управляемую блокировку

+ первая ссылка

Под Linux уже тоже готовы сборки 9.6.1 Весной ожидается выпуск коммерческой сборки Postgres Pro Enterprise 2, в которой обещают существенно увеличить производительности Postgres и даже обеспечить ее выше, чем в других коммерческих базах SQL:

Проблема блокировок в ушла. Решение: Откатил платформу 1с с сервером 1с до версии 1с 8.3.8.1652, сервер 1с х32

спасибо за ссылку- будет время, освою

Я одного не понял: сколько будет стоить коммерческая сборка и чем она будет отличаться от обычной.

+100500 тоже интересует этот вопрос - вроде как эта сборка работает быстрее "ванильной" и включает последнюю версию PostgreSQL + патчи для работы с 1С.

Пока молчат. Ощущение такое, что разрешать продавать 1С, тогда у той появится интерес к PostgreSQL.

Кстати, вернули сборку PostgreSQL под 1c Предприятие 8.2 и даже обновили до PostgreSQL 9.3.15 (для 1С версии начиная с 8.2).

и это правильно, есть конфиги живущие на 8.2, которым 8.3 надо как мопсу слоновьи уши.

Интересно. Ребята создавали бесплатную систему. Кто то взял её за основу, добавил плюшек и будет продавать. Ребята не против, или они в доле?

>> Ребята создавали бесплатную систему Ребята из PostgresPro - это часть тех самых ребят, которые создавали бесплатную систему. ))) Где-то даже было перечисление количества изменений в ванильных версиях, которые были внесены этими разработчиками. >> Кто то взял её за основу, добавил плюшек и будет продавать. Ребята не против, или они в доле? А что в этом такого? Это отдельный форк. Ни кого же не возмущает, что Fedora бесплатна, а RedHat денег стоит. Собственно говоря, если коммерческий релиз объективно даёт реальные преимущества по сравнению с ванильным или другим бесплатным, то почему бы и не заплатить. Пугает, что в анонсе коммерческой Enterprise-версии не указано перекочуют ли патчи для 1С исключительно в коммерческую версию, или в бесплатной версии эти патчи тоже останутся.

Думаю, будут обе версии. Enterprise для таких систем или для 8-way x86(для тех, кто "победнее")за отдельную плату, обычная - для остальных, кто купил 1С и подписку на ИТС.

это ошибка зафиксирована тоже на днях столкнулся с одной из перепиленных УТ 11.1 после обновления на 8.3.9.1850. Решил так: в конфигурации поставил режим совместимости 8.3.5 Есть подозрение, что с 8.3.9.1850 все конфигурации в режиме совместимости 8.1 не работают

*Есть подозрение, что с 8.3.9.1850 все конфигурации в режиме совместимости 8.2 не работают

ну как "не работаю" - глючат иногда, на самых непредсказуемых моментах. У меня такое же подозрение.

топикстартер там выше написал, что проблему с ошибкой устранил, понизив версию платформы на сервере. А вот насколько он ее понизил? Не написал