【问题标题】:PostgreSQL autovacuum causing significant performance degradationPostgreSQL autovacuum 导致性能显着下降
【发布时间】:2019-02-22 16:22:27
【问题描述】:

我们的 Postgres 数据库(托管在具有 1 个 CPU、3.7 GB 内存的 Google Cloud SQL 上,见下文)主要由一个约 90 GB 的大表组成,其中包含约 6000 万行。使用模式几乎完全由追加和表末尾附近的一些索引读取组成。有时会删除一些用户,删除分散在表中的一小部分行。

这一切都很好,但每隔几个月就会在该表上触发一次自动清理,这会显着影响我们服务的性能大约 8 小时:

  • 在 autovacuum 期间(几个小时),存储使用量增加了约 1GB,然后慢慢恢复到之前的值(由于 autovacuum 释放页面,最终可能会低于该值)
  • 数据库 CPU 利用率从
  • 磁盘读/写操作数从接近零增加到 ~50/秒
  • 数据库内存略有增加,但保持在 2GB 以下
  • 事务/秒和入口/出口字节也几乎不受影响,正如预期的那样

这会在自动清理期间将我们服务的第 95 个延迟百分位从约 100 毫秒增加到约 0.5-1 秒,这反过来又会触发我们的监控。该服务每秒处理大约 10 个请求,每个请求由几个简单的数据库读取/写入组成,每个请求通常有 2-3 毫秒的延迟。

以下是一些说明问题的监控屏幕截图:

数据库配置相当普通:

记录此自动清理过程的日志条目如下:

system usage: CPU 470.10s/358.74u sec elapsed 38004.58 sec
avg read rate: 2.491 MB/s, avg write rate: 2.247 MB/s
buffer usage: 8480213 hits, 12117505 misses, 10930449 dirtied
tuples: 5959839 removed, 57732135 remain, 4574 are dead but not yet removable
pages: 0 removed, 6482261 remain, 0 skipped due to pins, 0 skipped frozen
automatic vacuum of table "XXX": index scans: 1

我们有什么建议可以调整以减少未来自动清理对我们服务的影响吗?还是我们做错了什么?

【问题讨论】:

    标签: postgresql google-cloud-sql postgresql-performance autovacuum


    【解决方案1】:

    如果您可以增加autovacuum_vacuum_cost_delay,您的自动真空吸尘器会运行得更慢并且侵入性更小。

    但是,将autovacuum_vacuum_cost_limit 设置为 2000 左右来使其更快通常是最好的解决方案。然后它完成得更快。

    您也可以尝试自己安排VACUUMs 在最不痛的时候。

    但坦率地说,如果一个无害的 autovacuum 足以干扰您的操作,那么您需要更多的 I/O 带宽。

    【讨论】:

    • 谢谢,增加autovacuum_vacuum_cost_delay减少 autovacuum_vacuum_cost_limit 有助于提高服务性能,但当然会使autovacuum 花费更长的时间(但这很好)。我怀疑 Google 对 100 GB 永久性磁盘的约 3k IOPS 和 50 MB/s 吞吐量限制(请参阅cloud.google.com/compute/docs/disks/performance)在此有问题。
    • 进一步延迟 autovacuum 是一条危险的道路。你被警告了!我愿意花钱买更多的存储带宽。
    • 我实际上增加了 autovacuums 的频率(将比例因子从 0.2 降低到 0.01),同时降低了它们的速度。所以每个单独的 autovacuum 应该有更少的工作要做。
    • 这将使 autovacuum 一直运行。您应该监控它是否完成并且膨胀没有增加。
    • 如何在 GCP @LaurenzAlbe 上安排 VACUUM?
    猜你喜欢
    • 2018-10-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-04-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多