В PostgreSQL каждое соединение имеет выделенный бэкэнд. Этот бэкэнд не только содержит состояние соединения и сеанса, но также является механизмом выполнения. Бэкэнды не так уж и дешевы, чтобы их можно было лежать без дела, и они требуют затрат памяти и синхронизации даже в режиме ожидания.
Существует оптимальное количество активно работающих бэкэндов для любого данного сервера Pg в любой заданной рабочей нагрузке, где добавление большего количества рабочих бэкэндов замедляет работу, а не ускоряет ее. Вы хотите найти эту точку и ограничить количество бэкэндов до этого уровня. К сожалению, волшебного рецепта для этого нет, в основном это касается бенчмаркинга - на вашем оборудовании и с вашей рабочей нагрузкой.
Если вам нужно больше соединений, чем это, вы должны использовать прокси или систему пула, которая позволяет вам отделить «состояние соединения» от «механизма выполнения». Два популярных варианта: PgBouncer и PgPool-II . Вы можете поддерживать легкие соединения между вашим приложением и прокси / пулером и позволить ему планировать рабочую нагрузку, чтобы сервер базы данных работал с оптимальной нагрузкой. Если поступает слишком много запросов, некоторые ждут выполнения, вместо того чтобы конкурировать за ресурсы и замедлять все запросы на сервере.
См. postgresql wiki .
Обратите внимание, что если ваша рабочая нагрузка в основном для чтения, и особенно если в ней есть элементы, которые не часто меняются, для которых вы можете определить надежную схему аннулирования кэша , вы также можете потенциально использовать memcached или Redis уменьшить нагрузку на вашу базу данных. Это требует изменения приложения. LISTEN и NOTIFY в PostgreSQL помогут вам сделать нормальную аннулирование кэша.
Многие ядра СУБД имеют некоторое разделение механизма исполнения и состояния соединения, встроенного в структуру ядра СУБД. Sybase ASE, конечно, делает, и я думаю, что Oracle тоже, но я не слишком уверен в последнем. К сожалению, из-за модели PostgreSQL «один процесс на соединение» ему нелегко обойти работу между бэкэндами, что усложняет PostgreSQL эту задачу, поэтому большинство людей используют прокси или пул.
Я настоятельно рекомендую вам прочитать Высокая производительность PostgreSQL . У меня нет никаких связей или связей с Грегом Смитом или издателем *, я просто думаю, что это здорово и будет очень полезно, если вы беспокоитесь о производительности вашей БД.
* ... ну, я не знал, когда писал это. Сейчас я работаю в той же компании.