5

我有一个使用 Ubuntu 12.04 的亚马逊 ec2 实例(SAY S1)(4core-7GB 内存),它使用postgresql 9.1. 所有 postgres 数据都存储在 100 GB 的不同 ssd 卷(不是 root)上。(现在写它目前只有 26% 已满)。

突然从一两天开始,几个 postgres 操作开始花费大量时间。创建命令(52 秒)并恢复数据库(现在 9 分钟,以前最大 50 秒)。

通过在运行 postgres 命令的同时运行 iostat,我可以确认 ec2 卷的 IOPS 已达到其限制(3 IOPS/GB 等于 100GB 卷的 300 IOPS)。运行此命令后可以在下面看到它iostat -d 5 -x -p xvdf

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdf              0.35     2.28    1.20  298.99    19.65 13082.19    87.29    23.42   78.03   64.19   78.09   3.29  98.75

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdf              0.00     1.80    0.00  297.40     0.00 13067.20    87.88   126.47  420.75    0.00  420.75   3.35  99.76

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdf              0.00     1.80    0.00  297.40     0.00 13067.20    87.88   126.32  417.95    0.00  417.95   3.35  99.76

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdf              0.00     1.80    0.00  297.80     0.00 13093.60    87.94   131.70  440.82    0.00  440.82   3.36 100.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdf              0.00     0.00    0.00  301.00     0.00 13225.60    87.88   129.36  422.97    0.00  422.97   3.32  99.84

aws 上的IO 特性表明每个 IOPS 需要 256KiB 或更少的请求,那么 postgres 是否使用较小的数据块来写回导致更多数量的 IOPS 请求?

虽然我有另一个具有 100GB 卷(现在 95% 已满)的 ec2 实例(比如 S2),但 postgres 数据位于根卷上,并且性能很好。所以体积的大小是我确定在这里无关紧要的东西。

受影响的 S1 卷仅存储 postgres 数据,我仍然可以通过 iostat 看到以下统计信息。不知道为什么统计数据会这样,以及如何在不增加卷大小的情况下减少 postgres 命令时间。(虽然所有操作 3GB 内存始终是空闲的)

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdf              0.34     2.29    1.23  298.93    20.10 13079.03    87.28    26.19   87.26   66.96   87.34   3.29  98.78

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdf              0.00     2.40    0.60  299.00     4.80 13020.80    86.95   132.22  434.48  108.00  435.14   3.34 100.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdf              0.00     3.20    4.40  295.20    43.20 12866.40    86.18   122.18  417.09  142.00  421.20   3.34 100.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdf              0.00     2.80    2.40  297.20    23.20 12940.00    86.54   122.70  401.11  124.00  403.34   3.34  99.92

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdf              0.00     3.40    4.80  294.80    46.40 12840.00    86.02   127.43  433.15  161.67  437.57   3.34  99.92

注意:受影响的 postgres 卷包含 100 个不同的 postgres db,平均大小为 110 MB/db(但老实说,我认为这无论如何都不是问题)

4

1 回答 1

0

所以最后这个问题得到了解决。并发现它是postgres 统计收集器,它在后台运行并发出大量小(小于 256 KB)io 请求(因为我们有 100+ dbs)耗尽了 100GB 磁盘的所有 300 IOPS。结果所有 postgres 操作都安排在队列中,并且需要大量时间来处理。

Postgres 文件说

统计收集器通过临时文件将收集到的信息传输到后端(包括 autovacuum)。这些文件存储在pg_stat_tmp子目录中。当 postmaster 关闭时,统计数据的永久副本存储在全局子目录中。为了提高性能,参数 stats_temp_directory 可以指向基于 RAM 的文件系统,从而降低物理 I/O 要求。

pg_stats_tmp通过在 tmpfs 文件系统中挂载 pg_stats_tmp 将文件指向 ram 而不是磁盘。这个博客解释了如何一步一步地做到这一点。

于 2015-12-03T05:57:21.613 回答