Эффективность открытия соединений базы данных PostgreSQL

Question

У нас есть база данных PostgreSQL для хранения данных нашего C++-приложения, и мы используем libpqxx для подключения к ней.

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

Согласно PostgreSQL architectural fundamentals,

... [серверный процесс PostgreSQL] начинается ("вилки") новый процесс для каждого соединения.

Это звучит для меня как наш метод открытия нового pqxx::connection для каждой сделки действительно неэффективно, так как мы косвенно нерест несколько десятков новых процессов каждую минуту. Это то, о чем мы действительно должны беспокоиться?

Я вижу here on the PostgreSQL wiki, что PostgreSQL сам по себе не поддерживает пул процессов клиентского подключения, поэтому нам действительно нужно беспокоиться об этом. Если да, существует ли «правильный» способ держать объекты pqxx::connection неограниченно, так что новый процесс не разветвляется каждый раз, когда мне нужно подключиться к базе данных? Имейте в виду, что мое приложение должно запускаться весь день, каждый день, поэтому было бы неприемлемо, чтобы мои TCP-соединения упали после длительного периода времени.

Answer 1

То, что вы делаете, неэффективно, но не так резко. Стоимость вилки PostgreSQL низкая на платформе unix; бэкэнды довольно дешевы для создания и уничтожения.

Установки, аутентификация и т. Д. Требуют времени, поэтому вы увеличите задержки транзакций.

Было бы предпочтительнее использовать пул соединений, как в приложении, так и в прокси, например pgbouncer. Тем не менее, для «нескольких десятков подключений в минуту» я бы не стал слишком беспокоиться, если вы не столкнулись с проблемами с нагрузкой. Это уродливо, но это не так уж плохо.

TCP-соединения не просто «падают» после определенного периода времени. Если вы не находитесь за некоторым ресурсоемким NAT-маршрутизатором или брандмауэром, он может оставаться бездействующим на неопределенный срок. Если вам просто нужно включить TCP keepalives. Нет никакой реальной причины не открывать соединение до тех пор, пока вам нравится.

В любом случае, вашего приложения должна уже повторить логику для потери связи потому что движки не могут умереть из-за админ действие, восстановление после сбоя PostgreSQL сервера и перезагрузки, ошибки, ресурсов сервера утомления, вызывающих ОЫЙ и т.д. Никогда, стрелять и забыть транзакцию. Ваше приложение должно помнить полное состояние, необходимое для повторного завершения всего xact с самого начала, пока оно не получит подтверждение, которое xact совершил из БД. Если на каком-либо этапе произошел сбой, он должен снова подключиться и повторить попытку.