PostgreSQL 9.1 + 1С 8.2 = deadlock detected / PostgreSQL

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / PostgreSQL 9.1 + 1С 8.2 = deadlock detected

25 сообщений из 50, страница 1 из 2

все

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38881785

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С. Возможно ли это диагностировать с такой точностью? А то придёт слесарь, посмотрит, развернётся и уйдёт, хмыкнув маты себе под нос. Не хотелось бы с умным человеком ссориться из-за собственной некомпетентности.

...

Рейтинг:

0 / 0

17.02.2015, 14:37

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38881815

deadlock detected

Гость

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

...

Рейтинг:

0 / 0

17.02.2015, 14:59

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882186

deadlock detected

Гость

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

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

...

Рейтинг:

0 / 0

17.02.2015, 19:35

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882227

vyegorov

Участник

Откуда: Баньоло-ин-Пьяно

Сообщения: 1 237

Рейтинг: 0 / 0

deadlock detected,

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

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

...

Рейтинг:

0 / 0

17.02.2015, 21:07

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882264

ilejn

Участник

Откуда: Москва

Сообщения: 397

Рейтинг: 0 / 0

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

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

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

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

...

Рейтинг:

0 / 0

17.02.2015, 22:20

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882446

laskin82

Гость

Добрый день.

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

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

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

...

Рейтинг:

0 / 0

18.02.2015, 09:07

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882559

Nitro_Junkie

Участник

Сообщения: 935

Рейтинг: 0 / 0

laskin82Добрый день.

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

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

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

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

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

...

Рейтинг:

0 / 0

18.02.2015, 10:37

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882572

laskin82

Гость

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

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

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

...

Рейтинг:

0 / 0

18.02.2015, 10:46

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882609

Nitro_Junkie

Участник

Сообщения: 935

Рейтинг: 0 / 0

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

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

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

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

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

...

Рейтинг:

0 / 0

18.02.2015, 11:02

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882667

deadlock detected

Гость

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" - это фича, а не баг? :-/

...

Рейтинг:

0 / 0

18.02.2015, 11:43

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882675

Nitro_Junkie

Участник

Сообщения: 935

Рейтинг: 0 / 0

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

Правильно понимаете... Или если он чуть более чем тупой, скажет вам поставьте MS SQL, с версионниками 1С нормально работать не умеет.

ЗЫ: А с блокировочниками лучше вообще не работать :) Вот такой вот замкнутый круг :)

...

Рейтинг:

0 / 0

18.02.2015, 11:48

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882681

Nitro_Junkie

Участник

Сообщения: 935

Рейтинг: 0 / 0

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

Правильно понимаете... Или если он чуть более чем тупой, скажет вам поставьте MS SQL, с версионниками 1С нормально работать не умеет.

ЗЫ: А с блокировочниками лучше вообще не работать :) Вот такой вот замкнутый круг :)

Забыл добавить в автоматическом режиме. Так что можете его заставить переделать на ручной режим блокировок. Это же так просто и понятно по мнению 1С. Хотя при этом в обычном мире multi-threading программирование одно из самых сложных и ценных умений.

...

Рейтинг:

0 / 0

18.02.2015, 11:51

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882696

ilejn

Участник

Откуда: Москва

Сообщения: 397

Рейтинг: 0 / 0

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

MS SQL обеспечивает почти что SERIALIZABLE.
И разработчик 1С живет в этом удобном мире.

Так что есть такие варианты
1. Табличные блокировки, чтобы добиться того же уровня изоляции
2. Сознательное (не фантастически сложное) управление блокировками на уровне сущностей 1С.

Если Вы немного подумаете, то поймете, что "корректный откат транзакции "- это не метод.
Ну а "вообще уйти от этого дебильного блокировочника" если и метод, то очень радикальный.

...

Рейтинг:

0 / 0

18.02.2015, 12:04

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882702

deadlock detected

Гость

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

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

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

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

2. Оба писателя делают всякие проводки, списания, и всё остальное прочее, что позволяет делать 1С.

3. "Бухгалтерия для Казахстана 2.0.17.22".

4. Никаких тормозов нет и быть не может. Сервер с нуля - летает так, что эти жалкие 5 пользователей даже в самом пике нагружают его максимум на 5% от доступной процессорной, 60% от доступной оперативной, и 5% от дисковой подсистемы. Файл подкачки не задействован системой вовсе. Сама работа идёт в клиент-серверном режиме по гигабитной сети. Я сам впервые вижу такой низкий КПД, обычно у меня всё было наоборот: полсотни разъярённых пользователей, десятилетний сервер, файловый режим, и сеть в лучшем случае на 100 мегабит. Здесь идеальные условия, но одна база по непонятным причинам ведёт себя плохо, с чем я и желаю разобраться, потому что даже пенять не на что (кроме как на глупого себя).

5. 1С неудачно скрестили с PostgreSQL (или в принципе неудачно выбрали PostgreSQL в качестве СУБД - не суть важно). Работал ещё во времена "1С7 + SQL Server 2000" - никаких проблем не испытывал. Ничего плохого не говорю про PostgreSQL - я говорю плохое про тех, кто попытался PostgreSQL скрестить с 1С. Они и есть мутанты. А я теперь один из них.

...

Рейтинг:

0 / 0

18.02.2015, 12:06

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882712

deadlock detected

Гость

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

Правильно понимаете... Или если он чуть более чем тупой, скажет вам поставьте MS SQL, с версионниками 1С нормально работать не умеет.

ЗЫ: А с блокировочниками лучше вообще не работать :) Вот такой вот замкнутый круг :)
Ясно. Ок, пусть тогда пользователи мучаются дальше. На покупку Microsoft SQL Server у их руководства всё равно пока не сто и т.

Спасибо всем большое за ответы.

...

Рейтинг:

0 / 0

18.02.2015, 12:10

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882733

Nitro_Junkie

Участник

Сообщения: 935

Рейтинг: 0 / 0

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

MS SQL обеспечивает почти что SERIALIZABLE.
И разработчик 1С живет в этом удобном мире.

Так что есть такие варианты
1. Табличные блокировки, чтобы добиться того же уровня изоляции
2. Сознательное (не фантастически сложное) управление блокировками на уровне сущностей 1С.

Если Вы немного подумаете, то поймете, что "корректный откат транзакции "- это не метод.
Ну а "вообще уйти от этого дебильного блокировочника" если и метод, то очень радикальный.

Табличные блокировки как и блокировки по рядам на чтение (особенно на когда вешаются всю транзакцию при SERIALIZABLE) это очень опасная штука. Потому как ладно что долгий отчет повесит нафиг весь сервак (вон в 8.3 говорят уже делают мутанта когда именно отчеты по умолчанию в режиме версионника работают, хотя в 8.2 они вообще с NOLOCK'ом работают что еще хуже), любое "зависшее" проведение \ обработка нахватает локов, которые неизбежно повесят соседнее проведение \ обработку и т.д., то есть блокировки начнут накапливаться как снежный ком, пока сервак колом не встанет.

Собственно очень часто сталкивался со случаями, когда спрашивая почему вы всех пользователей 1С \ Аксапты \ Navision в одну базу не пустите, а разбиваете на кучу разных мелких баз, ответ один - пробовали, но из-за блокировок работать невозможно.

А корректный откат транзакции и ее перепроведение - очень даже метод. Я бы даже сказал самый эффективный из всех возможных.

...

Рейтинг:

0 / 0

18.02.2015, 12:28

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882738

ilejn

Участник

Откуда: Москва

Сообщения: 397

Рейтинг: 0 / 0

deadlock detected1. Оба пользователя - "писатели".

Убедитесь все-таки, что у них аккаунты одного типа.

deadlock detected2. Оба писателя делают всякие проводки, списания, и всё остальное прочее, что позволяет делать 1С.

Нужно локализовать тормоза и привязать их к бизнес-логике. Из логов Вы узнали, операции с какими таблицами приводят к deadlock, но этого мало.

deadlock detected4. Никаких тормозов нет и быть не может.

Вы очень по сисадмински рассуждаете. Если в среднем по больнице проблем нет, то это не значит, что какие-то операции нельзя ускорить.

deadlock detected5. 1С неудачно скрестили с PostgreSQL (или в принципе неудачно выбрали PostgreSQL в качестве СУБД - не суть важно). Работал ещё во времена "1С7 + SQL Server 2000" - никаких проблем не испытывал. Ничего плохого не говорю про PostgreSQL - я говорю плохое про тех, кто попытался PostgreSQL скрестить с 1С. Они и есть мутанты. А я теперь один из них.

Ваши эмоции можно понять и даже частично простить.

...

Рейтинг:

0 / 0

18.02.2015, 12:31

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882747

ilejn

Участник

Откуда: Москва

Сообщения: 397

Рейтинг: 0 / 0

ТС, вот здесь почитайте http://курсы-по-1с.рф/articles/режим-разделения-итогов/

Честно говоря, я так и не понял, поддержаны ли в Бухгалтерии для Казахстана управляемые блокировки.

...

Рейтинг:

0 / 0

18.02.2015, 12:36

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882768

laskin82

Гость

[quot deadlock detected]laskin82Добрый день.

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

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

Для вас варинты решения следующие:
1. Снять конфигурацию с поддержки и переключить режим на управляемый
2. Обновить конфигурацию до версии 3.0.1.4 (там реализован управляемый режим). Это вам лучше делать с помощью специалистов партнеров 1С.

...

Рейтинг:

0 / 0

18.02.2015, 12:47

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882833

ilejn

Участник

Откуда: Москва

Сообщения: 397

Рейтинг: 0 / 0

laskin821. Снять конфигурацию с поддержки и переключить режим на управляемый

Если конфигурация не управляет блокировками, то включение управляемого режима по факту выключает блокировки вообще.

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

...

Рейтинг:

0 / 0

18.02.2015, 13:33

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882884

laskin82

Гость

ilejnlaskin821. Снять конфигурацию с поддержки и переключить режим на управляемый

Если конфигурация не управляет блокировками, то включение управляемого режима по факту выключает блокировки вообще.

На основании чего сделан такой вывод?

...

Рейтинг:

0 / 0

18.02.2015, 14:13

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38882911

ilejn

Участник

Откуда: Москва

Сообщения: 397

Рейтинг: 0 / 0

laskin82На основании чего сделан такой вывод?

На основании знаний о том, как это работает.
Точнее, воспоминаниях о знаниях - дело было давно.

С точки зрения писателя конфигурации, управляемые блокировки - это конструкции языка. Они предписывают заблокировать ту или иную сущность 1С тем или иным образом. Поскольку у них мелкая гранулярность (не обязательно блокировать регистр целиком), управляемые блокировки позволяют достигать более высокого уровня параллелизма, чем автоматические.

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

Теперь Ваша очередь рассказывать почему Вы решили дать такой совет.

...

Рейтинг:

0 / 0

18.02.2015, 14:36

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38883002

laskin82

Гость

ilejn,

авторС точки зрения писателя конфигурации, управляемые блокировки - это конструкции языка.

Да, но это не значит, что если мы установили для конфигуарции управляемый режим блокировок и не написали ничего в коде, то блокировки перестают использоваться.

Управляемый режим - это дополнительный режим работы, позволяющий использовать собственный менеджер транзакционных блокировок 1С:Предприятия, независимый от используемой СУБД. В результате любой запрос к данным прежде всего обрабатывается собственным менеджером транзакционных блокировок 1С:Предприятия. Если на уровне 1С конфликт управляемых блокировок не обнаруживается, то запрос передается далее, на исполнение СУБД. СУБД также использует собственный механизм блокировок для определения конфликтующих транзакций, но уже с более низким уровнем изоляции транзакций, чем в режиме автоматических блокировок.

...

Рейтинг:

0 / 0

18.02.2015, 15:36

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38883013

Nitro_Junkie

Участник

Сообщения: 935

Рейтинг: 0 / 0

laskin82ilejn,
но уже с более низким уровнем изоляции транзакций

Что и означает что при конкурентном доступе к одним данным, агрегации могут "поплыть".

Ну то есть классика, оба считали 3, один добавил 2, другой 4, первый записал 5, второй перезаписал 7, а должно быть 9.

...

Рейтинг:

0 / 0

18.02.2015, 15:43

| Ответить | Цитировать | Написать

PostgreSQL 9.1 + 1С 8.2 = deadlock detected

#38883038

ilejn

Участник

Откуда: Москва

Сообщения: 397

Рейтинг: 0 / 0

laskin82Управляемый режим - это дополнительный режим работы, позволяющий использовать собственный менеджер транзакционных блокировок 1С:Предприятия, независимый от используемой СУБД. В результате любой запрос к данным прежде всего обрабатывается собственным менеджером транзакционных блокировок 1С:Предприятия. Если на уровне 1С конфликт управляемых блокировок не обнаруживается, то запрос передается далее, на исполнение СУБД. СУБД также использует собственный механизм блокировок для определения конфликтующих транзакций, но уже с более низким уровнем изоляции транзакций, чем в режиме автоматических блокировок.

То что Вы написали или процитировали не что чтобы неверно, но бессмысленно с практической точки зрения.
Те транзакции, которые не являются конфликтующими с точки зрения PostgreSQL'ного READ COMMITED, легко могут нарушать необходимый для 1C SERIALIZABLE.

Кстати, чтобы Вы понимали ситуацию, "собственный менеджер транзакционных блокировок 1С:Предприятия" писал я.

...

Рейтинг:

0 / 0

18.02.2015, 15:58

| Ответить | Цитировать | Написать

25 сообщений из 50, страница 1 из 2

все

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / PostgreSQL 9.1 + 1С 8.2 = deadlock detected

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=53&msg=38882559&tid=1998156]:	0ms
get settings:	8ms
get forum list:	15ms
check forum access:	3ms
check topic access:	3ms
track hit:	177ms
get topic data:	11ms
get forum data:	3ms
get page messages:	64ms
get tp. blocked users:	1ms
others:	204ms

total:	489ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы