Postgresql 索引完成后Postgres运行缓慢

我的postgres最近运行得非常慢，一个月的聚合通常需要1分钟以上（更确切地说，最后一次需要7分23秒）

上周五，我重新创建了服务器（主服务器和副本服务器），并重新导入了数据库

我注意到的第一件事是，从133gb到现在，数据库是42gb（实际数据大约是12gb，我猜其余的是索引）

一切都像地狱一样快了一天，在那之后索引完成了（索引为26gb），现在我又回到了第1步

大约500万行的计数需要3分钟42秒

使自动吸尘器更具攻击性，看起来它正在做它的工作，但DB仍然很慢

我使用db作为API，因此它在不断增长。Atm i有两个表，一个有大约5百万行，另一个有28百万行

因此，如果主机有很多活动，比如说，我预期会有一些性能损失，那么我不希望复制副本会有性能损失

有趣的是，重启后，它的速度真的快了一个小时左右

我还注意到，在我执行的每个查询中，IO都是100%，而内存和cpu几乎没有被使用

任何帮助都将不胜感激

更新

在一台较小的机器上运行相同的数据库就像一个符咒。 相同的查询，相同的索引。 唯一的区别是流量，没有写或更新那么多

我还忘了提到一件事，我的一个索引是集群索引

实时机器是一个5核的64gb和3k IO。 测试机器是一个2核的4gb和SSD

更新

找到了我的问题。 显然，autovacuum无法获得锁，当它获得锁时，死元组增加了

使autovacuum目前更具攻击性，并删除了大量未使用的索引

仍然不知道如何解决锁的问题

更新

看起来有什么东西在增加估计的行数。 自从我上次更新后，行数增加了2 mil。 我猜到明天，排数将再次在1200万左右，而且排数将再次缓慢

这可能与自动真空有关吗

更新 我发现了我的问题。 看来postgres在一个写操作密集型数据库上正在失去很多速度。 有一列被用作旗帜，每天更新很多次。 删除标志和更新后，一切看起来都很好

---

关于如何在写密集型表上解决此问题的任何线索？

可能是以下指针帮助：

• 是否确实要为API执行5mil行聚合？每次？难道你不能将数据分割成块，这样只有少量的块才能真正获得大部分新行（这样之前所有块的聚合就可以在下一次查询中重用）？时间是这样一种度量，序列号可能是另一种度量，等等。如果是这样，那么对数据进行分区显然是一种您应该研究的解决方案，它确实有很好的机会为您提供亚秒级的查询时间（假设您聪明地存储了以前数据块的聚合）

• 关于第一个小时的魔力的一种预感是，尽管这些数据适合RAM，但并发查询会将这些数据集推出来，然后将其纯磁盘I/O。。。在这种情况下，CPU/RAM空闲也就不足为奇了

• 最后，我认为这种设置要求重新设计，在这种情况下，一个SQL只能做这么多事情，而对于一个5mil数据集来说，对于不在RAM中的数据，期望亚秒的查询时间可能过于乐观了

---

（尽管如此，如果可能的话，一定要公布你的调查结果）

你能公布执行计划吗？您指的是解释，对吗？是的，对不起，是解释。解释分析从订阅中选择计数（id）。事件。聚合基于时间，数据库中的总量为5 mil，但在一个月内，第一个表的聚合量不应超过10-20k，第二个表的聚合量不应超过60k。在这种情况下，是否不可能在物化视图（9.3支持）中存储前几个月的聚合，并仅聚合最后几个月（1或2个月）的聚合，最后执行一个UNION ALL？这应该会让这“快得多”。。。。如果这样行的话。。有一个每月一次的cron来更新刚刚过去的一个月的物化视图。我认为我们将远离这个问题。我将在今天晚些时候或明天更新主要帖子，更多地解释视图以及如何生成统计数据。我想知道的是，为什么会出现这种性能损失，为什么会如此严酷。我的意思是5百万行的计数不到1秒，24小时后7分钟。这不应该发生，当然。这也会有所帮助，解释分析将证实我前面提到的另一个假设，即并发事务将最初缓存的表数据从RAM中移出，并导致大量磁盘I/O。