Postgres Тюнинг и масштабирование

Question

У нас есть база данных Postgres с 100 таблицами 20 из них с более чем 5 000 000 строк, главный сервер БД работает на процессорах Debian 32MB RAM 8.

Дополнительно к основной БД у нас есть Slave DB, реплицированная с использованием Slony.

В нашем приложении используется Java и Hibernate для SQL-запроса c3p0 в качестве пула соединений.

Наша проблема заключается в том, что в настоящее время мы ожидаем высоких нагрузок во время пикового времени около 30 и около 4 во время низкого трафика. В настоящее время мы не используем балансировку нагрузки между ведущим и ведомым для операторов выбора.

Конфигурация мастер-БД Postgres выглядит следующим образом:

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 невозможна, потому что мы не разрабатываем программное обеспечение.

Answer 1

Если вы не используете 2PC, ваши max_prepared_transactions должно быть 0.

work_mem слишком высока для 200 соединений. Вероятно, вы захотите отбросить его до 32 МБ или около того. Это может привести к тому, что вы поменяете место, что будет катастрофическим для вашей работы.

Это означает, что ваш пул подключений до < < 200 соединений для лучшей производительности. Вероятно, около 50 или около того даст вам лучшую производительность.

Что касается FSM, это полностью зависит от вашего шаблона доступа. Если вы обновляетесь до 8.4, у вас будет один автонастройка, так что одна может быть причиной для обновления (есть еще много, конечно).

Довольно сложно сказать гораздо больше, чем это, не зная намного больше о системе. Возможно, вам захочется обратиться к одной из консалтинговых компаний PostgreSQL, чтобы дать вам полный обзор производительности.

В целом, с такой небольшой базой данных, если вы правильно настроили ее, вы можете получить довольно хорошую производительность.

Answer 2

Существует базовое введение параметров PostgreSQL для настройки под названием Tuning Your PostgreSQL Server, которые вы должны прочитать. Вы не трогаете две из самых важных вещей, которые влияют на производительность: effective_cache_size, что плохой параметр для предотвращения планирования запросов и checkpoint_segments, которые вы должны поднять, чтобы получить приличную скорость записи из базы данных.Если у вас сложные запросы, посмотрите на default_statistics_target в порядке. Вам также может понадобиться Log difficult queries, а затем Use Explain, чтобы узнать, почему они работают медленно.