postgresql - Postgres 创建/恢复在亚马逊 ec2 上花费大量时间

Question

我有一个使用 Ubuntu 12.04 的亚马逊 ec2 实例 (SAY S1)(4 核 7GB 内存)，它正在使用 postgresql 9.1 运行我的网络应用程序。所有 postgres 数据都存储在 100 GB 的不同 ssd 卷(不是根)上。 (现在只写它目前的 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

IO characteristics在 aws 上说每个 IOPS 需要 256KiB 或更少的请求，那么 postgres 是否使用更小的数据 block 写回导致更多的 IOPS 请求？

虽然我有另一个 100GB 容量的 ec2 实例(比如 S2)(现在 95% 已满)，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 数据库，平均大小为 110 MB/db(但老实说，我认为这无论如何都不是问题)

Answer 1

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

Postgres 文档说

The statistics collector transmits the collected information to backends (including autovacuum) through temporary files. These files are stored in the pg_stat_tmp subdirectory. When the postmaster shuts down, a permanent copy of the statistics data is stored in the global subdirectory. For increased performance, the parameter stats_temp_directory can be pointed at a RAM-based file system, decreasing physical I/O requirements.

我通过在 tmpfs 文件系统中安装 pg_stats_tmp 将 pg_stats_tmp 文件指向 ram 而不是磁盘。这blog解释了如何一步一步地做到这一点。