2

我们目前有一个 Postgres 数据库，其中包含 100 个表，其中 20 个具有超过 5 000 000 行，主数据库服务器在 Debian 32MB RAM 8 处理器上运行。

除了主数据库，我们还有一个使用 Slony 复制的从数据库。

我们的应用程序使用 Java 和 Hibernate 框架进行 SQL 查询，c3p0 作为连接池。

我们的问题是，我们预计当前高峰时段的高负载大约是 30 点，而低流量时段大约是 4 点。目前我们没有在选择语句中使用主从之间的负载平衡。

Postgres master DB的配置如下：

shared_buffers = 6144MB
temp_buffers = 16MB
max_prepared_transactions = 20
work_mem = 128MB
max_fsm_pages = 409800

自动真空已开启。

c3p0 Hibernate连接池配置为：

 <property name="c3p0.min_size">3</property>
 <property name="c3p0.max_size">200</property>
 <property name="c3p0.timeout">300</property>
 <property name="c3p0.max_statements">1000</property>
 <property name="c3p0.idle_test_period">300</property>

我们面临的一个主要问题是选择查询非常复杂，有很多连接甚至联合。

调整、扩展我们的实际系统并避免高负载的解决方案是什么？

升级硬件？主从之间的负载平衡？配置错误？

有什么比 slony 更好的负载平衡复制系统的建议吗？

优化 SQL 语句是不可能的，因为我们不是在开发软件。

4

2 回答 2

2

您应该阅读PostgreSQL 参数调整的基本介绍，称为Tuning Your PostgreSQL Server 。您没有触及影响性能的两个最重要的事情：effective_cache_size，一个不好的设置会搞砸查询计划，以及 checkpoint_segments，您必须提高它才能从数据库中获得不错的写入速度。如果您有复杂的查询，也可以查看 default_statistics_target。您可能还想记录困难的查询，然后使用解释找出它们运行缓慢的原因。

于 2010-01-20T06:45:15.017 回答
1

除非您使用的是 2PC，否则您的 max_prepared_transactions 应该为 0。

work_mem 对于 200 个连接来说太高了。您可能希望将其降低到 32Mb 左右。这可能会导致您进行交换，这将对您的表现造成灾难性的影响。

也就是说，将您的连接池限制为 << 200 个连接以获得最佳性能。大概 50 左右会给你最好的性能。

至于 FSM，这完全取决于您的访问模式是什么。如果您升级到 8.4，您将自动调整该版本，因此仅此一项可能就是升级的原因（当然还有更多）。

如果不了解更多关于系统的信息，很难说更多。您可能想寻找一家 PostgreSQL 咨询公司来为您提供完整的性能评估。

一般来说，对于这么小的数据库，如果设置得当，应该可以从中获得相当不错的性能。

于 2010-01-19T10:33:58.970 回答