Google Translate

After the transition to the Zabbix database (PostgreSQL) to use Timescaledb, they found a problem after the restart of the Zabbix Backend container. After the server restored, it works until the next hour and on the calculations of the database trends sinking in large numbers of update-query to the trends and trends_uint tables. The average execution time of one update-query is about 30 seconds.

update trends set num=60,value_min=59.000000044250001,value_avg=133.93333333060167,value_max=212.00000021553333 where itemid=139209168 and clock=1714215600; 

It was experimentally found out that the update-query are performed as a result of the fact that when the server is turned off, the trends have already been calculated and synchronized, and when calculating the existing trends in the next hour, you need to update.

Question: Why do you need synchronization of trends when turning off the server, because in the next hour, the trends are calculated on the basis of all existing historical values in an hour?

The synchronization of trends itself is very stretching for the process of turning off the container with Zabbix Backend, and the update-query is very much loading the database. Before the transition to Timescaledb, such a problem was not found.

The Zabbix performance was returned by creating a new hypert bipper without cups for trends and trends_uint tables. Replaced old tables with new ones. Dali to work for 2 hours. Then they returned the tables back and added these two hours to large tables.

Everything worked due to the lack of update-queries. Cups for the trends and trends_uint hyper tables were divided from 30 daily to one-day. Did not help. It hangs on the same update-query at the coming estimated hour. The accommodation table of trends for the current day is not compressed.

Is it possible to somehow disable the synchronization of trends when turning off Zabbix Backend? There is an idea to create a postgreSQL trigger that will intercept all Update operations to Trends and Trends_uint tables and discard them, but it seems to me that this is another crutch.

And should the update-queries hang when updating trends and trends_uint tables?