PostgreSQL 9.1 + 1С 8.2 = deadlock detected

hard: Xeon E5-2420v2 2.20GHz, 120Gb SSD, 8Gb RAM
soft: Ubuntu Server 14.04.1 x86, PostgreSQL 9.1 (1С), 1С 8.2.19.116



Ребята, понимаю, что вас всех уже заколебали мутанты, избравшие данную СУБД в качестве основы для 1С, но я уже реально не знаю, куда мне ещё обратиться.



Есть десяток почти пустых баз данных (каждая примерно по 1-2 гигабайта) и пяток пользователей. Как водится, все базы работают нормально, но в семье не без урода - одна база хронически выпендривается. Содержание файла "/var/log/postgresql/postgresql-9.1-main.log" с момента включения под катом:

+

2015-02-17 06:01:05 MSCT ОТМЕТКА: загружена библиотека "online_analyze" 2015-02-17 06:01:05 MSCT ОТМЕТКА: загружена библиотека "plantuner" 2015-02-17 06:01:18 MSCT ОТМЕТКА: система БД была выключена: 2015-02-17 06:00:08 MSCT 2015-02-17 06:01:18 MSCT ВАЖНО: система баз данных запускается 2015-02-17 06:01:18 MSCT ОТМЕТКА: неполный стартовый пакет 2015-02-17 06:01:19 MSCT ОТМЕТКА: система БД готова принимать подключения 2015-02-17 06:01:19 MSCT ОТМЕТКА: процесс запуска автоочистки создан 2015-02-17 10:42:09 MSCT ОТМЕТКА: автоматическая очистка таблицы "MYDATABASE.pg_catalog.pg_class": получить исключительную блокировку для сканирования отсекаемых страниц не удалось 2015-02-17 14:05:10 MSCT ОТМЕТКА: автоматическая очистка таблицы "MYDATABASE.pg_catalog.pg_class": получить исключительную блокировку для сканирования отсекаемых страниц не удалось 2015-02-17 15:38:10 MSCT ОТМЕТКА: автоматическая очистка таблицы "MYDATABASE.pg_catalog.pg_class": получить исключительную блокировку для сканирования отсекаемых страниц не удалось 2015-02-17 15:41:47 MSCT ERROR: deadlock detected 2015-02-17 15:41:47 MSCT DETAIL: Process 27234 waits for ApplicationExclusiveLock on relation 2473436 of database 16949; blocked by process 3159. Process 3159 waits for ApplicationShareLock on relation 2460543 of database 16949; blocked by process 27234. Process 27234: SET STATEMENT_TIMEOUT TO 20000; LOCK _DocumentJournal3961 IN APPLICATION EXCLUSIVE MODE; SET STATEMENT_TIMEOUT TO DEFAULT; Process 3159: SET STATEMENT_TIMEOUT TO 20000; LOCK _AccRg5313 IN APPLICATION SHARE MODE; LOCK _AccRg5339 IN APPLICATION SHARE MODE; LOCK _AccumRg5101 IN APPLICATION SHARE MODE; LOCK _AccumRg5112 IN APPLICATION SHARE MODE; LOCK _AccumRg5133 IN APPLICATION SHARE MODE; LOCK _InfoRg4641 IN APPLICATION SHARE MODE; LOCK _InfoRg4682 IN APPLICATION SHARE MODE; SET STATEMENT_TIMEOUT TO DEFAULT; 2015-02-17 15:41:47 MSCT HINT: See server log for query details. 2015-02-17 15:41:47 MSCT STATEMENT: SET STATEMENT_TIMEOUT TO 20000; LOCK _DocumentJournal3961 IN APPLICATION EXCLUSIVE MODE; SET STATEMENT_TIMEOUT TO DEFAULT; 2015-02-17 15:42:32 MSCT ERROR: deadlock detected 2015-02-17 15:42:32 MSCT DETAIL: Process 3159 waits for ApplicationShareLock on relation 2460543 of database 16949; blocked by process 27234. Process 27234 waits for ApplicationExclusiveLock on relation 2473436 of database 16949; blocked by process 3159. Process 3159: SET STATEMENT_TIMEOUT TO 20000; LOCK _AccRg5313 IN APPLICATION SHARE MODE; LOCK _AccRg5339 IN APPLICATION SHARE MODE; LOCK _AccumRg5101 IN APPLICATION SHARE MODE; LOCK _AccumRg5112 IN APPLICATION SHARE MODE; LOCK _AccumRg5133 IN APPLICATION SHARE MODE; LOCK _InfoRg4641 IN APPLICATION SHARE MODE; LOCK _InfoRg4682 IN APPLICATION SHARE MODE; SET STATEMENT_TIMEOUT TO DEFAULT; Process 27234: SET STATEMENT_TIMEOUT TO 20000; LOCK _DocumentJournal3961 IN APPLICATION EXCLUSIVE MODE; SET STATEMENT_TIMEOUT TO DEFAULT; 2015-02-17 15:42:32 MSCT HINT: See server log for query details. 2015-02-17 15:42:32 MSCT STATEMENT: SET STATEMENT_TIMEOUT TO 20000; LOCK _AccRg5313 IN APPLICATION SHARE MODE; LOCK _AccRg5339 IN APPLICATION SHARE MODE; LOCK _AccumRg5101 IN APPLICATION SHARE MODE; LOCK _AccumRg5112 IN APPLICATION SHARE MODE; LOCK _AccumRg5133 IN APPLICATION SHARE MODE; LOCK _InfoRg4641 IN APPLICATION SHARE MODE; LOCK _InfoRg4682 IN APPLICATION SHARE MODE; SET STATEMENT_TIMEOUT TO DEFAULT; 2015-02-17 15:42:39 MSCT ERROR: deadlock detected 2015-02-17 15:42:39 MSCT DETAIL: Process 3159 waits for ApplicationShareLock on relation 2460473 of database 16949; blocked by process 27234. Process 27234 waits for ApplicationExclusiveLock on relation 2460543 of database 16949; blocked by process 3159. Process 3159: SET STATEMENT_TIMEOUT TO 20000; LOCK _AccRg5313 IN APPLICATION SHARE MODE; LOCK _AccRg5339 IN APPLICATION SHARE MODE; LOCK _AccumRg5101 IN APPLICATION SHARE MODE; LOCK _AccumRg5112 IN APPLICATION SHARE MODE; LOCK _AccumRg5133 IN APPLICATION SHARE MODE; LOCK _InfoRg4641 IN APPLICATION SHARE MODE; LOCK _InfoRg4682 IN APPLICATION SHARE MODE; SET STATEMENT_TIMEOUT TO DEFAULT; Process 27234: SET STATEMENT_TIMEOUT TO 20000; LOCK _AccRg5313 IN APPLICATION EXCLUSIVE MODE; SET STATEMENT_TIMEOUT TO DEFAULT; 2015-02-17 15:42:39 MSCT HINT: See server log for query details. 2015-02-17 15:42:39 MSCT STATEMENT: SET STATEMENT_TIMEOUT TO 20000; LOCK _AccRg5313 IN APPLICATION SHARE MODE; LOCK _AccRg5339 IN APPLICATION SHARE MODE; LOCK _AccumRg5101 IN APPLICATION SHARE MODE; LOCK _AccumRg5112 IN APPLICATION SHARE MODE; LOCK _AccumRg5133 IN APPLICATION SHARE MODE; LOCK _InfoRg4641 IN APPLICATION SHARE MODE; LOCK _InfoRg4682 IN APPLICATION SHARE MODE; SET STATEMENT_TIMEOUT TO DEFAULT; 2015-02-17 15:45:13 MSCT ОТМЕТКА: автоматическая очистка таблицы "MYDATABASE.pg_catalog.pg_class": получить исключительную блокировку для сканирования отсекаемых страниц не удалось 2015-02-17 15:46:13 MSCT ОТМЕТКА: автоматическая очистка таблицы "MYDATABASE.pg_catalog.pg_class": получить исключительную блокировку для сканирования отсекаемых страниц не удалось

Брыкается, напомню, только одна база. Все остальные работают прекрасно. В реальности же выпендрёж "MYDATABASE" выглядит так: пара пользователей, работающих именно с этой конкретной базой, начинают почти одновременно жаловаться на "дикие тормоза". Т.е. то, что ещё час-полтора-два назад выполнялось за считанные секунды, теперь начинает отнимать целые минуты. Какие-то проводки, списания, и прочее (я в этом не силён). Спустя полчаса-час жалобы прекращаются и работа возобновляется (остальные пользователи, работающие в это самое время с остальными базами, о проблемах этой парочки даже не в курсе - у них самих остальные базы шуршат отлично и без тормозов). Каждый день жалобы в разное время: то утром, то днём, то вечером. Системы какой-то не наблюдается. Содержание указанного выше лога за каждый день примерно одинаковое, с небольшой разницей по времени. Свободных вычислительных ресурсов, как вы понимаете, - вагон, такой сервер ещё грузить и грузить можно. Т.е. проблема явно не в "узком горлышке" каких-либо комплектующих. Уже склоняюсь к тому, чтобы звать программиста (проблема ведь с одной-единственной базой, остальные же работают и в логи не гадят), но мне прежде, чем вызывать слесаря по 1С, хотелось бы убедиться, что проблема 100% в 1С. Возможно ли это диагностировать с такой точностью? А то придёт слесарь, посмотрит, развернётся и уйдёт, хмыкнув маты себе под нос. Не хотелось бы с умным человеком ссориться из-за собственной некомпетентности.

Забыл добавить:
1. "Тестирование и исправление" в Конфигураторе 1С - не помогает.
2. Vacuum/Full непосредственно в СУБД - тоже.

Отключил все базы, кроме проблемной "MYDATABASE". Запустил в неё парочку пользователей (ту самую, которая вдвоём и мучается) - без изменений. В логах такой же срач. Т.е. остальные БД и пользователи уже точно не при чём.



Что ещё можно предпринять на моём месте, чтобы сузить поиски и ускорить локализацию проблемы?

deadlock detected,

Судя по логу, это особенность работы аппликации, которая явным образом блокирует таблицы, причем в разных местах приложения порядок блокировки таблиц разный, что и приводит к вашим deadlock'ам.

Я не думаю, что есть возможность что-то нашаманить на стороне базы. Может кто-то с опытом 1С подскажет.

Немного странно, что предполагаемая нехватка профессионализма мешает ТС вызвать слесаря по 1С, но не мешает называть мутантами тех, кто выбрал "данную СУБД в качестве основы для 1С".

Согласен с vyegorov - проблема на уровне приложения.
И, да, она будет проявляться только c PostgreSQL.
Тем не менее, довольно вероятно, что чем медленнее работает система, тем чаще возникает проблема. Поэтому если есть возможность сархивировать старые данные или сделать что-нибудь в этом духе - есть смысл.

Вы бы хоть намекнули, какая конфигурация используется.

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

Добрый день.

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

Если мои предположения верны, то у вас стоит режим - Автоматический. В таком случае
а) почитайте http://v8.1c.ru/overview/postgresql.htm
б) поймите http://v8.1c.ru/overview/datalockcontrol.htm

Будут вопросы - пишите

laskin82

Добрый день. 1. Уточните какая конфигурация используется (если типовая, то точная версия)? 2. Уточните какой режим управления блокировкой данных в транзакции по умолчанию установлен для конфигурации? (Посмотреть тут: Конфигуратор-Конфигурация-Свойства-Режим управления блокировкой) Если мои предположения верны, то у вас стоит режим - Автоматический. В таком случае а) почитайте http://v8.1c.ru/overview/postgresql.htm б) поймите http://v8.1c.ru/overview/datalockcontrol.htm Будут вопросы - пишите

У меня есть вопрос. Я правильно понимаю, что вместо того чтобы сделать нормальный корректный откат транзакции и использовать стандартные механизмы СУБД повышения уровня изоляции (с update-conflict'ами у версионникам, и вообще уйти от этого дебильного блокировочника), разработчики решили переложить ответственность за синхронизацию на, внимание, 1С разработчика (!). Человека, уровень которого предполагает работу в песочнице справочник-документ-регистр. Как грил недавно солнцеликий "они что с ума сошли"? Или есть какой-то другой скрытый мотив не поддерживать такой режим?

Кстати заодно - раз корректно откат транзакции не поддерживается, что 1С делает в автоматическом режиме с Dead Lock'ом?

Не совсем правильно понимаете.

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

Другими словами разработчику дается возможность дополнительно из кода управлять блокировками в случае необходимости (очень специфично). В большинстве случаев этого не требуется и платформа это берет на себя.

laskin82
Не совсем правильно понимаете. "Разработчику требуется управлять блокировками данных в тех случаях, когда бизнес-логика требует согласованного и целостного чтения данных в транзакции". Другими словами разработчику дается возможность дополнительно из кода управлять блокировками в случае необходимости (очень специфично). В большинстве случаев этого не требуется и платформа это берет на себя.

Необходимость возникает при любом конкурентном доступе, то есть чуть реже чем всегда?

Плюс для того же PostgreSQL "на себя" означает блокировку всей таблицы (то есть суперпессимистичный режим). А учитывая что даже обычный пессимистичный режим (с блокировкой по записям и возможностью эскалации до всей таблицы) очень опасная штука, так как обычное чтение при неправильно построенном или просто долгом запросе может нахрен повесить все проведения, то есть всю работу сервера, то можно считать что автоматического режима не существует. Точнее он для самоубийц или для баз на 5 пользователей.

laskin82

Добрый день. 1. Уточните какая конфигурация используется (если типовая, то точная версия)? 2. Уточните какой режим управления блокировкой данных в транзакции по умолчанию установлен для конфигурации? (Посмотреть тут: Конфигуратор-Конфигурация-Свойства-Режим управления блокировкой) Если мои предположения верны, то у вас стоит режим - Автоматический. В таком случае а) почитайте http://v8.1c.ru/overview/postgresql.htm б) поймите http://v8.1c.ru/overview/datalockcontrol.htm Будут вопросы - пишите

Приветствую.
Спасибо за отзыв!

Отвечаю:
1. Бухгалтерия для Казахстана 2.0.17.22 (вроде без каких-либо изменений со стороны нашей компании, но я не могу это гарантировать наверняка - я тут совсем новенький, а из стареньких никто ничего не помнит, как обычно).
2. Автоматический (и изменить никак не получается)

Открыл вторую ссылку, читаю вслух: "В автоматическом режиме управления блокировками данных используются уровни изоляции транзакций repeatable read и serializable, обеспечиваемые системой управления базами данных. Эти уровни изоляции транзакций обеспечивают согласованное и целостное чтение данных, и от разработчика не требуется каких-либо дополнительных действий по управлению блокировками.". Я так понимаю, мне слесаря по 1С даже беспокоить не стоит - он если и придёт, то всё равно безапелляционно заявит мне, что конкретно в моём случае "deadlock" - это фича, а не баг? :-/