我们目前有一个Postgres数据库，其中有100个表，其中20个行超过5 000 000行，主数据库服务器在Debian 32MB RAM 8处理器上运行。
除了主数据库之外，我们还使用Slony复制了一个Slave数据库。
我们的应用程序使用Java和Hibernate框架进行SQL查询，将c3p0用作连接池。
我们的问题是，在低流量时间期间，我们预计当前高峰时段的高负荷在30左右和4左右。 目前，我们没有在主语句和从属语句之间使用负载均衡来选择语句。
Postgres主数据库的配置如下：
shared_buffers = 6144MB
temp_buffers = 16MB
max_prepared_transactions = 20
work_mem = 128MB
max_fsm_pages = 409800
autovacuum已启用。
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语句。
答案 0 :(得分：2)
有一个基本的介绍，要调整PostgreSQL参数调用，你应该阅读Tuning Your PostgreSQL Server。你没有触及影响性能的两个最重要的因素：effective_cache_size，一个糟糕的设置会搞砸查询计划，而checkpoint_segments你必须要从数据库中获得合适的写入速度。如果您有复杂的查询，请查看default_statistics_target。您可能还需要Log difficult queries然后Use Explain找出他们运行缓慢的原因。
答案 1 :(得分：1)
除非您使用2PC，否则您的max_prepared_transactions应为0。
work_mem对于200个连接来说太高了。您可能希望将其降至32M左右。这可能会导致您进行交换，这对您的表现来说将是灾难性的。
也就是说，将连接池限制为＆lt;＆lt; 200个连接以获得最佳性能。可能大约50左右会给你最好的表现。
对于FSM，这完全取决于您的访问模式。如果您升级到8.4，那么您将自动调整一个，因此单独升级可能是理由（当然还有更多）。
如果不了解更多有关系统的信息，那么很难说更多。您可能希望找一家PostgreSQL咨询公司为您提供完整的绩效评估。
一般情况下，如果你设置得恰到好处，使用这么小的数据库，应该可以获得相当不错的性能。