Виснут соединения к БД

Платформа 8.1.14, база на Postgre, Debian, Конфа УТАП.
В наличии 2 идентичных сервера БД, базы реплицируются(РИБ). Время от времени клиенское приложение виснет напрочь. При этом если его прибить локально, соединение к БД остается и из консоли кластера не прибивается.
Зависание происходит в абсолютно произвольный момент, при редактировании ТЧ документа, или при его проведении, открытии справочника и т.п. То есть не на тяжелых транзакциях. Глюки начинают проявляться при более-менее интенсивной нагрузке на базу на обоих серверах. То есть когда в базе 1-2-3 человека, все нормально. Сервер по железу нагружен не сильно.
Включены ТЖ на сервере и клиенте - ни чего особенного. Пробовал один сервер откатывать на 12 платформу - не помогло. Грешу на систему защиты конфигурации. Помогите как то проверить эту версию.

1Сникам отписался, пока эффекта ноль. Вот может тут кто что умное подскажет. У меня уже просто варианты кончились куда копать.

У вас какой релиз конфигурации УТАП?
Мы оптимизировали запросы в последнем релизе, одним из наших клиентов производилось нагрузочное тестирование как раз на Linux и Postgre SQL.
В какие моменты происходит зависание.
По поводу защиты - можем предоставить самые последние драйверы Катран (мы с ними общались по поводу некоторых проблем, правда не связанных зависаниями), которые будут в ближайшем релизе.

Грешу на систему защиты конфигурации. Помогите как то проверить эту версию.

Вообще защита Катран используется в конфигурации минимально, ощибки маловероятны.
Я подготовлю последние версии установки защиты попробуйте.

Здесь размещен дистрибутив защиты (бета версия), доступно для скачивания зарегистрированным на форуме пользователям.
Дистрибутив защиты катран (1.0.0.50) от 19.11.2009 (бета) 1.84 MB

Попробуйте. Напишите о результатах.

релиз 10.3.8.2
До этого была 10.3.7.3, проблема была та же, причем на другом сервере БД (Fedora). Сервер был переустановлен на гарантированно работающую связку Debian+Postgre (ставил человек, который такую связку уже неоднократно использовал на куда более масштабных 1С-базах) Все что касается самой СУБД перепроверено 10 раз.
Зависание происходит в момент любой работы с БД, даже самого незначительного чтения. Например, при подборе в документ. Иногда вообще когда не было работы с БД (смотрю свойства зависшего соединения в консоли). При этом самое плохое, что соединение сервер 1с-БД остается висеть после закрытия приложения. И его не удается сбросить из консоли. Эти соединения висят и некоторые блокируют объекты БД (с которыми работали). Приходится раза по 3 в день перезапускать сервер 1С.
Пробовал ставить таймауты опроса ключа в системе защиты на 6000 сек, не помогло
Защиту новую попробую с удовольствием.
Спасибо за оперативный ответ.

Не помогло
Помимо прочего еще начали "хором" вылетать пользователи с сообщением "информационная база разрушена". Это видимо из-за 12 релиза. Пойду обратно на 14.

Конечно лучше более поздние релизы платформы использовать.
В последних обновлениях - рекомендация не ниже 8.1.15.14 (вот КАТАП чейчас будет выходить), скоро ЛВЗ.
Их уже на 8.2 можно будет конвертировать.

Только 15 релиз не работает стабильно на Postgres...

В общем, проблема осталась. Пробовал выносить сервер приложений на винду - тоже самое. Неужели ни у кого больше такой проблемы нет?

Вероятно не так много работают на Linux.
А в 1С ответили? Мы к ним обращались недавно по УРБД - они дали очень интересный ответ. В самую точку, то что мы даже ожидать не могли.

В 1С просят прислать дамп упавшего процесса rphost на сервере. А он не сохраняется по методике kb.1c.ru даже после kill.

Буду пробовать 15 релиз и постгре 8.4 на свой страх и риск. Хотя до сих пор не понятно на каком уровне собственно происходит проблема.

ЗЫ: А можно уточнить релиз платформы, версию Postgre и Linux на которых проводилось тестирование?

Примерно так:
CPU Xeon(TM) 2.80GHz * 2, RAM 2Гб, RAID 50,
ASPLinux, номер релиза сейчас не скажу, postgresql 8.3.3 (пропатчен по рекомендациям 1С).

Больше уже мысли вслух... Сделал полное тестирование и исправление. Зависаний стало заметно меньше. Сейчас запускаю его каждую ночь, каждый раз находятся битые ссылки Проблема похоже в этом. Осталось понять откуда они берутся. Замена сервера целиком не помогла (аппаратная часть не при чем). На MSSQL такой проблемы нет. Но думаю, это просто из-за более высокого уровня изоляции транзакций.

А дамп в 1С удалось отправить (интересно мнение 1С по этому поводу)?
Вот на всякий случай рекомендация 1С по созданию дампов:

Создание дампов аварийного завершения программы в ОС Linux

В данной статье приводятся шаги по настройке операционной системы Linux для обеспечения создания дампов памяти при аварийном завершении программы. Многообразие дистрибутивов Linux не позволяет со 100% уверенностью говорить о том, что описанные ниже шаги применимы ко всем из них в неизменном виде. Однако общий смысл совершаемых действий является общепринятым. Советы, содержащиеся в данной статье, в полной мере применимы для ОС Fedora Core 4 и ее аналогов.

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

Включение автоматической генерации дампов
В случае если сервер 1С:Предприятия запускается как сервис или генерацию дампов нужно включать сервер 1С:Предприятия по умолчанию: в домашнем каталоге пользователя, от имени которого запускается сервер, например: /home/usr1cv81, необходимо в файл .bashrc добавить строку:

ulimit -с unlimited
В случае если сервер 1С:Предприятия запускается как обычное приложение, то перед его запуском достаточно выполнить команду:

ulimit -с unlimited
Данные действия могут быть выполнены как от имени пользователя с правами root, так и от имени пользователя под которым работает сервер 1С:Предприятия (по умолчанию - usr1cv81).

Определение имени и местоположения дампов
Для более четкого понимания того, каким процессом был сгенерирован дамп аварийного завершения, а также для размещения дампов в требуемом каталоге диска, рекомендуется задать шаблон формирования имени дампа. Задание шаблона может осуществляться как в рамках одной сессии, так и на постоянной основе. Описанные ниже действия необходимо выполнять от имени пользователя root.

Для задания шаблона имени и пути расположения дампов аварийного завершения в рамках одной сессии нужно воспользоваться командой:

sysctl -w kernel.core_pattern=/tmp/core.%e.%p

В этом случае дампы будут размещаться в каталоге /tmp и имя дампов будет формироваться из префикса: core, а также имени исполняемого файла и идентификатора процесса, для которого был сформирован дамп аварийного завершения.

Для указания шаблона имени и пути на постоянной основе необходимо добавить следующую строку в файл /etc/sysctl.conf

kernel.core_pattern = /tmp/core.%e.%p
Для того чтобы сделанные в файле изменения вступили в силу, необходимо выполнить команду:

sysctl -p

Проблема по сути осталась не решенной.
Перешли на MS SQL. На нем, видимо засчет более высокого уровня изоляции транзакций, такая проблема возникает в разы реже и такие соединения удается прибивать из консоли кластера. Далее тратить вагоны времени на решение просто нет возможности. А так по крайней мере можно более-менее спокойно работать.
Были опробованы 3 различных аппаратных сервера, куча комбинаций ОС+СУБД, 3 разных платформы 1С (до 15 не дошли).
Очевидно, проблема в самой 1С. Либо платформа, либо конфа, либо данные.
Платформы перебрали разные.
Конфа дописанная, но не критично. Основные механизмы не трогались. В эту сторону еще покопаю.
Данные - ТИИ ничего криминального не находит. Только "неверные служебные данные".

Все-таки интересно, что ответили в 1С. Вы передали им дампы?

Артем, а как можно с Вами связаться? Есть вопрос, связанный с эксплуатацией вашего продукта, который не хотелось бы обсуждать на форуме.
Мои контакты ICQ 252687304
почта gscobe_a_td12mes.ru

PS: Извините, если нарушаю какое то правило

Добрый день!
Ответил письмом. Что-то совсем тут тихо стало
Ответов мало.

Удачи!

ЗюЫю: Всем привет!