После перехода на БД Zabbix (PostgreSQL) на использование TimescaleDB, обнаружили проблему после рестарта контейнера Zabbix Backend. После рестарата сервера, он работает до начала ближайшего часа и на расчетах трендов БД тонет в большом количестве UPDATE-запросов к таблицам trends и trends_uint. Среднее время выполнения одного UPDATE-запроса около 30 секунд.
Опытным путем было выяснено, что UPDATE-зпросы выполняются в следствии того, что при выключении сервера тренды уже были вычислены и синхронизированы, а при расчете в ближайший час существующие тренды нужно обновить. Сама синхронизация трендов очень растягивает процесс выключения контейнера с Zabbix Backend, а UPDATE-запросы очень нагружают БД. Вопрос: зачем нужна синхронизация трендов при выключении службы zabbix_server, ведь в ближайший час все равно тренды расчитаются на основе всех существующих исторических значений за час (справедливо при рестарте сервера)? Если отключить синхронизацию трендов при выключении службы zabbix_server, то тогда отпадет надобность в UPDATE-запросах при расчете трендов в ближайший час. До перехода на TimescaleDB такой проблемы не обнаруживалось.
Вернули работоспособность Zabbix путем создания новой гипертаблицы без чанков для таблиц trends и trends_uint. Подменили старые таблицы на новые. Дали поработать 2 часа. После чего вернули таблицы обратно и долили эти два часа в большие таблицы. Все заработало из-за отсутствия запросов UPDATE.
Чанки для гипертаблиц trends и trends_uint разбили с 30 дневных до однодневные. Не помогло. Зависает на тех же UPDATE-запросах в ближайщий расчетный час. Акктуальная таблица трендов за текущий день не сжата.
Таблица trends
Таблица trends_uint
Можно ли как-то отключить синхронизацию трендов при выключении Zabbix Backend?
Так же есть идея создать триггер Postgresql, который будет перехватывать все операции UPDATE к таблицам trends и trends_uint и отбрасывать их, но мне кажется, что это очередной костыль.
И вообще должны ли зависать UPDATE-запросы при обновлении таблиц trends и trends_uint? Почему так происходит? Может кто-то что-то знает?
Code:
update trends set num=60,value_min=59.000000044250001,value_avg=133. 93333333060167,value_max=212.00000021553333 where itemid=139209168 and clock=1714215600;
Вернули работоспособность Zabbix путем создания новой гипертаблицы без чанков для таблиц trends и trends_uint. Подменили старые таблицы на новые. Дали поработать 2 часа. После чего вернули таблицы обратно и долили эти два часа в большие таблицы. Все заработало из-за отсутствия запросов UPDATE.
Чанки для гипертаблиц trends и trends_uint разбили с 30 дневных до однодневные. Не помогло. Зависает на тех же UPDATE-запросах в ближайщий расчетный час. Акктуальная таблица трендов за текущий день не сжата.
Таблица trends
Code:
Table "public.trends"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
-----------+------------------+-----------+----------+-----------------------+---------+--------------+-------------
itemid | bigint | | not null | | plain | |
clock | integer | | not null | 0 | plain | |
num | integer | | not null | 0 | plain | |
value_min | double precision | | not null | '0'::double precision | plain | |
value_avg | double precision | | not null | '0'::double precision | plain | |
value_max | double precision | | not null | '0'::double precision | plain | |
Indexes:
"trends_pkey" PRIMARY KEY, btree (itemid, clock)
"trends_new_clock_idx" btree (clock DESC)
Triggers:
ts_insert_blocker BEFORE INSERT ON trends FOR EACH ROW EXECUTE FUNCTION _timescaledb_functions.insert_blocker()
Child tables: _timescaledb_internal._hyper_18_1156_chunk,
_timescaledb_internal._hyper_18_1157_chunk,
....
_timescaledb_internal._hyper_18_2822_chunk,
Code:
Table "public.trends_uint"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
-----------+---------------+-----------+----------+--------------+---------+--------------+-------------
itemid | bigint | | not null | | plain | |
clock | integer | | not null | 0 | plain | |
num | integer | | not null | 0 | plain | |
value_min | numeric(20,0) | | not null | '0'::numeric | main | |
value_avg | numeric(20,0) | | not null | '0'::numeric | main | |
value_max | numeric(20,0) | | not null | '0'::numeric | main | |
Indexes:
"trends_uint_pkey" PRIMARY KEY, btree (itemid, clock)
"trends_uint_2_clock_idx" btree (clock DESC)
Triggers:
ts_insert_blocker BEFORE INSERT ON trends_uint FOR EACH ROW EXECUTE FUNCTION _timescaledb_functions.insert_blocker()
Child tables: _timescaledb_internal._hyper_25_1530_chunk,
_timescaledb_internal._hyper_25_1531_chunk,
...
_timescaledb_internal._hyper_25_2839_chunk
Так же есть идея создать триггер Postgresql, который будет перехватывать все операции UPDATE к таблицам trends и trends_uint и отбрасывать их, но мне кажется, что это очередной костыль.
И вообще должны ли зависать UPDATE-запросы при обновлении таблиц trends и trends_uint? Почему так происходит? Может кто-то что-то знает?
Comment