Медленно выполняющиеся операторы postgresql commit

Question

В веб-приложении Django с бэкэндом postgresql (и обратным прокси nginx с сервером приложений gunicorn) я вижу десятки COMMIT сообщений в медленном журнале postgresql. Вот:

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

БД, о которой идет речь, только что мигрировала с одного выделенного сервера на другой в день go. В прежней среде COMMIT никогда не появлялся в 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 ранее)

А также несколько других изменений, где I увеличил пороги (что должно быть хорошо).

Может ли эксперт подсказать, могли ли внесенные мной изменения привести ко всем заявлениям 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. Перегруженная память. Это может быть вызвано

   • большим объемом ввода / вывода.

   • Множество небольших транзакций, где запросы WAL syn c слишком много.

2. WITH HOLD курсоров при больших запросах.

Вкл. Linux, отметьте %iowait столбец в vmstat 1, чтобы увидеть, перегружена ли подсистема ввода / вывода.

О ваших мерах:

• Увеличение max_connections или уменьшение checkpoint_completion_target иметь отрицательный эффект, если что-нибудь.

• Увеличение shared_buffers поможет, если проблема заключается в количестве считанных операций ввода-вывода.

• Если проблема заключается в большом количестве запросов syn c, и вы можете позволить себе потерять несколько совершенных транзакций в случае cra sh, установите synchronous_commit = off.

  Если это не вариант, Вы можете поиграть с commit_delay, чтобы уменьшить нагрузку ввода / вывода.

Я никогда не слышал о "рабочих-гентах", поэтому ничего не могу о них сказать.