|
Платформа 8.3 зависает при расчете (ЗКБУ) | ☑ | ||
---|---|---|---|---|
0
Squares
09.10.14
✎
10:34
|
Здравствуйте.
Есть проблема, о ней, писал на ЛК. Состоялась вот такая переписка (до сих пор продолжается т.к. проблема всё еще не решена). Подскажите как быть и что подкрутить. *Есть сервер на котором установлен 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 Все остальное соответствует до буквы. Но! Это все параметры производительности, а ошибка явно в взаимном обновлении двух таблиц!!! Я изменил настройки, как просите (пишите и перестартовал сервер. Может из-за более редкого сбора статистики и постоянного анализа не только временных, а всех таблиц (что только ресурсы жрет) будут какие-то изменения. Проверил, ничего не меняется. При расчете любого документа программа зависает и ошибка выходит (выскакивает окно с ошибкой) только тогда когда сеанс сбрасывается через консоль кластера иначе можно ждать вечность.» Переписка продолжается, но мне кажется, что она будет бесполезна, т.к. ЛК делает только отписки. Помогите советом. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |