postgresql – Postgres创建/恢复在amazon ec2上花费了大量时间

发布时间：2020-12-13 16:07:26 所属栏目：百科来源：网络整理

导读：我有一个亚马逊ec2实例(SAY S1)(4核-7GB内存)使用Ubuntu 12.04,它使用 postgresql 9.1运行我的网络应用程序.所有postgres数据都存储在100 GB的不同ssd卷(非root)上. (现在写下它目前只有26％满). 突然间,一天或两天的postgres行动开始耗费大量时间.创建命令(

我有一个亚马逊ec2实例(SAY S1)(4核-7GB内存)使用Ubuntu 12.04,它使用 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

aws上的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(但老实说,我认为这无论如何都不是问题)

解决方法

所以最后这个问题得到了解决.并且发现它是在后台运行的 postgres statistics collector并且发出了许多小的(少于256 KB)io请求(因为我们有100 dbs)消耗掉100GB磁盘的所有300 IOPS.导致所有postgres操作被安排在队列中,并且需要花费大量时间来处理.

Postgres文件说

The statistics collector transmits the collected information to
backends (including autovacuum) through temporary files. These files
are stored in the 07001 subdirectory. When the postmaster shuts
down,a permanent copy of the statistics data is stored in the global
subdirectory. For increased performance,the parameter
stats_temp_directory can be pointed at a RAM-based file system,
decreasing physical I/O requirements.

我通过在tmpfs文件系统中挂载pg_stats_tmp将pg_stats_tmp文件指向ram而不是磁盘.这个blog解释了如何一步一步地做到这一点.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!