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解釋瞭如何一步一步做到這一點。