5

Ubuntu 12.04 を使用する amazon ec2 インスタンス (SAY S1) (4 コア 7 GB メモリ) があり、postgresql 9.1. すべての postgres データは、100 GB の別の ssd ボリューム (ルートではない) に保存されます。(現在は 26% のみ使用可能) .

1 日か 2 日から突然、postgres アクションに多くの時間がかかり始めました。コマンドを作成し (52 秒)、データベースを復元します (現在は 9 分、以前は最大 50 秒)。

postgres コマンドの実行中に iostat を実行すると、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

aws のIO 特性によると、各 IOPS は 256KiB 以下のリクエストを受け取るため、postgres はより小さなデータ ブロックを使用して書き戻すため、より多くの IOPS リクエストが発生しますか?

私は100GBのボリューム(現在95%フル)の別のec2インスタンス(S2と言う)を持っていますが、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 db が含まれています (ただし、正直なところ、これが問題になるとは思いません)。

4

1 に答える 1

0

最終的にこの問題は解決しました。そして、バックグラウンドで実行されていて、100GB ディスクの 300 IOPS をすべて使い果たしている小さな (256 KB 未満の) io 要求 (100 以上のデータベースがあるため) を大量に発行していたのはpostgres 統計コレクターであることがわかりました。その結果、すべての postgres アクションがキューにスケジュールされ、処理に多くの時間がかかっていました。

Postgreドキュメントは言う

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

tmpfs filesystem に pg_stats_tmp をマウントすることで、pg_stats_tmpファイルをディスクではなく ram に指定しました。このブログでは、その方法を順を追って説明しています。

于 2015-12-03T05:57:21.613 に答える