Здравствуйте.

Есть проблема, о ней, писал на ЛК. Состоялась вот такая переписка (до сих пор продолжается т.к. проблема всё еще не решена). Подскажите как быть и что подкрутить.

  *Есть сервер на котором установлен 1С:Сервер 8.3.5.1119:*

  nanthony@1c1:~$ uname -a

Linux 1c1 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u1 x86_64 GNU/Linux

nanthony@1c1:~$ lscpu

Architecture:          x86_64

CPU op-mode(s):        32-bit, 64-bit

Byte Order:            Little Endian

CPU(s):                8

On-line CPU(s) list:   0-7

Thread(s) per core:    1

Core(s) per socket:    1

Socket(s):             8

NUMA node(s):          1

Vendor ID:             GenuineIntel

CPU family:            6

Model:                 2

Stepping:              3

CPU MHz:               2394.268

BogoMIPS:              4788.53

Hypervisor vendor:     KVM

Virtualization type:   full

L1d cache:             32K

L1i cache:             32K

L2 cache:              4096K

NUMA node0 CPU(s):     0-7

root@1c1:~# cat /proc/meminfo

MemTotal:       33019456 kB

root@1c1:~# dpkg -l | egrep "enterprise|postgre"

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

                WHERE EXISTS(

                  SELECT 1

                  FROM (SELECT 1 AS SDBL_DUMMY) SDBL_DUAL

                  INNER JOIN (SELECT

                  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

                  WHERE EXISTS(

                  SELECT 1

                  FROM (SELECT 1 AS SDBL_DUMMY) SDBL_DUAL

                  INNER JOIN (SELECT

                  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

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:50:57 MSK ERROR:  canceling statement due to user

request

2014-09-11 14:50:57 MSK STATEMENT:  DELETE FROM _CRgActP694

                  WHERE EXISTS(

                  SELECT 1

                  FROM (SELECT 1 AS SDBL_DUMMY) SDBL_DUAL

                  INNER JOIN (SELECT

                  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

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:53:27 MSK ERROR:  canceling statement due to user

request

2014-09-11 14:53:27 MSK STATEMENT:  DELETE FROM _CRgActP694

                  WHERE EXISTS(

                  SELECT 1

                  FROM (SELECT 1 AS SDBL_DUMMY) SDBL_DUAL

                  INNER JOIN (SELECT

                  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

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_)



*Я проверил, все объекты базы есть. Возникает дедлок в самом 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

deadlock_timeout = 2s

(вместо 1 секунды по-умолчанию)



Если необходимо, то могу все настройки вернуть в настройки по-умолчанию.

Но я это делал и это не помогает.»



Ответ 1С:

*добрый день.*



*У Вас, как у партнера, есть доступ к партнерской конференции. Там

тюнинг postgresql и его производительность обсуждаются очень активно.*

*Вот что нашел за 10 минут. *

*Обсуждение 1126960 »»

*enable_nestloop=off. *

*default_statistics_target = 5000*

Сообщение 1278095 »»

standard_conforming_strings = off'

Сообщение 1234685 »»

online_analyze.table_type = 'all'

/shared_buffers = 2048MB /

/join_collapse_limit = 1 /

/autovacuum_vacuum_threshold = 1800/

/deadlock_timeout = 2s /

/constraint_exclusion = on /

/checkpoint_completion_target = 0.9/

/wal_buffers = 16MB/

/maintenance_work_mem = 1024MB/

//

/Просьба, предварительно проводить первичный поиск по доступным Вам

ресурсам.///


Мой ответ:

«В наших настройках:

default_statistics_target = 100 переделал на 5000 checkpoint_completion_target = 0.5 сделал 0.9

Все остальное соответствует до буквы.

Но! Это все параметры производительности, а ошибка явно в взаимном обновлении двух таблиц!!!

Я изменил настройки, как  просите (пишите и перестартовал сервер.

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

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


Переписка продолжается, но мне кажется, что она будет бесполезна, т.к. ЛК делает только отписки. Помогите советом.