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

Question

В настоящее время у нас есть база данных Postgres с 100 таблицами, 20 из которых содержат более 5 000 000 строк, главный сервер БД работает на процессорах Debian 32 МБ RAM 8.

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

Наше приложение использует Java и Hibernate Framework для 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>

Одна из основных проблем, с которой мы сталкиваемся, заключается в том, что запрос select очень сложен, имеет множество объединений и даже объединений.

Каким было бы решение для настройки, масштабирования нашей действительной системы и избежания высокой нагрузки?

Обновить оборудование? Балансировка нагрузки между ведущим и ведомым? Плохая конфигурация?

Есть какие-нибудь предложения по лучшей системе репликации балансировки нагрузки, чем у slony?

Оптимизация операторов SQL невозможна, поскольку мы не разрабатываем программное обеспечение.

Answer 1

Существует базовое введение в параметры PostgreSQL для настройки, которое называется Настройка сервера PostgreSQL , которое вы должны прочитать. Вы не затрагиваете две самые важные вещи, влияющие на производительность: эффективное_cache_size, неправильный параметр для которого испортит планирование запросов, и контрольные точки, которые вы должны увеличить, чтобы получить приличную скорость записи из базы данных. Если у вас сложные запросы, посмотрите на default_statistics_target. Вы также можете Записывать сложные запросы , а затем . Использовать объяснение , чтобы узнать, почему они выполняются медленно.

Answer 2

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

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

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

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

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

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