Проблема на Zabbix 5.4

[Raccoon15]

Конфигурация:
Zabbix 5.4
PostgreSQL 12.7
TimescaleDB 2.4.1

Решил обновить Zabbix 5.2 на 5.4 и включить партиционирование с поддержкой TimescaleDB. Всё работает, но внутренние процессы забикса со временем накапливаются и через пару часов Забикс начинает тормозить. Если перезагрузить базу Postgres, то ситуации нормализуется на какое-то время. В логах показывает только медленные запросы к разным таблицам после пару часов работы забикса. Не могу понять куда дальше копать

[wins]

тут бы еще проанализировать телеметрию и логи посгреса, дисковой подсистемы. Маловато данных для анализа.
Если вы переходили на timescaledb имея ненулевую базу, я бы советовал сделать дамп-рестор, для начала.

[Raccoon15]

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

[Raccoon15]

За 6 часов работы сервера начали появляться медленные запросы. Больше информации в логах нету

2021-09-16 15:12:01.724 EEST [2839685] LOG: duration: 6084.300 ms statement: SELECT DISTINCT e.eventid,e.objectid,e.clock,e.ns,e.name,e.severit y FROM events e,functions f,items i,hosts_groups hg WHERE e.source='0' AND e.object='0' AND NOT EXISTS (SELECT NULL FROM functions f,items i,hosts_groups hgg LEFT JOIN rights r ON r.id=hgg.groupid AND r.groupid=21 WHERE e.objectid=f.triggerid AND f.itemid=i.itemid AND i.hostid=hgg.hostid GROUP BY i.hostid HAVING MAX(permission)<2 OR MIN(permission) IS NULL OR MIN(permission)=0) AND e.objectid=f.triggerid AND f.itemid=i.itemid AND i.hostid=hg.hostid AND hg.groupid IN (40,47,55,56) AND e.severity IN (3,4,5) AND NOT EXISTS (SELECT NULL FROM event_suppress es WHERE es.eventid=e.eventid) AND e.eventid<='87797110' AND e.value=1 ORDER BY e.eventid DESC LIMIT 2001
2021-09-16 15:57:08.011 EEST [2722762] LOG: duration: 7673.292 ms statement: begin;
2021-09-16 15:57:08.011 EEST [2855314] LOG: duration: 7696.222 ms statement: SET search_path='public'
2021-09-16 15:57:08.011 EEST [2722751] LOG: duration: 7530.164 ms statement: begin;
2021-09-16 15:57:08.011 EEST [2722755] LOG: duration: 8257.878 ms statement: select u.userid,u.roleid,r.type from sessions s,users u,role r where s.userid=u.userid and s.sessionid='f69093f303da1563edd5277a340f14ea' and s.status=0 and u.roleid=r.roleid
2021-09-16 15:57:08.012 EEST [2855303] LOG: duration: 8258.198 ms statement: SELECT itemid,COUNT(*) AS count,AVG(value) AS avg,MIN(value) AS min,MAX(value) AS max,round(620* MOD(CAST(clock AS BIGINT)+2022,3600)/(3600),0) AS i,MAX(clock) AS clock FROM history_uint WHERE itemid='33426' AND clock>='1631777178' AND clock<='1631780778' GROUP BY itemid,round(620* MOD(CAST(clock AS BIGINT)+2022,3600)/(3600),0)
2021-09-16 15:57:08.012 EEST [2722749] LOG: duration: 7021.521 ms statement: select t.taskid,t.type,t.clock,t.ttl,c.command_type,c.exe cute_on,c.port,c.authtype,c.username,c.password,c. publickey,c.privatekey,c.command,c.alertid,c.paren t_taskid,c.hostid,cn.itemid,d.data,d.parent_taskid ,d.type from task t left join task_remote_command c on t.taskid=c.taskid left join task_check_now cn on t.taskid=cn.taskid left join task_data d on t.taskid=d.taskid where t.status=1 and t.proxy_hostid=10494 and (t.ttl=0 or t.clock+t.ttl>1631797020) order by t.taskid
2021-09-16 15:57:08.013 EEST [2722740] LOG: duration: 6975.870 ms statement: begin;
2021-09-16 15:57:08.013 EEST [2855316] LOG: duration: 6653.074 ms statement: set schema 'public'
2021-09-16 15:57:08.013 EEST [2855306] LOG: duration: 6650.128 ms statement: SELECT c.configid,c.default_theme,c.search_limit,c.max_in _table,c.server_check_interval,c.work_period,c.sho w_technical_errors,c.history_period,c.period_defau lt,c.max_period,c.severity_color_0,c.severity_colo r_1,c.severity_color_2,c.severity_color_3,c.severi ty_color_4,c.severity_color_5,c.severity_name_0,c. severity_name_1,c.severity_name_2,c.severity_name_ 3,c.severity_name_4,c.severity_name_5,c.custom_col or,c.ok_period,c.blink_period,c.problem_unack_colo r,c.problem_ack_color,c.ok_unack_color,c.ok_ack_co lor,c.problem_unack_style,c.problem_ack_style,c.ok _unack_style,c.ok_ack_style,c.discovery_groupid,c. default_inventory_mode,c.alert_usrgrpid,c.snmptrap _logging,c.default_lang,c.default_timezone,c.login _attempts,c.login_block,c.validate_uri_schemes,c.u ri_valid_schemes,c.x_frame_options,c.iframe_sandbo xing_enabled,c.iframe_sandboxing_exceptions,c.max_ overview_table_size,c.connect_timeout,c.socket_tim eout,c.media_type_test_timeout,c.script_timeout,c. item_test_timeout,c.url,c.report_test_timeout FROM config c
2021-09-16 15:57:08.013 EEST [2855319] LOG: duration: 6175.711 ms statement: SET search_path='public'
2021-09-16 15:57:08.013 EEST [2855308] LOG: duration: 8253.384 ms statement: BEGIN
2021-09-16 15:57:08.017 EEST [2722742] LOG: duration: 6104.617 ms statement: select escalationid,actionid,triggerid,eventid,r_eventid, nextcheck,esc_step,status,itemid,acknowledgeid from escalations where triggerid is not null and nextcheck<=1631797024 order by actionid,triggerid,itemid,escalationid
2021-09-16 15:57:08.018 EEST [2722748] LOG: duration: 5860.827 ms statement: select h.hostid,h.host,h.name,t.httptestid,t.name,t.agent ,t.authentication,t.http_user,t.http_password,t.ht tp_proxy,t.retries,t.ssl_cert_file,t.ssl_key_file, t.ssl_key_password,t.verify_peer,t.verify_host,t.d elay from httptest t,hosts h where t.hostid=h.hostid and t.nextcheck<=1631797022 and mod(t.httptestid,2)=1 and t.status=0 and h.proxy_hostid is null and h.status=0 and (h.maintenance_status=0 or h.maintenance_type=0)
2021-09-16 15:57:08.018 EEST [2722726] LOG: duration: 5841.226 ms statement: select discovery_groupid,snmptrap_logging,severity_name_0 ,severity_name_1,severity_name_2,severity_name_3,s everity_name_4,severity_name_5,hk_events_mode,hk_e vents_trigger,hk_events_internal,hk_events_discove ry,hk_events_autoreg,hk_services_mode,hk_services, hk_audit_mode,hk_audit,hk_sessions_mode,hk_session s,hk_history_mode,hk_history_global,hk_history,hk_ trends_mode,hk_trends_global,hk_trends,default_inv entory_mode,db_extension,autoreg_tls_accept,compre ssion_status,compress_older,instanceid,default_tim ezone from config order by configid
...

Запустил дамп timescaledb (https://docs.timescale.com/timescale...dump-meta-data)
И обнаружил один сжатый чанк, который относится к таблице history_uint. Но сжатие на сервере не включено.

zabbix=# \d+ _timescaledb_internal._compressed_hypertable_9
Table "_timescaledb_internal._compressed_hypertable_ 9"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
-----------------------+---------------------------------------+-----------+----------+---------+----------+--------------+-------------
itemid | bigint | | | | plain | 1000 |
clock | _timescaledb_internal.compressed_data | | | | external | 0 |
value | _timescaledb_internal.compressed_data | | | | extended | 0 |
ns | _timescaledb_internal.compressed_data | | | | external | 0 |
_ts_meta_count | integer | | | | plain | 1000 |
_ts_meta_sequence_num | integer | | | | plain | 1000 |
_ts_meta_min_1 | integer | | | | plain | 1000 |
_ts_meta_max_1 | integer | | | | plain | 1000 |
_ts_meta_min_2 | integer | | | | plain | 1000 |
_ts_meta_max_2 | integer | | | | plain | 1000 |
Indexes:
"_compressed_hypertable_9_itemid__ts_meta_sequence _num_idx" btree (itemid, _ts_meta_sequence_num)
Triggers:
ts_insert_blocker BEFORE INSERT ON _timescaledb_internal._compressed_hypertable_9 FOR EACH ROW EXECUTE FUNCTION _timescaledb_internal.insert_blocker()
Child tables: _timescaledb_internal.compress_hyper_9_1775_chunk
Access method: heap
Options: toast_tuple_target=128


SELECT decompress_chunk('_timescaledb_internal.compress_hyper_9_1775_chunk');
ERROR: missing compressed hypertable

zabbix=# select * from _timescaledb_catalog.chunk where table_name = 'compress_hyper_9_1775_chunk';
id | hypertable_id | schema_name | table_name | compressed_chunk_id | dropped | status
------+---------------+-----------------------+-----------------------------+---------------------+---------+--------
1775 | 9 | _timescaledb_internal | compress_hyper_9_1775_chunk | | f | 0


zabbix=# select ht.id,ht.table_name FROM _timescaledb_catalog.chunk ch1, _timescaledb_catalog.hypertable ht where ch1.hypertable_id = ht.id GROUP BY 1,2 ORDER BY 1;
id | table_name
----+--------------------------
1 | history
2 | history_log
3 | history_str
4 | history_text
5 | history_uint
6 | trends
7 | trends_uint
9 | _compressed_hypertable_9
(9 rows)


SELECT * FROM timescaledb_information.hypertables;
hypertable_schema | hypertable_name | owner | num_dimensions | num_chunks | compression_enabled | is_distributed | replication_factor | data_nodes | tablespaces
-------------------+-----------------+-----------+----------------+------------+---------------------+----------------+--------------------+------------+-------------
public | history | zbx01user | 1 | 126 | f | f | | |
public | history_log | zbx01user | 1 | 80 | f | f | | |
public | history_str | zbx01user | 1 | 126 | f | f | | |
public | history_text | zbx01user | 1 | 215 | f | f | | |
public | history_uint | zbx01user | 1 | 401 | t | f | | |
public | trends | zbx01user | 1 | 13 | f | f | | |
public | trends_uint | zbx01user | 1 | 13 | f | f | | |
(7 rows)


ALTER TABLE history_uint SET (timescaledb.compress = FALSE);
ERROR: cannot drop table _timescaledb_internal._compressed_hypertable_9 because other objects depend on it
DETAIL: table _timescaledb_internal.compress_hyper_9_1775_chunk depends on table _timescaledb_internal._compressed_hypertable_9
HINT: Use DROP ... CASCADE to drop the dependent objects too.

Как запустить декомпрессию этого чанка и не потерять данные?

[wins]

Дамп лучше делать утилитой ts-backup https://docs.timescale.com/timescale...db-backup-tool
А в логе заббикса больше ошибок нет?

[Raccoon15]

За утилиту спасибо.
В логах больше информации нету. Не за чего зацепиться. Забикс быстро работает часов 20-22 и потом в логах куча ошибок медленных запросов. Иногда отваливается забикс агент на базе

462431:20210912:041622.817 active check configuration update from [zabbix:10051] started to fail (ZBX_TCP_READ() timed out)
462428:20210912:041636.858 Failed to execute command " psql -qtAX -h "127.0.0.1" -p "5432" -U "zbx_monitor" -d "postgres" -f "/var/lib/zabbix/postgresql/pgsql.bgwriter.sql"": Timeout while executing a shell script.
462430:20210912:041637.878 Failed to execute command " psql -qtAX -h "127.0.0.1" -p "5432" -U "zbx_monitor" -d "postgres" -f "/var/lib/zabbix/postgresql/pgsql.cache.hit.sql"": Timeout while executing a shell script.
462429:20210912:041645.489 Failed to execute command " psql -qtAX -h "127.0.0.1" -p "5432" -U "zbx_monitor" -d "zabbix" -f "/var/lib/zabbix/postgresql/pgsql.scans.sql"": Timeout while executing a shell script.

Пока помогает только рестарт базы раз в сутки

[Raccoon15]

Сервер базы особо не нагружен. До апдейта забикса и включение партиционирования без проблем работал на 2CPU и 8GB ram. Сейчас добавили ему ещё 6 ядер и 24GB оперативки

[wins]

На счет декомпрессии 1 чанка затрудняюсь ответить. Сам использую с компрессией.
Если б такая задача стояла - игрался бы с дампом на тестовой среде, заменяя параметры, которые были переданы скриптом тсдб:

/usr/share/zabbix-server/postgresql grep UPDATE timescaledb.sql
UPDATE config SET db_extension='timescaledb',hk_history_global=1,hk_ trends_global=1;
UPDATE config SET compression_status=1,compress_older='7d';

[Raccoon15]

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

[Raccoon15]

Может стоит перейти на постгрес 13 и там настраивать timescaledb?

[wins]

Возможно.
Гляньте, не ваш случай? https://www.zabbix.com/documentation...s#timescale_db

[Raccoon15]

К сожалению нет. Чанков не так много. Было настроено history* - 1 день, trends* - 1 месяц
Планирую на следующей неделе отказаться от timescaledb и партиционирования и посмотреть как себя будет чувствовать сервер