ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / pgq deadlock
14 сообщений из 14, страница 1 из 1
pgq deadlock
    #38933037
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
Всем привет
PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit

pgq 3.1.0.0

Есть функции, время выполнения которых десятки минут.
Источником данных для функции являются pgq очереди.

Сегодня произошел deadlock при работе с pgq.
Вроде как pgq.finish_batch и pgq.ticker() законфликтовали
ниже лог:
 

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
Apr  9 22:47:12 stat-web postgres[59567]: [67-1] 2015-04-09 22:47:12 UTC [59567]: [37-1]LOG:  process 59567 detected deadlock while waiting for ShareLock on transaction 241122026 after 1000.118 ms
Apr  9 22:47:12 stat-web postgres[59567]: [67-2] 2015-04-09 22:47:12 UTC [59567]: [38-1]CONTEXT:  SQL statement "SELECT 1 FROM ONLY "pgq"."queue" x WHERE "queue_id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x"
Apr  9 22:47:12 stat-web postgres[59567]: [67-3]        SQL statement "update pgq.subscription
Apr  9 22:47:12 stat-web postgres[59567]: [67-4]                set sub_active = now(),
Apr  9 22:47:12 stat-web postgres[59567]: [67-5]                    sub_last_tick = sub_next_tick,
Apr  9 22:47:12 stat-web postgres[59567]: [67-6]                    sub_next_tick = null,
Apr  9 22:47:12 stat-web postgres[59567]: [67-7]                    sub_batch = null
Apr  9 22:47:12 stat-web postgres[59567]: [67-8]                where sub_batch = x_batch_id"
Apr  9 22:47:12 stat-web postgres[59567]: [67-9]        PL/pgSQL function pgq.finish_batch(bigint) line 19 at SQL statement
Apr  9 22:47:12 stat-web postgres[59567]: [67-10]       SQL statement "SELECT pgq.finish_batch(_batch_id)"
Apr  9 22:47:12 stat-web postgres[59567]: [67-11]       PL/pgSQL function actualize_from_queue(integer) line 64 at PERFORM
Apr  9 22:47:12 stat-web postgres[59567]: [67-12]       SQL statement "SELECT actualize.actualize_from_queue(_actualize_table_id)"
Apr  9 22:47:12 stat-web postgres[59567]: [67-13]       PL/pgSQL function table_actualize(text) line 12 at SQL statement
Apr  9 22:47:12 stat-web postgres[59567]: [67-14]       SQL statement "SELECT actualize.table_actualize('actualize.hotel_basis')"
Apr  9 22:47:12 stat-web postgres[59567]: [67-15]       PL/pgSQL function event_core.called_per_hour(text) line 36 at EXECUTE statement
Apr  9 22:47:12 stat-web postgres[59567]: [67-16] 2015-04-09 22:47:12 UTC [59567]: [39-1]STATEMENT:  --Cron: cron_for_postgres2;
Apr  9 22:47:12 stat-web postgres[59567]: [67-17]
Apr  9 22:47:12 stat-web postgres[59567]: [67-18]                       set timezone to 'utc';
Apr  9 22:47:12 stat-web postgres[59567]: [67-19]                       SET work_mem to '4GB';
Apr  9 22:47:12 stat-web postgres[59567]: [67-20]                       select * from event_core.called_per_hour('hotel_basis');
Apr  9 22:47:12 stat-web postgres[59567]: [67-21]
Apr  9 22:47:12 stat-web postgres[70537]: [37-1] 2015-04-09 22:47:12 UTC [70537]: [14-1]LOG:  process 70537 acquired ShareLock on transaction 241122019 after 70478.634 ms
Apr  9 22:47:12 stat-web postgres[70537]: [37-2] 2015-04-09 22:47:12 UTC [70537]: [15-1]CONTEXT:  SQL statement "update pgq.queue
Apr  9 22:47:12 stat-web postgres[70537]: [37-3]               set queue_switch_step2 = txid_current()
Apr  9 22:47:12 stat-web postgres[70537]: [37-4]             where queue_switch_step2 is null"
Apr  9 22:47:12 stat-web postgres[70537]: [37-5]        PL/pgSQL function pgq.maint_rotate_tables_step2() line 9 at SQL statement
Apr  9 22:47:12 stat-web postgres[70537]: [37-6] 2015-04-09 22:47:12 UTC [70537]: [16-1]STATEMENT:  select pgq.maint_rotate_tables_step2()
Apr  9 22:47:12 stat-web postgres[70537]: [38-1] 2015-04-09 22:47:12 UTC [70537]: [17-1]LOG:  duration: 70479.510 ms  statement: select pgq.maint_rotate_tables_step2()
Apr  9 22:47:12 stat-web postgres[[58316]]: [37-1] 2015-04-09 22:47:12 UTC [[58316]]: [13-1]LOG:  process [58316] acquired ShareLock on transaction 241122026 after 68684.520 ms
Apr  9 22:47:12 stat-web postgres[[58316]]: [37-2] 2015-04-09 22:47:12 UTC [[58316]]: [14-1]CONTEXT:  SQL statement "SELECT 1 FROM ONLY "pgq"."queue" x WHERE "queue_id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x"
Apr  9 22:47:12 stat-web postgres[[58316]]: [37-3]        SQL statement "insert into pgq.tick (tick_queue, tick_id, tick_event_seq)
Apr  9 22:47:12 stat-web postgres[[58316]]: [37-4]                values (q.queue_id, nextval(q.queue_tick_seq), q.event_seq)"
Apr  9 22:47:12 stat-web postgres[[58316]]: [37-5]        PL/pgSQL function pgq.ticker(text) line 94 at SQL statement
Apr  9 22:47:12 stat-web postgres[[58316]]: [37-6]        PL/pgSQL function pgq.ticker() line 21 at IF
Apr  9 22:47:12 stat-web postgres[[58316]]: [37-7] 2015-04-09 22:47:12 UTC [[58316]]: [15-1]STATEMENT:  select pgq.ticker()
Apr  9 22:47:12 stat-web postgres[59567]: [68-1] 2015-04-09 22:47:12 UTC [59567]: [40-1]LOG:  duration: 70691.493 ms  statement: --Cron: cron_for_postgres2;
Apr  9 22:47:12 stat-web postgres[59567]: [68-2]
Apr  9 22:47:12 stat-web postgres[59567]: [68-3]                        set timezone to 'utc';
Apr  9 22:47:12 stat-web postgres[59567]: [68-4]                        SET work_mem to '4GB';
Apr  9 22:47:12 stat-web postgres[59567]: [68-5]                        select * from event_core.called_per_hour('hotel_basis');
Apr  9 22:47:12 stat-web postgres[59567]: [68-6]
Apr  9 22:47:12 stat-web postgres[[58316]]: [38-1] 2015-04-09 22:47:12 UTC [[58316]]: [16-1]LOG:  duration: 68696.808 ms  statement: select pgq.ticker()
Apr  9 22:47:12 stat-web postgres[70537]: [39-1] 2015-04-09 22:47:12 UTC [70537]: [18-1]LOG:  disconnection: session time: 0:02:01.850 user=skytools database=stat host=10.21.0.25 port=41326
Apr  9 22:47:13 stat-web postgres[59567]: [69-1] 2015-04-09 22:47:13 UTC [59567]: [41-1]LOG:  could not receive data from client: Connection reset by peer
Apr  9 22:47:13 stat-web postgres[59567]: [70-1] 2015-04-09 22:47:13 UTC [59567]: [42-1]LOG:  disconnection: session time: 0:47:09.024 user=postgres database=stat host=127.0.0.1 port=37775
...
Рейтинг: 0 / 0
10.04.2015, 13:39
| Ответить | Цитировать | Написать  
pgq deadlock
    #38933064
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
Gold_,

offtop

Код: sql
1.
OPERATOR(pg_catalog.=)


-- вы перекрыли системный "=" для int/bigint-а ? а назачем ?

я как -то накатил intarray -- и то плевался -- всю динамику пришлось переписывать на "OPERATOR(pg_catalog" -- проклял гурьев теодора и олега. а вы -- своей смертью -- да этакое.
...
Рейтинг: 0 / 0
10.04.2015, 13:58
| Ответить | Цитировать | Написать  
pgq deadlock
    #38933083
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
qwwq-- вы перекрыли системный "=" для int/bigint-а ? а назачем ?


нет. Работает системное "="
...
Рейтинг: 0 / 0
10.04.2015, 14:21
| Ответить | Цитировать | Написать  
pgq deadlock
    #38933618
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
Gold_,

> pgq.maint_rotate_tables_step2()

эта штука насквозь апдейтит очереди.
а тикер тикает на все очереди. где-то там случилось всё похоже (там fk с тиков на очереди).

ордер бай там расставить что ли.

хотя я, если честно, пока не вижу точно (ночь может), при чем ту finish_batch и его блокировки. хотя, он ждет апдейта (rotate), а апдейт и tick сами себя друг друг ждут.

таких штук не видел раньше.

найди в логе, кто в итоге то отвалился по исключению deadlock а
...
Рейтинг: 0 / 0
11.04.2015, 02:29
| Ответить | Цитировать | Написать  
pgq deadlock
    #38933622
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
хотя они там могут и вперемешку ждать, например, finish успел попасть между взаимной блокировкой rotate и tick.

например, finish (хочет share на queue через fk при update subscription) начал ждать rotate (update queue),
в этот момент tick (хочет share на queue при insert в tick) уже ждал rotate, но и взял уже себе блокировок,
которых далее начал ждать сам rotate, т. е. и rotate начал ждать tick -- вот и приехали. // ну или вариант наоборот между tick и rotate.

походу точно надо ордер бай по queue_name или queue_id и в tick и в rotate при выборе очередей.

там у вех времена (duration) по 70 секунд примерно были, всё в одно время завязалось.
...
Рейтинг: 0 / 0
11.04.2015, 02:52
| Ответить | Цитировать | Написать  
pgq deadlock
    #38933655
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Gold_,

Вопросы
1)ваши хранимки случайно не пытаются с несколькими очередями одновременно работать в пределах 1 вызова или одной транзакции?
2)ваши хранимки случайно не пытаются несколько батчей за один вызов отработать в пределах 1 вызова или одной транзакции?

Любой из этих вариантов является неверным использованием PGQ.

PS: конкретно этот deadlock вылечится при переходе на 9.3+ версию так как это как раз случай:
=======================================
Prevent non-key-field row updates from blocking foreign key checks (Álvaro Herrera, Noah Misch, Andres Freund, Alexander Shulgin, Marti Raudsepp, Alexander Shulgin)

This change improves concurrency and reduces the probability of deadlocks when updating tables involved in a foreign-key constraint. UPDATEs that do not change any columns referenced in a foreign key now take the new NO KEY UPDATE lock mode on the row, while foreign key checks use the new KEY SHARE lock mode, which does not conflict with NO KEY UPDATE. So there is no blocking unless a foreign-key column is changed.
=======================================


--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
11.04.2015, 08:26
| Ответить | Цитировать | Написать  
pgq deadlock
    #38934829
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
Misha Tyurin,

спасибо на помощь

[quot Maxim Boguk]Gold_,

Вопросы
1)ваши хранимки случайно не пытаются с несколькими очередями одновременно работать в пределах 1 вызова или одной транзакции?
2)ваши хранимки случайно не пытаются несколько батчей за один вызов отработать в пределах 1 вызова или одной транзакции?

Любой из этих вариантов является неверным использованием PGQ.

PS: конкретно этот deadlock вылечится при переходе на 9.3+ версию так как это как раз случай:


Да для обоих вопросов.
- хранимка работает до первого не пустого батча.
- хранимка с двумя очередями: если одна очередь не имеет батчей - начинает работать со второй.
...
Рейтинг: 0 / 0
13.04.2015, 13:34
| Ответить | Цитировать | Написать  
pgq deadlock
    #38934873
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
Gold_,

я тут посмотрел и понял, что сломали всё в 3-ем скайтулзе (мы, в авито, на втором сидим).

как сломали -- чуть более, чем было "надломано" во 2-ом.

во втором не было сортировки и при ticker и при rotate -- и оно сексканом с очень большой вероятностью выбиралось в одном порядке и там и там -- следовательно и локи брались в одном порядке, дедлока практически не случалось!
а в третьем зачем-то добавили ордер бай при ticker. ну и порядок взятия локов разошелся -- вероятность дедлоков драматически выросла!

ссылки
было:
https://github.com/markokr/skytools/blob/skytools_2_1_stable/sql/pgq/functions/pgq.ticker.sql#L82 -- ! нет ордера
https://github.com/markokr/skytools/blob/skytools_2_1_stable/sql/pgq/functions/pgq.maint_rotate_tables.sql#L104 -- нет ордера
стало:
https://github.com/markokr/skytools/blob/master/sql/pgq/functions/pgq.ticker.sql#L156 -- ! ордер
https://github.com/markokr/skytools/blob/master/sql/pgq/functions/pgq.maint_rotate_tables.sql#L113 -- не поменялось


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

--
в 93+ оно конечно по-другому, как писал Максим, но я не 146% доверяю всему этому:)
...
Рейтинг: 0 / 0
13.04.2015, 13:59
| Ответить | Цитировать | Написать  
pgq deadlock
    #38934914
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
Misha Tyurin,

Самый быстрый способ "подлечить" - убрать сортировку как во втором skytools? )
...
Рейтинг: 0 / 0
13.04.2015, 14:29
| Ответить | Цитировать | Написать  
pgq deadlock
    #38934961
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
Gold_,

ну можно попробовать так, да.
...
Рейтинг: 0 / 0
13.04.2015, 14:58
| Ответить | Цитировать | Написать  
pgq deadlock
    #38935060
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
Misha Tyurin,

Либо в maint_rotate_tables_step2 делать UPDATE по одной записи в нужном порядке?
Что по Вашему лучше?
...
Рейтинг: 0 / 0
13.04.2015, 16:13
| Ответить | Цитировать | Написать  
pgq deadlock
    #38935128
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Misha Tyurin
Участник
Gold_,

порядок при ротейте нужен такой же, как и при тике. а уж по одной или по две -- даз нот маттер эт олл
...
Рейтинг: 0 / 0
13.04.2015, 16:53
| Ответить | Цитировать | Написать  
pgq deadlock
    #38935147
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Gold_Misha Tyurin,

Либо в maint_rotate_tables_step2 делать UPDATE по одной записи в нужном порядке?
Что по Вашему лучше?

Проще обновится до 9.4.1.

PS: работать не на (пред)последних минорных версиях базы - к проблемам (это я про 9.2.4 когда текущая 9.2.10) и винить будет некого.

--
Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
13.04.2015, 17:04
| Ответить | Цитировать | Написать  
pgq deadlock
    #38935272
Gold_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gold_
Гость
Misha Tyurin,
Maxim Boguk,



спасибо.

зы
Обновление запланировали, но будет не скоро
...
Рейтинг: 0 / 0
13.04.2015, 19:35
| Ответить | Цитировать | Написать  
14 сообщений из 14, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / pgq deadlock
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&msg=38933064&tid=1998047]:
 0ms
get settings:
 8ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 145ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 48ms
get tp. blocked users:
 1ms
others: 211ms
total:  444ms
созд. / загр.: 444ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]