PostgreSQL снижает производительность после миграции - PullRequest
Новая
       8

PostgreSQL снижает производительность после миграции

0 голосов
/ 15 января 2019

После миграции сервера баз данных PostgreSQL v9.3 на v9.6 я заметил снижение производительности всей системы. Параметры конфигурации такие же, как в версии 9.3, с учетом следующих параметров:

  1. shared_buffers = 10000MB
  2. work_men = 64 МБ
  3. maintenance_work_men = 1024 МБ

Также я пытался отслеживать некоторые ресурсы, и это результат 

              total        used        free      shared  buff/cache   available
Mem:            31G        385M        4.5G         10G         26G 19G
Swap:          3.0G          0B        3.0G

Также, когда я запускаю некоторые запросы, сервер внутренне запускает такие запросы: 

select typname from pg_type where oid=1043
set search path to public
deallocate pdo_stmt_0000000e

И затем запускает мой запрос, но я боюсь, что это повлияет на производительность после миграции. У меня есть другой сервер 9.6 с новой установкой без миграции, и он не представляет эту проблему (время отклика). Кажется, он тратит слишком много времени на эти запросы.

У вас есть совет или совет, как это исправить?

Я сделал это с pg_upgrade, но заметил, что в процессе некоторые данные не переносятся на сервер v9.6. После этого я сделал процесс дампа / восстановления и vacuum analyze.

1 Ответ

0 голосов
/ 22 января 2019

вы можете установить расширение pg_stat_statements в медленной и быстрой системе и сравнить производительность самых популярных запросов в обеих системах. При наличии существенных отличий времени / исполнения вы можете проверить планы выполнения (используя объяснение анализа).

Иногда новые функции оказывают существенное влияние на производительность после обновления. Если моя память хорошо мне подходит, параллельное последовательное сканирование - https://blog.2ndquadrant.com/postgresql96-parallel-sequential-scan/ - было добавлено в 9.6. Хотя это в основном отличная функция, в некоторых ситуациях ее использование может привести к замедлению запросов. Это может послужить причиной для установки для параметра parallel_setup_cost (или других параметров планировщика) другого значения, чтобы избежать неэффективного параллельного последовательного сканирования.

Отредактировано позже: как я вижу в https://www.postgresql.org/docs/9.6/release-9-6.html, параллельное выполнение запроса не было активировано по умолчанию, поэтому, вероятно, это не является причиной замедления вашей ситуации. Тем не менее, я думаю, что только анализ производительности самых популярных запросов и их планов может пролить свет на эту проблему.

...