アマゾンec2で多くの時間を費やしてPostgresを作成/復元します

Question

postgresql 9.1でWebアプリケーションを実行しているUbuntu 12.04を使用してamazon ec2インスタンス（SAY S1）（4core-7GBメモリ）を使用しています。すべてのpostgresデータは、100 GBの異なるssdボリューム（rootではなく）に保存されます。 （今は現在26％満額のみ）。

突然、1日から2回のポストグルアクションから多くの時間がかかり始めました。コマンドを作成し（52秒）、dbを復元します（9分、以前は最大50秒）。

postgresコマンドを実行しているときにiostatを実行すると、限界に達したec2ボリュームのIOPS（3 IOPS/GBは100 GBボリュームの場合は300 IOPSに等しい）が確認できます。このコマンドを実行した後、下に表示されますiostat -d 5 -x -p xvdf。 AWSに

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の要求をとる以下のようにIOPS要求のより数を得られたライトバックするデータの小さなブロックを使用して、Postgresがあると言いますか？

ポストグルのデータがルートボリュームにあり、そのパフォーマンスが優れている別のec2インスタンス（S2と言ってください）が100GBのボリューム（95％が完全なものです）を持っています。ボリュームの大きさは私がここでは関係ないと確信しているものです。

影響を受けるS1のボリュームにはpostgresデータしか格納されませんが、iostatでは以下の統計情報が表示されます。なぜ統計がそうであるのか分からず、どうやってボリュームのサイズを大きくしなくてもpostgresコマンドの時間を短縮することができます。 postgresのの影響を受けたボリュームは110メガバイト/ DBの平均サイズは100種類のPostgresのDBが含まれています（正直なところ、私はこれがどのような場合にはあるとは思わない：

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 

注意（すべての操作しながら3ギガバイトのメモリは常に無料です）問題）

Answer 1

最後にこの問題は解決しました。そして、それはバックグラウンドで実行されていたpostgres statistics collectorで、100GBディスクの300 IOPSすべてを外食していたことがわかりました。その結果、すべてのpostgresアクションがキューにスケジュールされ、処理に多くの時間がかかりました。

Postgresの文書が

統計情報コレクタは、一時ファイルから（自動バキュームを含む） バックエンドに収集した情報を送信すると言います。これらのファイル は、サブディレクトリpg_stat_tmpに格納されています。ポストマスターが をシャットダウンすると、統計データの永続コピーがグローバル サブディレクトリに保存されます。パフォーマンスを向上させるために、パラメータ stats_temp_directoryをRAMベースのファイルシステムで指し示すことができます。 物理I/O要件が減少します。

私はpg_stats_tmpファイルを、tmpfsファイルシステムにpg_stats_tmpをマウントすることで、代わりにramに指摘しました。このblogは、ステップバイステップで行う方法を説明しています。