Платформа 8.3 зависает при расчете (ЗКБУ) #722446

Здравствуйте. Есть проблема, о ней, писал на ЛК. Состоялась вот такая переписка (до сих пор продолжается т.к. проблема всё еще не решена). Подскажите как быть и что подкрутить.   *Есть сервер на котором установлен 1С:Сервер 8.3.5.1119:* Linux 1c1 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u1 x86_64 GNU/Linux Byte Order:            Little Endian NUMA node0 CPU(s):     0-7 ii  1c-enterprise83-common             8.3.5-1119 amd64        1C:Enterprise 8.3 common components ii  1c-enterprise83-common-nls         8.3.5-1119 amd64        National resource files for 1C:Enterpise 8.3 common components for Linux ii  1c-enterprise83-server             8.3.5-1119 amd64        1C:Enterprise 8.3 server for Linux ii  1c-enterprise83-server-nls         8.3.5-1119 amd64        National resource files for 1C:Enterpise 8.3 server for Linux ii  1c-enterprise83-ws                 8.3.5-1119 amd64        1C:Enterpise 8.3 Web-services components for Linux ii  1c-enterprise83-ws-nls             8.3.5-1119 amd64        National resource files for 1C:Enterpise 8.3 Web-services components for Linux ii  postgresql-9.2                     9.2.4-1.1C amd64        object-relational SQL database, version 9.2 server ii  postgresql-9.2-dbg                 9.2.4-1.1C amd64        debug symbols for postgresql-9.2 ii  postgresql-client-9.2              9.2.4-1.1C amd64        front-end programs for PostgreSQL 9.2 ii  postgresql-client-common           140~lucid                     all             manager for multiple PostgreSQL client versions ii  postgresql-common                  140~lucid                     all             PostgreSQL database-cluster manager ii  postgresql-contrib-9.2             9.2.4-1.1C amd64        additional facilities for PostgreSQL ii  postgresql-doc-9.2                 9.2.4-1.1C                    all             documentation for the PostgreSQL database management system ii  postgresql-plpython-9.2            9.2.4-1.1C amd64        PL/Python procedural language for PostgreSQL 9.2 ii  postgresql-plpython3-9.2           9.2.4-1.1C amd64        PL/Python 3 procedural language for PostgreSQL 9.2 ii  postgresql-pltcl-9.2               9.2.4-1.1C amd64        PL/Tcl procedural language for PostgreSQL 9.2 ii  postgresql-server-dev-9.2          9.2.4-1.1C amd64        development files for PostgreSQL 9.2 server-side programming *Конфигурация ЗКБУ 1,0,74,1. * *При попытке рассчитать какой-либо документ программа зависает. Эта ситуация проявляется только на **Linux в клиент-серверном варианте. Локально или на **Windows в любом варианте, ошибка не проявляется.* ** *Вот что делает сервер (**PostgreSQL) в момент зависания:* 2014-09-11 14:40:22 MSK ERROR:  canceling statement due to user request 2014-09-11 14:40:22 MSK STATEMENT:  DELETE FROM _CRgActP694                   FROM (SELECT 1 AS SDBL_DUMMY) SDBL_DUAL                   T4._RecorderTRef AS RecorderTRef,                   T4._RecorderRRef AS RecorderRRef,                   T4._LineNo AS LineNo_                   FROM _CRgActP694 T4                   INNER JOIN tt51 T5                   ON T4._RecorderTRef = T5._RecorderTRef AND T4._RecorderRRef = T5._RecorderRRef AND T4._LineNo = T5._LineNo LIMIT 100000) T3                   ON _CRgActP694._RecorderTRef = T3.RecorderTRef AND _CRgActP694._RecorderRRef = T3.RecorderRRef AND _CRgActP694._LineNo = T3.LineNo _                   WHERE _CRgActP694._RecorderTRef = T3.RecorderTRef AND _CRgActP694._RecorderRRef = T3.RecorderRRef AND _CRgActP694._LineNo = T3.Lin eNo_) 2014-09-11 14:47:30 MSK ERROR:  canceling statement due to user request 2014-09-11 14:47:30 MSK STATEMENT:  DELETE FROM _CRgActP694                   FROM (SELECT 1 AS SDBL_DUMMY) SDBL_DUAL                   T4._RecorderTRef AS RecorderTRef,                   T4._RecorderRRef AS RecorderRRef,                   T4._LineNo AS LineNo_                   FROM _CRgActP694 T4                   INNER JOIN tt45 T5                   ON T4._RecorderTRef = T5._RecorderTRef AND T4._RecorderRRef = T5._RecorderRRef AND T4._LineNo = T5._LineNo LIMIT                   ON _CRgActP694._RecorderTRef = T3.RecorderTRef AND _CRgActP694._RecorderRRef = T3.RecorderRRef AND _CRgActP694._LineNo =                   WHERE _CRgActP694._RecorderTRef = T3.RecorderTRef AND _CRgActP694._RecorderRRef = T3.RecorderRRef AND _CRgActP694._LineNo = T3.Lin eNo_) 2014-09-11 14:50:57 MSK ERROR:  canceling statement due to user request 2014-09-11 14:50:57 MSK STATEMENT:  DELETE FROM _CRgActP694                   FROM (SELECT 1 AS SDBL_DUMMY) SDBL_DUAL                   T4._RecorderTRef AS RecorderTRef,                   T4._RecorderRRef AS RecorderRRef,                   T4._LineNo AS LineNo_                   FROM _CRgActP694 T4                   INNER JOIN tt48 T5                   ON T4._RecorderTRef = T5._RecorderTRef AND T4._RecorderRRef = T5._RecorderRRef AND T4._LineNo = T5._LineNo LIMIT                   ON _CRgActP694._RecorderTRef = T3.RecorderTRef AND _CRgActP694._RecorderRRef = T3.RecorderRRef AND _CRgActP694._LineNo =                   WHERE _CRgActP694._RecorderTRef = T3.RecorderTRef AND _CRgActP694._RecorderRRef = T3.RecorderRRef AND _CRgActP694._LineNo = T3.Lin eNo_) 2014-09-11 14:53:27 MSK ERROR:  canceling statement due to user request 2014-09-11 14:53:27 MSK STATEMENT:  DELETE FROM _CRgActP694                   FROM (SELECT 1 AS SDBL_DUMMY) SDBL_DUAL                   T4._RecorderTRef AS RecorderTRef,                   T4._RecorderRRef AS RecorderRRef,                   T4._LineNo AS LineNo_                   FROM _CRgActP694 T4                   INNER JOIN tt33 T5                   ON T4._RecorderTRef = T5._RecorderTRef AND T4._RecorderRRef = T5._RecorderRRef AND T4._LineNo = T5._LineNo LIMIT                   ON _CRgActP694._RecorderTRef = T3.RecorderTRef AND _CRgActP694._RecorderRRef = T3.RecorderRRef AND _CRgActP694._LineNo =                   WHERE _CRgActP694._RecorderTRef = T3.RecorderTRef AND _CRgActP694._RecorderRRef = T3.RecorderRRef AND _CRgActP694._LineNo = T3.Lin eNo_) *Я проверил, все объекты базы есть. Возникает дедлок в самом 1С сервере. Т.е. не база данных дедлочит, а 1С сервер в своих внутренних структурах.* *По коду 1С зависание происходит по выходу(окончании) из процедуры:* *> РегистрРасчетов.ОсновныеНачисленияРаботниковОрганизаций (модуль *В теле этой процедуры есть только:* *Если данный код закомментировать то ничего не меняется (т.е. проблема в самой транзакции)*> ** *Мой вывод: Получается зависание по началу транзакции (она начинается по окончании  исполнения кода 1С на клиенте)* *Подскажите пожалуйста как решить эту проблему самостоятельно или в какой версии платформы это будет исправлено.* Ответ 1С: Добрый день. Спасибо за Ваше обращение в 1С. Меня зовут Роман, я инженер технической поддержки и я принял Ваш инцидент в работу. При ответе просьба указывать номер инцидента  SW877126 в ТЕМЕ письма. Насколько я вижу Вы используете ОС  Debian 3.2.60. Данная операционная система не поддерживается сервером 1С предприятия. Просьба использовать дистрибутивы из списка v8.1c.ru/requirements/. »» Если после обновления проблемма будет возникать ,сообщите, будем собирать технологическую информацию для анализа. Мой ответ: Приветствую! Я долго смотрел на письмо и у меня выросли ослиные уши: Дело в том, что на сайте сказано, цитирую: "Debian GNU/Linux 4.0 и выше только на рабочих и центральных серверах кластера" У нас - Debian GNU/Linux 7.0 и рабочий и центральный сервер кластера. Кроме того, он единственный. Т.е. письмо - чистой воды "отписка". Я еще раз проверил все требования и версии пакетов и не нашел никаких противопоказаний. Даже переустановил для профилактики сервисные пакеты, требуемые для 1С.» Возвращаемся к вопросу из письма №1: - «Подскажите пожалуйста как решить эту проблему самостоятельно или в какой версии платформы это будет исправлено.» Ответ 1С: добрый день. - В изначальном письме не было указание на версию debian. - Тюнинг postgresql проводился? Мой ответ: «Да, тюнинг PostgresSQL производился в соответствии с рекомендациями и настройками других серверов. Если речь про deadlock (вместо 1 секунды по-умолчанию) Если необходимо, то могу все настройки вернуть в настройки по-умолчанию. Но я это делал и это не помогает.» Ответ 1С: *добрый день.* *У Вас, как у партнера, есть доступ к партнерской конференции. Там тюнинг postgresql и его производительность обсуждаются очень активно.* *Вот что нашел за 10 минут. * /Просьба, предварительно проводить первичный поиск по доступным Вам Мой ответ: «В наших настройках: default_statistics_target = 100 переделал на 5000 checkpoint_completion_target = 0.5 сделал 0.9 Все остальное соответствует до буквы. Но! Это все параметры производительности, а ошибка явно в взаимном обновлении двух таблиц!!! Я изменил настройки, как  просите (пишите и перестартовал сервер. Может из-за более редкого сбора статистики и постоянного анализа не только временных, а всех таблиц (что только ресурсы жрет) будут какие-то изменения. Проверил, ничего не меняется. При расчете любого документа программа зависает и ошибка выходит (выскакивает окно с ошибкой) только тогда когда сеанс сбрасывается через консоль кластера иначе можно ждать вечность.» Переписка продолжается, но мне кажется, что она будет бесполезна, т.к. ЛК делает только отписки. Помогите советом.