Postgres create/restore 在 amazon ec2 上花费大量时间
Postgres create/restore taking lot of time on amazon ec2
我有一个使用 Ubuntu 12.04 的亚马逊 ec2 实例（比如说 S1）（4 核 7GB 内存），这是 运行 我的网络应用 postgresql 9.1。所有 postgres 数据都存储在 100 GB 的不同 ssd 卷（不是根）上。 （现在只写它目前的 26%）。
突然间，从一两天开始，一些 postgres 操作开始占用大量时间。创建命令（52 秒）并恢复数据库（现在 9 分钟，之前最多 50 秒）。
通过 运行 iostat 和 运行 postgres 命令，我可以确认其 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 是否使用更小的数据块回写导致更多的 IOPS 请求？
虽然我有另一个 ec2 实例（比如 S2），容量为 100GB（现在 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（但老实说，我不认为这在任何情况下都是问题）
所以这个问题终于解决了。并发现它是 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 解释了如何一步一步地做到这一点。
我有一个使用 Ubuntu 12.04 的亚马逊 ec2 实例（比如说 S1）（4 核 7GB 内存），这是 运行 我的网络应用 postgresql 9.1。所有 postgres 数据都存储在 100 GB 的不同 ssd 卷（不是根）上。 （现在只写它目前的 26%）。
突然间，从一两天开始，一些 postgres 操作开始占用大量时间。创建命令（52 秒）并恢复数据库（现在 9 分钟，之前最多 50 秒）。
通过 运行 iostat 和 运行 postgres 命令，我可以确认其 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 是否使用更小的数据块回写导致更多的 IOPS 请求？
虽然我有另一个 ec2 实例（比如 S2），容量为 100GB（现在 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（但老实说，我不认为这在任何情况下都是问题）
所以这个问题终于解决了。并发现它是 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_tmpsubdirectory. 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 解释了如何一步一步地做到这一点。