诊断PostgreSQL性能下降

Question

[在具有postgresql后端的Django Web应用程序（以及带有gunicorn应用程序服务器的nginx反向代理）中，我在postgresql的慢日志中看到数十条COMMIT消息。看哪：

2020-02-01 17:56:16.335 UTC [19424] ubuntu@app LOG LOG:  duration: 175.630 ms  statement: COMMIT
2020-02-01 17:56:21.355 UTC [19435] ubuntu@app LOG LOG:  duration: 107.735 ms  statement: COMMIT
2020-02-01 17:57:22.592 UTC [19419] ubuntu@app LOG LOG:  duration: 235.313 ms  statement: COMMIT
2020-02-01 17:57:30.685 UTC [19419] ubuntu@app LOG LOG:  duration: 249.875 ms  statement: COMMIT
2020-02-01 17:57:30.688 UTC [19424] ubuntu@app LOG LOG:  duration: 99.049 ms  statement: COMMIT
2020-02-01 17:57:30.688 UTC [19435] ubuntu@app LOG LOG:  duration: 115.772 ms  statement: COMMIT
2020-02-01 17:57:30.688 UTC [19554] ubuntu@app LOG LOG:  duration: 248.656 ms  statement: COMMIT
2020-02-01 17:58:03.266 UTC [19435] ubuntu@app LOG LOG:  duration: 780.232 ms  statement: COMMIT
2020-02-01 17:58:03.270 UTC [19424] ubuntu@app LOG LOG:  duration: 622.424 ms  statement: COMMIT
2020-02-01 17:58:07.579 UTC [19435] ubuntu@app LOG LOG:  duration: 75.658 ms  statement: COMMIT

有问题的数据库一天前刚刚从一台专用服务器迁移到另一台专用服务器。在以前的环境中，COMMIT never出现在slow log中。在新环境中，我进行了一些更改：

1）我设置了checkpoint_completion_target = 0.7（从之前的checkpoint_completion_target = 0.8向下移）

2）我换了用枪眼角的gevent工人（以前使用过sync工人）。这也需要我在postgresql中添加以下内容（允许我们将psycopg2与gevent-source异步使用）：

from psycogreen.gevent import patch_psycopg

def post_fork(server, worker):
  from gevent import monkey

  patch_psycopg()
  worker.log.info("Made PostgreSQL Green!")
  monkey.patch_all()

3）从max_connections增加到400（从以前的300开始）

4）从shared_buffers增加到8GB（从以前的6GB）

还有其他一些我将阈值增加的更改（应该是一件好事）。

专家能否建议我上面所做的更改是否可能导致所有COMMIT语句乱丢我的slow log？如果没有，还有其他猜测吗？

而且最重要的是，我可以采取哪些缓解措施来改善这种情况？

---

vmstat 1产生：

ubuntu@main-app:~$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
16  0      0 10031160 263796 11650344    0    0     2    20    5    4 13  1 86  0  0
 2  0      0 10030184 263796 11650308    0    0     0  1832 8598 9433 20  1 78  0  0
 4  1      0 10028432 263796 11650416    0    0    40   436 7229 7887 20  1 79  0  0
 6  0      0 10027076 263796 11650456    0    0     0   764 7836 8833 17  1 81  0  0
 4  0      0 10025904 263796 11650464    0    0     0   588 7947 9754 22  1 76  0  0
 4  0      0 10025988 263796 11650512    0    0     0   652 9727 12033 30  2 68  0  0
 7  0      0 10025572 263796 11650532    0    0     0   816 8296 9984 25  1 73  0  0
 2  1      0 10025680 263796 11650596    0    0     0  1128 8794 11003 23  1 75  0  0
 0  0      0 10025552 263796 11650588    0    0     0   288 7153 8091 20  1 79  0  0
 6  0      0 10025096 263796 11650612    0    0     0   412 9423 12016 25  2 73  0  0
 1  0      0 10025056 263796 11650640    0    0     0   240 9227 11442 32  2 66  0  0
 6  0      0 10025056 263796 11650800    0    0    32  1036 8762 10418 25  2 73  0  0
 2  0      0 10025116 263796 11650828    0    0     0   352 8730 10924 23  2 75  0  0
 6  0      0 10024992 263796 11650940    0    0     0   592 7920 9399 14  1 85  0  0
 3  0      0 10024288 263796 11650952    0    0     0   380 8380 9662 23  1 75  0  0
 4  0      0 10024536 263796 11650896    0    0     0   680 9193 10819 22  1 76  0  0
 1  0      0 10024720 263796 11650776    0    0     0   588 9655 10757 24  2 74  0  0
 5  0      0 10024820 263796 11650700    0    0     0    48 10237 13216 28  2 70  0  0
 1  0      0 10023660 263796 11650716    0    0     0   396 9291 11251 34  2 64  0  0
 6  0      0 10024564 263796 11650744    0    0     0   720 8557 10500 22  1 76  0  0

Answer 1

对于慢速提交有两种可能的解释：

1. 超载存储。这可能是由于

   • I / O量大。

   • 很多小交易，WAL同步请求太多。

2. [WITH HOLD游标在较大的查询上。

在Linux上，检查%iowait中的vmstat 1列以查看I / O子系统是否过载。

关于您的措施：

• 增大max_connections或减小checkpoint_completion_target将产生不利影响，如果有的话。

• 如果问题是读取的I / O数量，增加shared_buffers会有所帮助。

• 如果问题是同步请求过多，如果发生崩溃，您有可能丢失一些已提交的事务，请设置synchronous_commit = off。

  如果这不是一个选项，则可以使用commit_delay来降低I / O负载。

我从没听说过“ gevent worker”，所以我无话可说。