Дедлоки, PostgreSQL и ЦУП #780568

Господа, такая ситуация: есть УТ 10.3, в которой работает 10-15 пользователей. Когда файловая база уперлась в размер, перешли на PostgreSQL. На нем? при проведении заказа покупателя? стали периодически выскакивать дедлоки. Поставил ЦУП, посмотрел ошибки. Все ошибки в выполнении запросов в обработках. Посмотрел, ни одна из них не записывает документы, т.е. по идее ничего блокировать не должна. В связи с чем вопрос: поможет ли ускорение запросов в борьбе с дедлоками или надо смириться и перейти на MS SQL?

Пару статей с ТВКВ по тюнингу Постгри применил уже?

Админ постгрю ставил и админит. Если дадите ссылку на статьи - дам ему почитать.

И вообще все, что выходит в поиске по ИТС по слову "postgresql"

спасибо, передам ссылки. А по сабжу что скажете? Там есть запрос, который выполняется 2400 секунд, но выполняется фоном и по факту никому не мешает. Может он на дедлоки как-то вилять?

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

классические :)

спасибо, увеличить время на блокировки попробую

по сабжу можно сказать, что с момента выхода УТ 10.3 много воды уже утекло. И платформа обновлялась и постгри обновлялся и типовая 10.3 тоже обновлялась - насколько там кривой запрос или насколько он криво обрабатывается на твоей субд сейчас?

платформа 8.3.7, конфа достаточно старая (jn 30/10/2014u) и сильно переписанная, ПГ самый свежий. Запросы достаточно кривые (судя по времени выполнениия), но они просто получают данные и потом их в одном случае сохраняют в эксель, Во втором отправляютна сайт, т.е. заказ покупателя, по которому лезут дедлоки не задевают совсем

Ставлю на то, что лочится таблица регистрации изменений

В логах постгри посмотри, какая таблица во время дедлока блочится. Будет что-то типа LOCK _AccumReg456 IN APPLICATION EXCLUSIVE MODE

see server log

Посмотрел лог, блочится много чего, но в основном основная таблица заказов покупателя (Document134)

ну раз пошла такая пьянка - режь последний огурец! Если не трудно, можешь показать текст запроса, который документ блочит? Просто интересно некоторые свои догадки проверить.

А на управляемые блокировки же уже перешли?

вряд ли. поэтому я и выпрашиваю текст запроса.

а где его найти? нет, конечно

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

Ну главное впихнуть немного кода в места где важен контроль остатков.

читал по этому поовду мануалы. Я так понял, там надо все регистры заказа покупателя переводить в управляемый режим и потмо во всех остальных документах-регистраторах этих регистров тоже переходить на управляемый режим. Т.е. я всю конфу в итоге переведу на управляемые блокировки. Это тоже вариант, но пока ищу пути по проще

добавить в запросы "для изменения"

при проведении заказа покупателя я запросом не обращаюсь к таблице заказов, т.е. нет запроса, куда можно вписать "Для изменения". Если я правильно вас понял

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

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

нет, обработки классические, из ветки "Обработки". Самый долгий запрос выглядит вот так:

Результат анализа ЦУПа: В первый запрос из скриншота

извиняюсь, какой-то бред. Обращения к виртуальным таблицам срезов последних и остатков мало того, что долго выполняется на этом сервере, но еще и блочит регистраторы. Так еще окажется, что Заказы покупателя просто такой документ, который используют чаще всего, а не потому, что он чем-то хуже остальных, которые используются просто реже.

так может не запросы блочат таблицы не запросы, а просто заказы часто проводят и они сами друг друга блочат? PG же блокирует всю таблицу

постгре от файловой мало чем отличается по блокировкам

в файловой не было проблем с блокировками

тогда размер просто меньше был

Режим совместимости какой стоит?

Это не блокировки, а длительные запросы

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

8.2.13 вот я в и спрашивал, поможет ли исправление в борьбе с дедлоками

перейди хотя бы на 8.2.14 там константы по другому хранятся

вообще пока ниодного дедлока ты не предоставил здесь. делдлок - это 2 блокировки минимум

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

с каким журналом это сопоставить?

перейду

Открыл щас типовую УТ 10.3, самую новую. там тоже 8.2.13. М.б. не стоит переходить на 8.2.14? Разрабы. поди,не зря остались на текущей совместимости

ну не хочешь не переходи.

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

и пост тоже - увеличить ожидание

На дедлоки это не распространяется

увеличил ожидание с 20 секунд до 40, не помогло. Инфу с ИТСа по настройкам скинул админу, читает пока. А я попутно ищу, что на стороне 1с могу сделать

я к тому, что не повалится ли что-нибудь после перехода? ИЛи разрабы тупо забыли поменять совместимостЬ?

может конечно

в 8.2.14 нельзя сериализовть половину данных, что в 8.2.13 можно было

Там есть параметр deadlock_timeout = 1s попробуй поменять на 2s Больше 2 секунд не не ставь.

тогда я посижу на текущей версии совместимости :) Ок, попробую, спасибо

deadlock_timeout отключен сейчас

Он не отключен, просто если параметр закомментирован, то по-умолчанию действует указанный параметр, т.е. 1s.

И еще - ставьте актуальную версию PostgreSQL отсюда: PostgreSQL 9.4.9 для 8.3.7 Если ставили под Windows, то по-умолчанию при установке предлагается оптимизировать конфиг автоматически. Ну а далее по-необходимости уже тюнить ручками.

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

понял, поставил 2s. PostgreSQL как раз по этой ссылке и качали. учту и поищу такие моменты, спасибо!

Дедлоск не решается таймаутом

с 1С 1 секунды явно недостаточно, практикой проверено.