MrM*_*age 3 postgresql google-cloud-sql postgresql-performance autovacuum
我们的 Postgres 数据库(托管在具有 1 个 CPU、3.7 GB RAM 的 Google Cloud SQL 上,见下文)主要由一个大约 90GB 的大表组成,大约有大约 6000 万行。使用模式几乎完全由附加和靠近表末尾的一些索引读取组成。有时会删除一些用户,删除散布在表中的一小部分行。
这一切正常,但每隔几个月就会在该表上触发自动清理,这会显着影响我们服务的性能约 8 小时:
这会在 autovacuum 期间将我们服务的第 95 个延迟百分位数从 ~100ms 增加到 ~0.5-1s,从而触发我们的监控。该服务每秒处理大约 10 个请求,每个请求由一些简单的 DB 读/写组成,每个请求的延迟通常为 2-3 毫秒。
以下是一些说明问题的监控屏幕截图:
数据库配置相当普通:
记录此 autovacuum 过程的日志条目如下所示:
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
Run Code Online (Sandbox Code Playgroud)
有什么建议我们可以调整以减少未来 autovacuums 对我们服务的影响?还是我们做错了什么?
如果您可以增加autovacuum_vacuum_cost_delay,您的自动真空吸尘器会运行得更慢并且侵入性更小。
但是,通过设置autovacuum_vacuum_cost_limit为 2000 左右来使其更快通常是最佳解决方案。然后它完成得更快。
您也可以尝试VACUUM在最不痛的时候自己安排表的s。
但坦率地说,如果一个无害的 autovacuum 足以干扰您的操作,您需要更多的 I/O 带宽。
| 归档时间: |
|
| 查看次数: |
2133 次 |
| 最近记录: |