我的postgres最近运行速度非常缓慢，一个月的聚合通常最终花费超过1分钟（更确切地说，最后一个花了7分钟和23秒）。
上周五我重新创建了服务器（主服务器和副本服务器）并重新导入了数据库。
我注意到的第一件事是从133gb现在数据库是42gb（实际数据大约是12gb，我猜其余的是索引）。
一切都很快就像一天一样，在索引完成之后（索引上26gb），现在我又回到了1。
大约500万行的计数需要3分42秒。
使autovacuum更具攻击性，现在看来它正在做它的工作，但数据库仍然很慢。
我正在使用db作为API，因此它不断增长。 Atm我有2个表，一个有大约5密耳行，另一个有28密耳。
因此，如果主人有很多活动并且让我说我期待一些性能损失，那么我不会期望它来自副本。
重要的是，重启后它真的快了一个小时左右。
我注意到的另一件事是，在每次查询时，我都会将IO设为100％，而内存和CPU几乎完全没有使用。
非常感谢任何帮助。
更新
小型机器上的相同数据库就像魅力一样。 相同的查询，相同的索引。 唯一的区别是流量，而不是写作或更新那么多。
我也忘了提一件事，我的一个索引是聚集的。
直播机是一个5核，64GB和3k IO。 测试机器是2核心，4GB和SSD。
更新
找到我的问题。 显然，autovacuum无法获得锁定，当它获得锁定时，死元组会增加。
现在使autovacuum更具攻击性并删除了一堆未使用的索引。
仍然不知道如何修复锁定问题。
更新
看起来有些东西增加了估计的行数。 自从我上次更新以来，行数增加了2 mil。 我想明天行数将再次大约为12 mil，而且计数将会再次缓慢。
这可能与autovacuum有关吗？
更新 很好找到了我的问题。 看起来postgres在写密集型数据库上失去了很多速度。 有一个用作标志的列，每天更新很多次。 标志和更新被删除后，一切看起来都非常好。
关于如何在写密集型表上修复此问题的任何线索？
答案 0 :(得分：0)
可能是以下指针帮助：
您真的确定要为API执行5mil行聚合吗？每次 ？你不能将数据拆分成块，这样只有少量的块实际上可以获得大部分新行（因此所有以前的块的聚合可以重用于下一个查询）吗？时间就是一个这样的衡量标准，序列号可能是另一个，等等。如果是这样，分区数据是一个你应该调查的明显解决方案，它确实很有可能给你亚秒查询时间（假设你存储以前块的聚合）巧妙地）。
关于第一个小时魔术的预感是，虽然这个数据适合RAM，但并发查询会推送数据设置，然后是纯粹的磁盘I / O ......在这种情况下，CPU / RAM处于空闲状态并不奇怪。
最后，我认为这个设置要求重新设计，其中只有一个SQL可以做很多事情，并且期望不在RAM内的数据的亚秒查询时间一个5密耳的数据集可能过于乐观了！
（尽管如此，如果可能，请发布您的发现）