Postgresql 调试慢速postgres服务器连接

我们最近从mysql迁移到postgres 9.4，性能非常差。每当芹菜集群开始工作时，所有cpu核心都会100%运行。在此之前，来自MySQL的CPU从未真正超过20%

我不确定从哪里开始，但我这样做是为了快速测试。这可能不太重要，但我认为这将是对连接速度的测试。所以我至少知道，在我进入查询性能之前，我就已经失去了很多连接时间

# Postgres
$ time for i in `seq 1 100`; do sudo -u postgres psql db -c "select 1" > /dev/null; done

real    0m5.498s
user    0m3.317s
sys     0m0.660s

# MySQL
$ time for i in `seq 1 100`; do mysql -uroot -ppass db -e 'select 1;' > /dev/null; done

real    0m0.664s
user    0m0.153s
sys     0m0.310s

Postgres配置如下所示

data_directory = '/data/pg_data'
hba_file = '/etc/postgresql/9.4/main/pg_hba.conf'
ident_file = '/etc/postgresql/9.4/main/pg_ident.conf'
external_pid_file = '/var/run/postgresql/9.4-main.pid'

listen_addresses = '192.168.172.34, localhost'
port = 5432
max_connections = 200
unix_socket_directories = '/var/run/postgresql'
ssl = true
ssl_cert_file = '/etc/ssl/certs/ssl-cert-snakeoil.pem'
ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key'

shared_buffers = 1GB
work_mem = 5242kB
maintenance_work_mem = 256MB
dynamic_shared_memory_type = posix

wal_buffers = 16MB                      # min 32kB, -1 sets based on shared_buffers
checkpoint_segments = 32                # in logfile segments, min 1, 16MB each
checkpoint_completion_target = 0.7      # checkpoint target duration, 0.0 - 1.0

effective_cache_size = 3GB
default_statistics_target = 100

log_line_prefix = '%t [%p-%l] %q%u@%d '
log_timezone = 'UTC'
stats_temp_directory = '/var/run/postgresql/9.4-main.pg_stat_tmp'

datestyle = 'iso, mdy'
#intervalstyle = 'postgres'
timezone = 'UTC'
#timezone_abbreviations = 'Default'
#extra_float_digits = 0
#client_encoding = sql_ascii

lc_messages = 'en_US.UTF-8'
lc_monetary = 'en_US.UTF-8'
lc_numeric = 'en_US.UTF-8'
lc_time = 'en_US.UTF-8'

default_text_search_config = 'pg_catalog.english'

---

PostgreSQL后端是新的进程。尽管它们是邮政局长提供的，因此避免了大量启动开销，但它们不是免费的

尽管如此，这种比较有很多错误，以至于你把苹果比作油轮

• 每次迭代都使用

  sudo

  。为什么？这与你正在做的事情完全无关，并且大大超过了其他一切的成本。如果没有这些，同样的测试在我的笔记本电脑上需要0.1秒

• 您正在比较命令行客户端启动时间和连接/断开连接时间。这不太可能意味着与您的应用程序相关的任何内容

• 您正在串行连接100个连接，而不是并行连接。行为将完全不同。你的应用程序不太可能一次只做一件事

• 任何合理的应用程序都会共享连接，并避免连接启动/关闭开销。如果您的应用程序不能也无法轻松修复，请在应用程序和PostgreSQL server之间放置PgBouncer作为连接池代理

如果您有性能问题，您需要在制定不相关的基准之前确定它们是什么

您会发现

log\u min\u duration\u语句

设置很有用，就像

log\u lock\u waitis

一样。也可能是

auto_explain

模块和

pg_stat_语句

模块

对于更多的系统级瓶颈查找工作，请使用

top

、

vmstat

、

iostat

、

iotop

，如果您真的需要投入精力，请使用

perf

此外，更多的联系并不意味着更好。我对大多数人的系统所做的最大的性能改进就是缩小他们的连接池。有一台8核服务器，存储速度非常快？然后，从50个连接到100个连接可能会使其速度变慢，从100个连接到500个连接将使其变得缓慢

---

最后，如果您的连接速度确实很慢，那么主要的问题是活动连接太多、I/O过饱和、导致交换的内存耗尽以及启用DNS问题的反向查找。

这一结果比我预期的要多一点。在建立会话时，PostgreSQL只需做更多的工作。不像游轮比摩托艇需要更长的启动时间，但你应该明白这一点

通常情况下，应用程序或DB驱动程序应该——并且将——重用DB会话

如果您的应用程序没有这样做，很可能是有人（错误？）以这种方式配置了它。这将是最简单的解决办法

---

如果你的应用程序不能重复使用会话，或者你不能配置应用程序，因为你“只是”DB管理员：寻找能做到这一点的Pgpool。

你的“测试”只测量{连接建立+授权+空查询+空结果+连接故障}使用实际查询获得实际性能测量值的时间。设置

log\u min\u duration\u语句

以检测慢速查询，并检查它们的查询计划我知道，但很明显连接/身份验证/断开连接花费的时间比我认为的要长得多。或者这对postgres来说是正常的？你以前的连接/断开率是多少？如果无法使用应用内连接池，则可能需要将PgBouncer放在PostgreSQL前面，以执行服务器端连接池。高连接/断开连接率不会表现得很好，如果MySQL在这方面速度更快，我也不会太惊讶。它通常是在做很多非常小，简单，轻量级的操作。不过请注意，您正在测试的是

psql

启动时间，而不仅仅是服务器连接时间。谢谢，我会调查一下。哦，您可能只是使用了太多的连接。试着限制在20左右。是的，真的。除非您有某种64核monster服务器，否则您将通过更少的连接获得更好的结果。