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

[sire]

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

Я не большой специалист по БД, может кто знает, использование SEQUENCE'ов или типа данных SERIAL для полей id не решит проблему генерации идентификаторов? Что-то вроде того, что описано здесь.

[mkolomiets]

Приветствую!

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

Да особых проблем не проявилось. Теоретически существует вероятность нарушения целостности данных на уровне бизнес-логики - например, при успешном обновление датчика может не выполнится изменение статуса связанного с ним триггера.
К сожалению из-за нехватки времени дальше я я того момента никуда не сдвинулся. В планах есть пересмотреть реализацию ряда методов, в т.ч. попробовать использовать последовательности для генерации ИД-ов и, как вариант, задействовать объекты синхронизации, типа мютексов, для защиты связок чтения/обновления в БД, так что бы исключить возможность дедлоков.

Разработчикам следовало бы прежде исправить эту проблему, чем гордо заявлять о поддержке postgresql (извините, наболело), тем более, что проблема известна аж 2009 года и версии zabbix 1.6.7, судя по трекеру. Интересно, с db2 и oracle всё гладко, или нормально работает только mysql?

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

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

Давайте бороться с этой несправедливостью в отношении постгреса коллективно, думаю, в наших силах решить этот вопрос окончательно и бесповоротно.

[mkolomiets]

Я не большой специалист по БД, может кто знает, использование sequence'ов или типа данных serial для полей id не решит проблему генерации идентификаторов? Что-то вроде того, что описано здесь.

Решает. Только есть маленькое но - в случае многосерверной реализации для каждой из 1000 возможных нод выделяется свой диапазон ИД-ов для каждой таблицы.

[sire]

Решает. Только есть маленькое но - в случае многосерверной реализации для каждой из 1000 возможных нод выделяется свой диапазон ИД-ов для каждой таблицы.

А в нынешней реализации ИД содержит в себе идентификатор ноды? Если так, то при использовании serial надо будет вместо одного поля ИД учитывать ещё и ИД ноды? А можно как-то сказать БД, что последовательность начинается не с нуля, а например, с 1 триллиона? Тогда, наверно, можно будет заложить в ИД идентификатор ноды.

[mkolomiets]

А в нынешней реализации ИД содержит в себе идентификатор ноды? Если так, то при использовании serial надо будет вместо одного поля ИД учитывать ещё и ИД ноды? А можно как-то сказать БД, что последовательность начинается не с нуля, а например, с 1 триллиона? Тогда, наверно, можно будет заложить в ИД идентификатор ноды.

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

[dima_dm]

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

Вот так:
Может быть 100000000000000 item, и до 1000 Node. (0-999)
Индекс вычисляется как NodeID * 100000000000000 + ItemID

[sire]

âîò òàê:
ìîæåò áûòü 100000000000000 item, è äî 1000 node. (0-999)
èíäåêñ âû÷èñëÿåòñÿ êàê nodeid * 100000000000000 + itemid

Понятно

[sire]

mkolomiets,

Переделал Ваш патч для pre-1.8.6. При этом обернул в сэйвпоинты все DBexecute_overflowed_sql, которые нашёл. Возможно это было лишнее. Сервер запускается и работает, но в логе периодически появляются ошибки вида

18530:20110615:164122.913 [Z3005] query failed: [0] PGRES_EMPTY_QUERY: []
18530:20110615:164122.914 [Z3005] query failed: [0] PGRES_FATAL_ERROR:ОШИБКА:  нет такой точки сохранения (savepoint)
 [rollback to savepoint DCmass_add_history;]

Патч от дедлоков не помогает, вот лог

2011-06-15 13:12:46 MSD ОШИБКА:  обнаружена взаимная блокировка (deadlock)
2011-06-15 13:12:46 MSD ПОДРОБНОСТИ:  Процесс 2831 ожидает ShareLock в транзакция 5843234; заблокир
овано процессом 2816.
        Процесс 2816 ожидает ShareLock в транзакция 5842782; заблокировано процессом 2831.
        Процесс 2831: update ids set nextid=nextid+256 where nodeid=0 and table_name='events' and f
ield_name='eventid'
        Процесс 2816: update triggers set value=1,lastchange=1308129164,error='' where triggerid=24
740
2011-06-15 13:12:46 MSD ПОДСКАЗКА:  Смотрите подробности о запросе в журнале сервера.
2011-06-15 13:12:46 MSD КОМАНДА:  update ids set nextid=nextid+256 where nodeid=0 and table_name='e
vents' and field_name='eventid'
2011-06-15 13:12:46 MSD ОШИБКА:  текущая транзакция отменена, команды до конца блока транзакции игн
орированы
2011-06-15 13:12:46 MSD КОМАНДА:  select nextid from ids where nodeid=0 and table_name='events' and
 field_name='eventid'
2011-06-15 13:12:46 MSD ОШИБКА:  текущая транзакция отменена, команды до конца блока транзакции игн
орированы
2011-06-15 13:12:46 MSD КОМАНДА:  select nextid from ids where nodeid=0 and table_name='events' and
 field_name='eventid'
2011-06-15 13:12:46 MSD ОШИБКА:  текущая транзакция отменена, команды до конца блока транзакции игн
орированы
2011-06-15 13:12:46 MSD КОМАНДА:  select max(eventid) from events where eventid between 0 and 99999
999999999

Подскажите, пожалуйста, где я ошибся.

[mkolomiets]

Переделал Ваш патч для pre-1.8.6. При этом обернул в сэйвпоинты все DBexecute_overflowed_sql, которые нашёл. Возможно это было лишнее. Сервер запускается и работает, но в логе периодически появляются ошибки вида

18530:20110615:164122.913 [Z3005] query failed: [0] PGRES_EMPTY_QUERY: []
18530:20110615:164122.914 [Z3005] query failed: [0] PGRES_FATAL_ERROR:ОШИБКА:  нет такой точки сохранения (savepoint)
 [rollback to savepoint DCmass_add_history;]

Не плохо бы определится с местом где это происходит, возможно стоит посмотреть лог перед этим сообщением. Если сохранился, дайте глянуть [michael.kolomiets AT gmail.com].

Патч от дедлоков не помогает, вот лог

        Процесс 2831: update ids set nextid=nextid+256 where nodeid=0 and table_name='events' and f
ield_name='eventid'

Подскажите, пожалуйста, где я ошибся.

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

[sire]

mkolomiets,

К сожалению, лог не сохранился. Дело было на боевой базе, на патч я понадеялся как на последний костыль, но не помогло, пришлось срочно пересоздавать базу заново, благо основное наполнение у меня делается скриптом через Zabbix API. После восстановления я установил Заббикс без патча.
Я так понимаю, что база у меня слетела из-за массового обновления шаблонов. Теперь перед этим действием я останавливаю сервер. Пока всё ок.
По-хорошему мне надо бы протестировать патч на тестовой системе, но в ближайшие две недели у меня вряд ли будет на это время. Если смогу - обязательно всё проверю.

Вам спасибо за все труды.

К стати, Алексей Владышев утверждает, что этой проблеме подвержены все СУБД, не только Postgres.

[mkolomiets]

mkolomiets,
К стати, Алексей Владышев утверждает, что этой проблеме подвержены все СУБД, не только postgres.

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

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

[sire]

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

Вот сиквенсы - это было бы кардинальное решение проблемы, имхо. И производительность бы возрасла заметно.

[mkolomiets]

Вот сиквенсы - это было бы кардинальное решение проблемы, имхо. И производительность бы возрасла заметно.

Не факт, но попробовать думаю стоит. Таблица евентов судя по номерам, имеет на два порядка вставок больше чем любая другая, пробую на ней пока.

[sire]

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

Вот, вроде бы, тот лог постгреса. Лог Заббикса не сохранился.

[mkolomiets]

Привет!

Вот, вроде бы, тот лог постгреса. Лог Заббикса не сохранился.

Спасибо!
Посмотрю, походу есть еще вызов получения ИДа именно через модуль кеша из какого то места, т.к. резервируется целая пачка из 256 ИД-ов.

ЗЫ. По ходу - в случае с секвенсами скорее всего придется от кеша отказаться, т.к. постгресс не позволяет вызывать некствал с инкрементом отличным от параметров секвенса.