PostgreSQL - блокировки таблицы IDS

[sersad]

Самое неприятное поймать из-за чего получается деадлок нет возможности.
Возникает случайным образом.
Так и придется переползать на MySQL

[sersad]

ВОт после таких запросов сервак встает

 [select nextid from ids where nodeid=0 and table_name='events' and field_name='eventid']
 10532:20110526:085436.829 Query [txnlev:1] [select max(eventid) from events where eventid between 0 and 99999999999999]
 10532:20110526:085436.830 [Z3005] Query failed: [0] PGRES_FATAL_ERROR:ERROR:  current transaction is aborted, commands ignored until end of transaction block
 [select max(eventid) from events where eventid between 0 and 99999999999999]
 10532:20110526:085436.830 Query [txnlev:1] [insert into ids (nodeid,table_name,field_name,nextid) values (0,'events','eventid',0)]
 10531:20110526:085436.830 [Z3005] Query failed: [0] PGRES_FATAL_ERROR:ERROR:  current transaction is aborted, commands ignored until end of transaction block
 [select nextid from ids where nodeid=0 and table_name='events' and field_name='eventid']
 10531:20110526:085436.830 Query [txnlev:1] [select max(eventid) from events where eventid between 0 and 99999999999999]
 10532:20110526:085436.830 [Z3005] Query failed: [0] PGRES_FATAL_ERROR:ERROR:  current transaction is aborted, commands ignored until end of transaction block
 [insert into ids (nodeid,table_name,field_name,nextid) values (0,'events','eventid',0)]
 10532:20110526:085436.830 Query [txnlev:1] [update ids set nextid=nextid+1 where nodeid=0 and table_name='events' and field_name='eventid']
 10531:20110526:085436.830 [Z3005] Query failed: [0] PGRES_FATAL_ERROR:ERROR:  current transaction is aborted, commands ignored until end of transaction block
 [select max(eventid) from events where eventid between 0 and 99999999999999]
 10531:20110526:085436.830 Query [txnlev:1] [insert into ids (nodeid,table_name,field_name,nextid) values (0,'events','eventid',0)]
 10532:20110526:085436.830 [Z3005] Query failed: [0] PGRES_FATAL_ERROR:ERROR:  current transaction is aborted, commands ignored until end of transaction block
 [update ids set nextid=nextid+1 where nodeid=0 and table_name='events' and field_name='eventid']
 10532:20110526:085436.830 Query [txnlev:1] [select nextid from ids where nodeid=0 and table_name='events' and field_name='eventid']
 10532:20110526:085436.830 [Z3005] Query failed: [0] PGRES_FATAL_ERROR:ERROR:  current transaction is aborted, commands ignored until end of transaction block
 [select nextid from ids where nodeid=0 and table_name='events' and field_name='eventid']
 10532:20110526:085436.830 Query [txnlev:1] [select max(eventid) from events where eventid between 0 and 99999999999999]
 10531:20110526:085436.831 [Z3005] Query failed: [0] PGRES_FATAL_ERROR:ERROR:  current transaction is aborted, commands ignored until end of transaction block
 [insert into ids (nodeid,table_name,field_name,nextid) values (0,'events','eventid',0)]
 10531:20110526:085436.831 Query [txnlev:1] [update ids set nextid=nextid+1 where nodeid=0 and table_name='events' and field_name='eventid']
 10532:20110526:085436.831 [Z3005] Query failed: [0] PGRES_FATAL_ERROR:ERROR:  current transaction is aborted, commands ignored until end of transaction block
 [select max(eventid) from events where eventid between 0 and 99999999999999]
 10532:20110526:085436.831 Query [txnlev:1] [insert into ids (nodeid,table_name,field_name,nextid) values (0,'events','eventid',0)]
 10532:20110526:085436.831 [Z3005] Query failed: [0] PGRES_FATAL_ERROR:ERROR:  current transaction is aborted, commands ignored until end of transaction block
 [insert into ids (nodeid,table_name,field_name,nextid) values (0,'events','eventid',0)]
 10532:20110526:085436.831 Query [txnlev:1] [update ids set nextid=nextid+1 where nodeid=0 and table_name='events' and field_name='eventid']
 10531:20110526:085436.831 [Z3005] Query failed: [0] PGRES_FATAL_ERROR:ERROR:  current transaction is aborted, commands ignored until end of transaction block
 [update ids set nextid=nextid+1 where nodeid=0 and table_name='events' and field_name='eventid']
 10531:20110526:085436.831 Query [txnlev:1] [select nextid from ids where nodeid=0 and table_name='events' and field_name='eventid']
 10532:20110526:085436.831 [Z3005] Query failed: [0] PGRES_FATAL_ERROR:ERROR:  current transaction is aborted, commands ignored until end of transaction block
 [update ids set nextid=nextid+1 where nodeid=0 and table_name='events' and field_name='eventid']
 10532:20110526:085436.831 Query [txnlev:1] [select nextid from ids where nodeid=0 and table_name='events' and field_name='eventid']
 10531:20110526:085436.831 [Z3005] Query failed: [0] PGRES_FATAL_ERROR:ERROR:  current transaction is aborted, commands ignored until end of transaction block
 [select nextid from ids where nodeid=0 and table_name='events' and field_name='eventid']
 10531:20110526:085436.831 Query [txnlev:1] [select max(eventid) from events where eventid between 0 and 99999999999999]

Руками если выполнить запрос

zabbix=# insert into ids (nodeid,table_name,field_name,nextid) values (0,'events','eventid',0);
ERROR:  duplicate key value violates unique constraint "ids_pkey"
zabbix=# 
zabbix=# 
zabbix=# insert into ids (nodeid,table_name,field_name,nextid) values (0,'events','eventid',0);
ERROR:  duplicate key value violates unique constraint "ids_pkey"
zabbix=#

[sersad]

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

[dima_dm]

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

sersad, chengliu - SPAM bot, он просто копирует фразы из предыдущих постов. Не стоит к нему относиться серьёзно. Я уже жалобу на SPAM на него написал

[nightwitch]

1.8.4 + этот патч отлично работают...
Один раз кстати сыпались такие ошибки в логи, когда перезапускала zabbix_server во время работы postgresql. Остановила postgresql, zabbix_server. По порядку запустила - проблемы больше не было.

centos 5.4 x64 postges 9.0.3 zabbix-1.8.4

[sersad]

Попробую обновить постгрес на 9 версию

[sersad]

Все так же(((

[sersad]

Переехал на MySQL 5.1
Полет нормальный.
Минус (а может и плюс) намеренно похер историю и тренды, хотя и могу её перенести.

[mkolomiets]

upd: Патч накатился но сервер не стартует.
Проблема с деадлоком осталась. Есть какие либо варианты решения?

Я его делал на 1.8.4, с 1.8.5 не тестил.

[mkolomiets]

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

Если глянете на патч - там все видно, например, процедура генерации уникальных ИД-ов: читаем IDS, делаем инкремент, обновляем IDS. Все это в одной транзакции - прямая дорога и к взаимным блокировкам. Еще одно место - обновление статуса триггеров.

ЗЫ. Я сам переехал на MySQL, хотя тянул до последнего - знаю я его не в той степени как хотелось бы... Появится свободное время - попробую добить проблему с постгрессом.

[mkolomiets]

ВОт после таких запросов сервак встает

Вот "корень зла":

GRES_FATAL_ERROR:ERROR:  current transaction is aborted, commands ignored until end of transaction block

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

[sersad]

Если глянете на патч - там все видно, например, процедура генерации уникальных ИД-ов: читаем IDS, делаем инкремент, обновляем IDS. Все это в одной транзакции - прямая дорога и к взаимным блокировкам. Еще одно место - обновление статуса триггеров.

ЗЫ. Я сам переехал на MySQL, хотя тянул до последнего - знаю я его не в той степени как хотелось бы... Появится свободное время - попробую добить проблему с постгрессом.

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

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

С MySQL таких проблем, как я понял, не возникает?

ЗЫ На мускуле осталось сделать партишен тейбл

[mkolomiets]

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

Те же самые мотивы.

С MySQL таких проблем, как я понял, не возникает?

ЗЫ На мускуле осталось сделать партишен тейбл

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

[sersad]

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

Для меня постргрес, по оптимизации, так и остался темным лесом. Сколько не изучал, все равно тонкостей в нем очень много. MySQL ИМХО проще и есть много готовых рецептов и разжеванных конфигов, в том числе на этом форуме.

[sire]

ВОт после таких запросов сервак встает

 [select nextid from ids where nodeid=0 and table_name='events' and field_name='eventid']
 10532:20110526:085436.829 Query [txnlev:1] [select max(eventid) from events where eventid between 0 and 99999999999999]
 10532:20110526:085436.830 [Z3005] Query failed: [0] PGRES_FATAL_ERROR:ERROR:  current transaction is aborted, commands ignored until end of transaction block

Сегодня и я получил такую же проблему (не в первый раз). Непосредственно перед глюком обновил 1.8.6rc1 примерно двухнедельной давности до сегодняшнего найтли билда, добавил шаблон мониторинга производительности сервера Zabbix, увеличил в конфиге Заббикса число discoverers и pingers. Кроме того, делал изменения в шаблонах, подключенных к более чем семи сотням устройств, - добавлял айтемы, менял множитель, единицы измерения, изменял графики. Такое впечатление, что если бы я делал перенастройку шаблонов при выключенном Заббиксе, глюка бы не было.

mkolomiets, есть какие нибудь новые мысли на счёт беспроблемности использования Вашего патча? Хочу попробовать адаптировать его под 1.8.6.

Разработчикам следовало бы прежде исправить эту проблему, чем гордо заявлять о поддержке PostgreSQL (извините, наболело), тем более, что проблема известна аж 2009 года и версии Zabbix 1.6.7, судя по трекеру. Интересно, с DB2 и Oracle всё гладко, или нормально работает только MySQL?

P.S. Я не мазохист, MySQL и другие БД использовать не могу по причинам, далёким от технических и от меня не зависящим.