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

[mkolomiets]

Привет!
Достаточно регулярно (раз в день точно, бывает и чаще) в логи постгресса начинают сыпаться пачками следующие сообщения:

STATEMENT:  select nextid from ids where nodeid=0 and table_name='events' and field_name='eventid'
ERROR:  current transaction is aborted, commands ignored until end of transaction block
STATEMENT:  select max(eventid) from events where eventid between 0 and 99999999999999
ERROR:  current transaction is aborted, commands ignored until end of transaction block
STATEMENT:  insert into ids (nodeid,table_name,field_name,nextid) values (0,'events','eventid',0)
ERROR:  current transaction is aborted, commands ignored until end of transaction block
STATEMENT:  update ids set nextid=nextid+1 where nodeid=0 and table_name='events' and field_name='eventid'
ERROR:  current transaction is aborted, commands ignored until end of transaction block

Сбор данных при этом прекращается. Помогает (???) киляние процесса БД, создающего сообщение. Причем если не прервать этот "праздник души", то в течении 1-2 часов забивается раздел логов размером в 30 ГБ.

Что можно предпринять в данной ситуации, кто сталкивался с подобным?

ЗЫ. Не рассматривался ли вариант использовать sequence постгреса для генерации ИД-ов?

CentOS 5 x64, Zabbix 1.8.4, PostgreSQL 8.4, размер БД примерно 40 ГБ, активных узлов/датчиков порядка 550/14500

[Dev_LC]

Привет!
Достаточно регулярно (раз в день точно, бывает и чаще) в логи постгресса начинают сыпаться пачками следующие сообщения:

STATEMENT:  select nextid from ids where nodeid=0 and table_name='events' and field_name='eventid'
ERROR:  current transaction is aborted, commands ignored until end of transaction block
STATEMENT:  select max(eventid) from events where eventid between 0 and 99999999999999
ERROR:  current transaction is aborted, commands ignored until end of transaction block
STATEMENT:  insert into ids (nodeid,table_name,field_name,nextid) values (0,'events','eventid',0)
ERROR:  current transaction is aborted, commands ignored until end of transaction block
STATEMENT:  update ids set nextid=nextid+1 where nodeid=0 and table_name='events' and field_name='eventid'
ERROR:  current transaction is aborted, commands ignored until end of transaction block

Сбор данных при этом прекращается. Помогает (???) киляние процесса БД, создающего сообщение. Причем если не прервать этот "праздник души", то в течении 1-2 часов забивается раздел логов размером в 30 ГБ.

Что можно предпринять в данной ситуации, кто сталкивался с подобным?

ЗЫ. Не рассматривался ли вариант использовать sequence постгреса для генерации ИД-ов?

CentOS 5 x64, Zabbix 1.8.4, PostgreSQL 8.4, размер БД примерно 40 ГБ, активных узлов/датчиков порядка 550/14500

Я сталкивался с такой проблемой. Шатал ее около двух недель туда сюда и пришел к выводу что буду дальше шатать Oracle
p.s. чтобы не росли логи - монтировал на данную ветвь отдельный раздел в гиг.

[mkolomiets]

Немного покопался над проблемой.
Причина в том, что Постгрес требует явного роллбека при сбоях в запросах, и все последующие запросы в рамках этой же транзакции будут получать эту ошибку "current transaction is aborted..."
Думаю, неплохо было бы обернуть запросы в сейвпоинты и при сбоях делать "ролббек ту сейвпоинт" - это позволит при сбое отдельного запроса сохранить в нормальном состоянии транзакцию или попробовать повторно выполнить запрос или пропустить сбойный, если это допустимо. Ну или как более радикальный способ - сразу же делать роллбек и прекращать операцию.

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

[Dev_LC]

Присоединяюсь

[mkolomiets]

Пока удалось добиться такого:

ERROR:  deadlock detected
DETAIL:  Process 20628 waits for ShareLock on transaction 55780345; blocked by process 20632.
	Process 20632 waits for ShareLock on transaction 55780278; blocked by process 20628.
	Process 20628: update triggers set value=1,lastchange=1301756976,error='' where triggerid=17047
	Process 20632: update triggers set value=1,lastchange=1301756877,error='' where triggerid=26081
HINT:  See server log for query details.
STATEMENT:  update triggers set value=1,lastchange=1301756976,error='' where triggerid=17047

Этим и ограничивается - вылетает дедлок, но уже нет дальнейшего цикла "current transaction is aborted", т.е. единичный отказ в рамках транзакции удалось локализовать и ограничить влияние на последующие запросы в рамках той же транзакци.

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

ЗЫ. В качестве дополнительного бонуса - заметно снизилась нагрузка на сервер БД.

[zalex_ua]

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

[mkolomiets]

В ключе темы обсуждения, кто то может объяснить смысл этих конструкций?

void	DBcommit()
{
	int	rc;

	rc = zbx_db_commit();

	while (rc == ZBX_DB_DOWN)
	{
		DBclose();
		DBconnect(ZBX_DB_CONNECT_NORMAL);

		if (ZBX_DB_DOWN == (rc = zbx_db_commit()))
		{
			zabbix_log(LOG_LEVEL_WARNING, "Database is down."
					" Retrying in 10 seconds");
			sleep(10);
		}
	}
}

Если оборвалась связь с базой до выполнения коммита, переподключаться и прорбывать что то коммитить ИМХО - "мертвому припарки". Такая же картина и с ролбеком.

[zalex_ua]

Не может быть это похожим?

[mkolomiets]

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

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

Второе я вроде бы как вчера сделал - прошелся по сорцам и во всех местах где в рамках транзакции выполняется несколько различных запросов подряд изолировал запросы с обновлением данных (DBexecute) с помощью сейвпоинтов. Пока вроде бы живет...

Но, остается большое "но" - я не разбирался как повлияет отмена одного из запросов в рамках транзакции.
Пример - получение уникального идентификатора из таблицы ids, там выполняется цепочка из сетекта, апдейта/инсерта и еще одного селекта. Если отменить апдейт из-за сбоя то теряет смысл вся цепочка.

ЗЫ. Кому интересно во вложении патч правок, я поразбирался немного и вынес сейвлоки на более высокий уровень, так что бы немного учитывать бизнес-логику.

[zalex_ua]

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

[sersad]

Попробуем накатить ваш патч. Был раз случай что сервер сбойнул из-за выросших логов которые съели все место ))) Не думал что может быть подстава, сейчас то логи жестко ограничены в размерах.
Посмотрим как повлияет этот патч на работоспособность системы. "аборты" в логах регулярно но к катастрофам они не приводят.

[sersad]

Как же достали деад локи.
Накатил пачт на 1.8.5 посмотрим что будет.

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

[sersad]

Победил деадлоки, но таким извращенным способом - грохнул primary key таблицы IDS
Все работает.
Толи я дурак, то ли что то не то.

[sersad]

Деад локи остались, но не такие критичные
Просто отваливаются от мониторинга некоторые итемы.
Подскажите что я делаю не так?

[sersad]

ЛЮДИ!
Неужели я один только мучаюсь?