Настройка и масштабирование Postgres

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

В дополнение к основной БД у нас есть подчиненная БД, реплицированная с помощью 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:

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


person SPC    schedule 19.01.2010    source источник


Ответы (2)


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

person Greg Smith    schedule 20.01.2010
comment
Используя результаты объяснения, вы сможете определить новые индексы, которые улучшат производительность операторов sql, не изменяя их. - person crowne; 20.01.2010

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

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

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

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

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

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

person Magnus Hagander    schedule 19.01.2010