Question

将PostgreSQL数据库服务器v9.3迁移到v9.6之后，我注意到整个系统的性能下降。配置参数与v9.3中的相同，其中考虑了以下参数：

shared_buffers = 10000MB
work_men = 64MB
maintenance_work_men = 1024MB

我也试图监视一些资源，这就是结果

              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。

Answer 1

您可以在慢速和快速系统上安装pg_stat_statements扩展，并比较两个系统中最热门查询的性能。如果时间/执行方式存在重大差异，则可以检查执行计划（使用解释分析）。

有时，新功能在升级后会对性能产生重大影响。如果我的记忆很好，则在9.6中添加了并行顺序扫描-Create an empty migration and use the following operation-。尽管这基本上是一个很棒的功能，但是在某些情况下使用它可能会导致查询速度变慢。这可能是将parallel_setup_cost（或其他计划程序参数）设置为不同值的原因，以避免无效的并行顺序扫描。

稍后编辑：正如我在https://blog.2ndquadrant.com/postgresql96-parallel-sequential-scan/中所看到的那样，并行查询执行默认未激活，因此这可能不是您情况变慢的原因。我仍然认为，只有对热门查询的性能及其计划进行分析才能阐明这一问题。

Answer 2

在我们的例子中，我们忽略了：

git config --local core.hooksPath .git/hooks 数据库

Postgres 在大规模迁移后可能特别需要它。

例如，当将 django 2.2 升级到 3.2 并且所有 ANALYZE 字段类型都从 id 更改为 AutoField

PostgreSQL迁移后会降低性能

2 个答案: