【巡检问题分析与最佳实践】RDS PostgreSQL 实例IO高问题

往期分享

RDS MySQL 小版本升级最佳实践

RDS MySQL 实例空间问题

RDS MySQL 内存使用问题

RDS MySQL 活跃线程数高问题

RDS MySQL 慢SQL问题

RDS MySQL 实例IO高问题

IO基本概念


  • IO,就是对磁盘进行读写的动作。
  • IO延时,一个IO操作的执行时间。
  • 逻辑IO,由应用程序发给文件系统的IO。
  • 物理IO,由文件系统发给磁盘的IO。
  • 顺序IO,顺序的从磁盘进行读写动作。
  • 随机IO,随机的访问磁盘进行读写操作。
  • 同步写,需要等数据完全写入磁盘进行返回。
  • 异步写,无需等待数据写入磁盘进行返回,释放CPU资源。

IO高的常见原因

SQL扫描行高

查看资源监控的数据盘IOPS

【巡检问题分析与最佳实践】RDS PostgreSQL 实例IO高问题

可以发现基本都是读占用的,一般客户端SQL访问的数据都是从数据库共享缓冲区进行返回,如果数据未在共享缓冲区命中就会需要从磁盘中进行读取,读的IOPS比较高,说明大量的从磁盘读取数据到数据库共享缓冲区中,可能存在SQL扫描行较高的情况。

查看引擎监控

【巡检问题分析与最佳实践】RDS PostgreSQL 实例IO高问题

发现全表扫描行明显增加,说明客户端读取了大量的数据。

查看性能洞察

【巡检问题分析与最佳实践】RDS PostgreSQL 实例IO高问题

可以找到对应的问题SQL,可以对问题SQL进行索引优化或者增加规格承担更高的负载。

导入数据

查看资源监控的数据盘IOPS

【巡检问题分析与最佳实践】RDS PostgreSQL 实例IO高问题

从图中可以看出有大量的写入IOPS,怀疑存在大量的数据导入动作。

查看das中的性能洞察可以发现是由该操作导致的IOPS升高

【巡检问题分析与最佳实践】RDS PostgreSQL 实例IO高问题

尽量避免高峰期的数据导入动作。

Vacuum操作

vacuum指的是PostgreSQL需要对垃圾数据进行清理动作,一般update和delete过程,数据表会产生垃圾数据造成膨胀,需要及时通过vacuum进行清理回收空间。

查看资源监控的数据盘IOPS

【巡检问题分析与最佳实践】RDS PostgreSQL 实例IO高问题

此时可以看到IOPS中读写都占用了较多的资源。

查看引擎监控操作行数

【巡检问题分析与最佳实践】RDS PostgreSQL 实例IO高问题

此时发现操作行数没有明显增加,此时可以怀疑是vacuum或者CheckPoint引起的IOPS升高,通过查询pg_stat_progress_vacuum可以查看当前正在运行vacuum的动作及vacuum的进度。可以确定是由vacuum引起的IOPS升高。


postgres=# select * from pg_stat_progress_vacuum ;
-[ RECORD 1 ]------+--------------
pid                | 109229
datid              | 13593
datname            | postgres
relid              | 40435
phase              | scanning heap
heap_blks_total    | 943453
heap_blks_scanned  | 937101
heap_blks_vacuumed | 0
index_vacuum_count | 0
max_dead_tuples    | 291
num_dead_tuples    | 0


通过pg_stat_user_tables也可以查看历史vacuum的情况


postgres=# select * from pg_stat_user_tables where relname ='t_all';
-[ RECORD 1 ]-------+------------------------------
relid               | 40435
schemaname          | public
relname             | t_all
seq_scan            | 4547
seq_tup_read        | 35959634448
idx_scan            |
idx_tup_fetch       |
n_tup_ins           | 91514896
n_tup_upd           | 0
n_tup_del           | 0
n_tup_hot_upd       | 0
n_live_tup          | 91514896
n_dead_tup          | 0
n_mod_since_analyze | 0
last_vacuum         | 2020-11-20 14:25:19.077927+08
last_autovacuum     |
last_analyze        |
last_autoanalyze    | 2020-11-20 11:59:34.641906+08
vacuum_count        | 1
autovacuum_count    | 0
analyze_count       | 0
autoanalyze_count   | 5


对于vacuum引起的IO升高可以通过调整vacuum相关参数进行降低vacuum对IO产生的影响。

【巡检问题分析与最佳实践】RDS PostgreSQL 实例IO高问题

autovacuum_vacuum_cost_delay指的是vacuum动作代价达到autovacuum_vacuum_cost_limit时vacuum进程休息的时间单位是ms。autovacuum_vacuum_cost_limit指的是vacuum进程代价评估的阈值。通过这两个参数调整可以很大程度降低vacuum操作对于生成环境IO的影响,同时也需要考虑vacuum回收速度慢也会导致表膨胀的更加严重。

CheckPoint

CheckPoint指的是将数据库共享缓冲区的脏页进行写入到磁盘的操作,一般该行为由四种条件触发

    • 定时触发,通过checkpoint_timeout参数定时将将数据库共享缓冲区的脏页进行写入到磁盘,此行为为异步写,数据分多次小批量写入磁盘,对IO影响小。
    • wal日志写入量达到max_wal_size触发,wal日志是循环使用的,当日志量达到max_wal_size,会触发积极的CheckPoint,此行为为同步写,会全速进行数据写入动作,对IO影响大。
    • 手动CheckPoint,此行为为同步写,会全速进行数据写入动作,对IO影响大。
    • 重启实例,此行为为同步写,会全速进行数据写入动作,对IO影响大。


目前对于这种情况可以通过查询pg_stat_bgwriter分析,checkpoints_timed指的是定时触发的次数,checkpoints_req指的是手动触发以及wal日志写入量达到max_wal_size触发,如果checkpoints_req高需要关注是否有大批量导入的情况,可以控制批量导入的大小,最好调整为小批量,多批次导入。


postgres=# select * from pg_stat_bgwriter ;
-[ RECORD 1 ]---------+------------------------------
checkpoints_timed     | 8271
checkpoints_req       | 160
checkpoint_write_time | 9109283
checkpoint_sync_time  | 22878
buffers_checkpoint    | 1228674
buffers_clean         | 829714
maxwritten_clean      | 293
buffers_backend       | 3731358
buffers_backend_fsync | 0
buffers_alloc         | 2290169
stats_reset           | 2020-06-28 15:32:00.021466+08


上一篇:【巡检问题分析与最佳实践】RDS PostgreSQL 慢SQL问题


下一篇:超级高兴.flex builder 的插件拷贝可以 在 eclipse 3.5 里面运行.