我有一个使用Ubuntu 12.04的亚马逊ec2实例（SAY S1）（4核-7GB内存），它使用postgresql 9.1运行我的网络应用程序。所有postgres数据都存储在100 GB的不同ssd卷（非root）上。 （现在写下它目前只有26％满）。
突然间，一天或两天的postgres行动开始耗费大量时间。创建命令（52秒）并恢复数据库（现在9分钟，最多50秒）。
通过在运行postgres命令时运行iostat，我可以确认其ec2卷的IOPS已达到其限制（3 IOPS / GB等于100 IOPS的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表示每个IOPS接受256KiB或更少的请求，因此postgres使用较小的数据块来回写产生更多的IOPS请求吗？
虽然我有另一个100GB卷的ec2实例（Say 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 db，平均大小为110 MB / db（但老实说，我认为这无论如何都不是问题）
答案 0 :(得分：0)
所以最后这个问题得到了解决。并且发现它是postgres statistics collector在后台运行并且发出了大量小的（少于256 KB）io请求（因为我们有100多个dbs）消耗掉100GB磁盘的所有300 IOPS。导致所有postgres操作被安排在队列中，并且需要花费大量时间来处理。
Postgres文件说
统计信息收集器将收集的信息发送给 后端（包括autovacuum）通过临时文件。这些文件 存储在
pg_stat_tmp子目录中。当邮政局长关闭时 down，统计数据的永久副本存储在全局中 子目录。为了提高性能，参数 stats_temp_directory可以指向基于RAM的文件系统， 降低物理I / O要求。
我通过在tmpfs文件系统中挂载pg_stats_tmp，将pg_stats_tmp文件指向ram而不是磁盘。这个blog解释了如何逐步完成。