Postgres创建/恢复在亚马逊ec2上花费很多时间

Question

我有一个使用Ubuntu 12.04的amazon ec2实例（SAY S1）（4core-7GB内存），它运行我的web应用程序postgresql 9.1。所有postgres数据都存储在100 GB的不同的ssd卷（不是根目录）上。 （现在写它目前只有26％全）。

突然从一两天的postgres行动开始花费很多时间。创建命令（52秒）并恢复数据库（现在9分钟，以前最多50秒）。

通过在运行postgres命令时运行iostat，我可以确认其ec2卷的IOPS已达到其极限（3 IOPS/GB等于100 GB卷的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的请求或更少，以便是使用数据的更小的块写回所得更多数目IOPS请求的postgres的？

虽然我有另一个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的影响卷包含110 MB/DB的平均尺寸为100不同的Postgres数据库（但老实说，我不认为这是在任何情况下一个问题）

Answer 1

所以最后这个问题得到解决。并且发现它是在后台运行的postgres statistics collector，并且发布了大量小于（不到256 KB）的IO请求（因为我们有100多个数据块），因此可以在100GB磁盘的所有300 IOPS内吞掉这些请求。导致所有postgres操作都排队等待并花费大量时间来处理。

Postgres的文件说

的统计收集器发送所收集的信息来 后端（包括自动清理）通过临时文件。这些文件 存储在pg_stat_tmp子目录中。当postmaster关闭 时，统计数据的永久副本将存储在全局的 子目录中。为了提高性能，参数 stats_temp_directory可以指向基于RAM的文件系统，即 ，从而减少物理I/O需求。

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