Question

我们最近从mysql迁移到postgres 9.4并且得到了一些非常差的性能。每当我们的芹菜群开始工作时，所有cpu核心都会以100％结束。在此之前来自MySQL，cpus从未真正超过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'

Answer 1

PostgreSQL后端是新进程。即使他们从postmaster开始编写fork（），因此他们避免了大量的启动开销，但他们并不是免费的。

尽管如此，这种比较还有很多错误，你将苹果与油轮进行比较。

您每次迭代都使用sudo。 为什么？的。这与你正在做的事情完全无关，而且大大超过了其他一切的成本。没有它，我的笔记本电脑上的相同测试需要0.1秒。
您正在比较命令行客户端启动时间以及连接/断开连接时间。这不一定意味着与您的申请有关。
您连续100次连接，而不是并行连接。行为将完全不同。您的应用一次只能做一件事。
无论如何，任何合理的应用程序池连接，并避免连接启动/关闭开销。如果您没有并且无法轻松修复，请将PgBouncer作为连接池代理放在应用程序和PostgreSQL服务器之间。

如果您遇到性能问题，则需要在编制不相关的基准之前识别它们是什么。

您会发现log_min_duration_statement设置很有用，log_lock_waits也是如此。也许是auto_explain模块和pg_stat_statements模块。

要获得更多系统级瓶颈查找工作，请使用top，vmstat，iostat，iotop，如果您真的需要深入了解，{{1} }。

此外，更多连接并不意味着更好。我对大多数人的系统所做的最大的性能改进是缩小了他们的连接池。有一个8核服务器具有相当快的存储？然后从50到100连接将可能只是减慢它，从100到500将磨它爬行。

最后，如果你实际上连接时间较慢，那么主要考虑的是主动连接过多，过饱和I / O，内存耗尽导致交换，以及DNS启用反向查找问题。

Answer 2

这个结果只是我所期待的更多。在建立会话时，PostgreSQL只会执行 lot 更多的工作。没有一艘游轮比摩托艇更长的启动时间，但你应该明白这一点。

通常，应用程序或数据库驱动程序应该 - 并且将 - 重用数据库会话。

如果您的应用程序没有，很可能有人（错误？）以这种方式配置它。那么这将是最容易解决的问题。

如果您的应用无法重复使用会话，或者您无法配置应用，因为您只是＆＃34;只是＆＃34; DB-Admin：寻找能够做到这一点的Pgpool。

调试慢postgres服务器连接

2 个答案: