Timescaledb 作业已经有一段时间没有运行了

Question

我在几台服务器（所有单节点部署）上配置了 timescaledb version 2.2.1，它在大多数情况下都运行良好。

然而，在其中一台服务器上，这是一台功能相对较弱的机器，并且安装了一个 100TB 的大型 NAS 驱动器，一旦我为大型数据库设置压缩作业，我安排的压缩作业似乎停止工作。

之前它确实适用于较小的数据库，但是当我在最大的数据库（总大小为 13TB - 一个表本身为 9.7TB）上创建超表并设置适当的压缩策略时，它只是从未触发，甚至在我使用 alter_job 命令手动更改作业之后。其他 DBS 也发生了同样的事情（启用了 timescaledbs）。计划的作业也几乎在同一时间停止了对它们的处理（它的最后一次成功完成日期是 9 月 29 日 - 即 20 天前）。

我尝试手动调用该作业，它一次只压缩一个块。所以我目前不得不手动压缩它们作为快速修复。

有人可以帮忙吗？我似乎找不到任何有关此的资源。

SELECT compress_chunk(i,if_not_compressed=>true) from 
show_chunks('oa_odds_historic', older_than => INTERVAL '10 day') i ; 

   
 code: SELECT alter_job(job_id, next_start =>now())
-- select *
FROM timescaledb_information.jobs
WHERE proc_name = 'policy_compression';

服务器规格：

timescaledb 作业：

Answer 1

感谢 Jonatasdp。 不幸的是，这是由于没有足够的后台工作人员 - timescaledb.max_background_workers，我增加了它以适应服务器上的作业总数（= 启用压缩策略的超表数）。