Настройка пула подключений PostgreSQL для веб-приложений требует баланса между производительностью и стабильностью. Основная задача — предотвратить исчерпание лимитов базы данных при пиковых нагрузках. В конфигурации postgresql.conf параметр max_connections определяет общее число соединений, доступных системе. Для веб-нагрузок этот показатель часто становится узким местом из-за накладных расходов на каждое соединение. Параметр shared_buffers выделяет память для кэша данных в общей памяти сервера. Его размер зависит от объема оперативной памяти и влияет на скорость чтения данных, но не решает проблему исчерпания соединений. В файле pg_hba.conf задаются правила доступа: кто, откуда и каким методом может подключаться. Для веб-сервера (Nginx/Apache) обычно используется метод scram-sha-256 или md5, а не trust. На стороне приложения (PHP/Python/Node.js) необходимо использовать драйверы с поддержкой пулинга, такие как pgbouncer для внешнего уровня или встроенные библиотеки (PDO_PGSQL, psycopg2) с настройкой pool_size. Параметр work_mem контролирует память на одно соединение. При высокой нагрузке его увеличение может привести к фрагментации памяти и падению сервера, поэтому рекомендуется использовать значения по умолчанию или слегка увеличенные. Мониторинг подключений осуществляется через системные команды (psql, pg_stat_activity) и метрики в Prometheus/Grafana. Критическим признаком является состояние active для всех доступных соединений. При использовании pgbouncer важно правильно настроить параметры pool_mode (transaction или statement) в зависимости от требований приложения к транзакционности.
Настройка пула подключений PostgreSQL для веб-приложений
Настройка пула подключений PostgreSQL — это не просто изменение цифр в конфигурационных файлах, а создание архитектуры, способной выдерживать скачки нагрузки без потери доступности. Основная проблема веб-приложений заключается в том, что каждое HTTP-запрос от пользователя часто требует отдельного соединения с базой данных. При высокой посещаемости количество таких соединений может быстро превысить лимит `max_connections`, после чего база перестает отвечать на запросы, даже если свободна память и диски.
Решение строится на двух уровнях: настройка самого сервера PostgreSQL и внедрение внешнего пулера. На уровне СУБД параметр `max_connections` ограничивает общее число одновременных сессий. Для веб-серверов это часто становится узким местом, так как каждое соединение потребляет ресурсы памяти (включая `work_mem`, `maintenance_work_mem`) и требует обработки сетевых пакетов. Увеличение этого значения без соответствующего роста оперативной памяти приведет к тому, что сервер начнет сбрасывать старые соединения или падать при попытке создать новые.
Второй уровень — использование пулера подключений, такого как `pgbouncer`. Этот инструмент работает как прокси между веб-сервером (Nginx/Apache) и базой данных. Он принимает множество коротких соединений от приложения и переиспользует их для выполнения запросов к PostgreSQL. Это позволяет обслуживать тысячи пользователей с ограниченным числом физических подключений к базе. Важно правильно выбрать режим работы пулера: `transaction` возвращает соединение после завершения транзакции, а `statement` — после каждого SQL-запроса. Выбор режима зависит от требований вашего приложения к целостности данных и скорости обработки.
На стороне приложения (PHP, Python, Node.js) необходимо убедиться, что используемые драйверы поддерживают работу с пулами. Библиотеки вроде `PDO_PGSQL`, `psycopg2` или официальные драйверы для Node.js позволяют настраивать размер пула (`pool_size`) и время ожидания соединения. Если приложение само управляет подключениями без внешнего пулера, оно должно уметь корректно закрывать их после использования, чтобы не накапливать «мертвые» сессии в памяти базы.
Мониторинг состояния подключений критически важен для раннего обнаружения проблем. Используйте системные команды `psql` и таблицы статистики `pg_stat_activity`, чтобы отслеживать количество активных (`active`) и ожидающих (`waiting`) соединений. Если все доступные соединения находятся в состоянии `active` или `idle in transaction`, это сигнал о том, что пул переполнен или есть блокировки, требующие вмешательства. Интеграция этих метрик в Prometheus/Grafana позволит видеть нагрузку в реальном времени и автоматически перезагружать пулер при необходимости.
Параметр `work_mem` контролирует объем памяти, выделяемый на одно соединение для сортировок и хеш-таблиц. При высокой нагрузке его чрезмерное увеличение может привести к фрагментации памяти и падению сервера, так как общая память ограничена. Рекомендуется использовать значения по умолчанию или слегка увеличенные, но с учетом общего лимита `max_connections`. Также в файле `pg_hba.conf` для веб-серверов следует использовать методы аутентификации `scram-sha-256` или `md5`, избегая метода `trust`, который небезопасен при подключении из внешней сети.
Ошибки на этом этапе часто связаны с попыткой увеличить `max_connections` без анализа потребления памяти и игнорирования необходимости в пулере. Также распространена практика использования режима `transaction` там, где требуется высокая скорость обработки простых запросов, что увеличивает время ожидания соединения. Правильная настройка требует баланса: достаточно соединений для пиковой нагрузки, но не настолько много, чтобы исчерпать оперативную память или вызвать таймауты в приложении.
Настройка параметра max_connections и роль пулинга
Параметр `max_connections` в файле конфигурации PostgreSQL (`postgresql.conf`) задает жесткий лимит на количество одновременных сессий. Для веб-приложений этот показатель часто становится узким местом, так как каждое соединение требует выделения памяти и обработки сетевых пакетов. При достижении предела новые запросы от пользователей получают ошибку `FATAL: too many connections`, что приводит к падению доступности сервиса.
Просто увеличивать значение `max_connections` без анализа архитектуры — ошибка. Каждое соединение занимает ресурсы оперативной памяти (включая буферы, планы выполнения и контекст). Если веб-сервер (Nginx/Apache) генерирует тысячи коротких запросов в секунду, база данных не успеет обработать их через прямые соединения. В результате система начнет сбрасывать старые сессии или блокировать новые, что нарушит работу приложения.
Решение лежит в использовании внешнего пулера подключений, такого как `pgbouncer`. Этот инструмент работает как прокси между веб-сервером и базой данных. Он принимает множество коротких соединений от клиентов, а затем открывает ограниченное количество длинных сессий к PostgreSQL. Это позволяет обслуживать тысячи пользователей при фиксированном количестве активных подключений в базе.
При выборе режима работы пулера (`pool_mode`) важно понимать разницу между `transaction` и `statement`. Режим `transaction` сохраняет соединение открытым на время всей транзакции клиента, что подходит для сложных операций с несколькими запросами. Режим `statement` возвращает соединение в пул после каждого отдельного SQL-запроса, что быстрее для простых чтений, но увеличивает нагрузку на базу при частых обновлениях. Для большинства веб-приложений рекомендуется использовать режим `transaction`, если приложение поддерживает его корректно.
В конфигурации самого PostgreSQL параметр `shared_buffers` отвечает за кэширование данных в оперативной памяти. Его размер должен составлять от 10% до 25% от доступной RAM, но он не решает проблему исчерпания лимита соединений. Параметр `work_mem` контролирует память на одно соединение (сортировки, хэш-таблицы). Увеличение этого значения для всех подключений при высокой нагрузке может привести к фрагментации памяти и падению сервера. Рекомендуется использовать значения по умолчанию или слегка увеличенные только для критических операций.
Мониторинг состояния пула необходим для предотвращения аварийных ситуаций. Используйте команды `psql` (например, `SELECT count(*) FROM pg_stat_activity`) или метрики в Prometheus/Grafana. Критическим признаком проблем является состояние `active` для всех доступных соединений в базе данных при наличии новых запросов от пользователей. Это сигнализирует о том, что пул переполнен и новые сессии не могут быть созданы.
Ошибки на этапе настройки часто связаны с попыткой увеличить `max_connections` без анализа потребления памяти и игнорирования необходимости в пулере. Также распространена практика использования режима `transaction` там, где требуется высокая скорость обработки простых запросов, что увеличивает время ожидания соединения. Правильная настройка требует баланса: достаточно соединений для пиковой нагрузки, но не настолько много, чтобы исчерпать оперативную память или вызвать таймауты в приложении.
Настройка параметра shared_buffers
Параметр `shared_buffers` отвечает за выделение памяти под кэш данных внутри сервера PostgreSQL. Это общий пул, доступный всем подключенным сессиям для хранения часто запрашиваемых страниц и результатов запросов. Размер этого буфера напрямую зависит от объема установленной оперативной памяти на сервере.
Для веб-приложений критически важно понимать: увеличение `shared_buffers` ускоряет чтение данных из кэша, но не решает проблему исчерпания лимита подключений (`max_connections`). Если веб-сервер (Nginx/Apache) создает тысячи коротких соединений для каждого запроса, даже идеальный кэш не спасет от падения базы при достижении предела `max_connections`. Поэтому настройка этого параметра — это лишь часть общей стратегии оптимизации памяти.
Рекомендуемый размер `shared_buffers` составляет обычно 25% от доступной оперативной памяти. Например, на сервере с 16 ГБ ОЗУ разумным значением будет 4 ГБ. Однако не стоит выделять более 30–40% памяти под кэш базы данных, так как это оставит недостаточно ресурсов для операционной системы и других процессов. Если вы увеличите `shared_buffers` сверх меры, система может начать использовать файл подкачки, что приведет к резкому падению производительности.
При настройке этого параметра важно учитывать баланс между скоростью чтения и стабильностью работы. Слишком большой буфер может привести к тому, что при пиковой нагрузке сервер не сможет выделить память для новых соединений или процессов сортировки, что вызовет ошибки `out of memory`. Поэтому начните с консервативного значения (например, 2–4 ГБ) и наблюдайте за метриками использования памяти через `pg_stat_activity` и системные утилиты.
Изменение размера `shared_buffers` требует перезагрузки сервера базы данных или выполнения команды `ALTER SYSTEM`, после чего изменения вступят в силу без полной остановки сервиса. Однако для веб-нагрузок важно также проверить, как изменение этого параметра влияет на общее потребление памяти и не приводит ли оно к фрагментации или таймаутам в приложении.
Настройка правил доступа в pg_hba.conf для веб-приложений
Файл `pg_hba.conf` определяет, какие клиенты могут подключаться к базе данных, откуда они исходят и каким способом аутентификации пользуются. Для веб-серверов критически важно запретить метод `trust`, который позволяет подключение без пароля. В среде интернета или даже внутри корпоративной сети использование `trust` для внешних сервисов создает прямую угрозу безопасности: любой, кто сможет подделать IP-адрес веб-сервера или получить доступ к файлу конфигурации, получит полный контроль над данными.
Для взаимодействия с Nginx или Apache стандартным и безопасным выбором являются методы `scram-sha-256` или `md5`. Метод `scram-sha-256` предпочтительнее, так как он использует хеширование пароля с солью, что защищает его от перехвата в сети и последующего перебора. Если ваш веб-сервер находится на том же хостинге, что и база данных (localhost), метод `md5` также допустим, но требует передачи пароля через переменные окружения или файлы конфигурации приложения, а не через URL.
Структура строки в `pg_hba.conf` состоит из четырех полей: тип подключения, IP-адрес или маска сети, имя пользователя и метод аутентификации. Для веб-нагрузки важно настроить правила так, чтобы они проверялись в правильном порядке. PostgreSQL обрабатывает правила сверху вниз, поэтому конкретные исключения должны идти перед общими правилами. Например, сначала разрешите подключение от доверенного IP с паролем, затем запретите все остальные подключения по умолчанию.
Практический пример настройки строки для веб-сервера выглядит следующим образом: `hostssl all web_user 192.168.1.0/24 scram-sha-256`. Здесь указано требование защищенного соединения (SSL), что дополнительно усложняет задачу злоумышленника. Если SSL не обязателен, можно убрать префикс `ssl`, но метод аутентификации должен оставаться строгим. Избегайте записи правил вида `host all all 0.0.0.0/0 trust` даже для локальной разработки в продакшене — это частая ошибка новичков, приводящая к утечкам данных.
После внесения изменений в файл необходимо перезагрузить базу данных или применить изменения динамически через `SELECT pg_reload_conf()`. Однако важно помнить, что метод аутентификации применяется только при новом подключении. Если приложение уже имеет открытые соединения, они не будут прерваны автоматически. Для корректного перехода на новый метод аутентификации потребуется перезапуск приложения или обновление пула подключений, чтобы новые сессии использовали обновленные правила.
Ошибки при настройке часто связаны с неверной маской сети или конфликтом правил. Если вы добавили правило для конкретного IP, но забыли удалить старое общее правило `trust`, подключение может работать, но через старый метод. Это создает риск: если пароль изменен в системе, но база использует старый метод `trust`, доступ останется открытым. Регулярно проверяйте файл конфигурации на наличие дубликатов и противоречий.
Для мониторинга успешности аутентификации используйте логи сервера базы данных (`postgresql.log`). Там будут записаны попытки подключения, которые были отклонены из-за неверного метода или пароля. Если видите много ошибок `FATAL: password authentication failed for user`, проверьте соответствие пароля в базе и в конфигурации веб-сервера. Также следите за сообщениями об отказе в подключении, если маска сети настроена слишком узко.
Важно учитывать, что метод `scram-sha-256` требует поддержки со стороны клиента (драйвера базы данных). Старые версии драйверов PHP или Python могут не поддерживать этот алгоритм. В таком случае придется либо обновить библиотеки, либо временно использовать `md5`, понимая риски. Для современных стеков (PHP 7+, Python 3.8+, Node.js) поддержка `scram-sha-256` является стандартной и не требует дополнительных настроек.
Если веб-сервер использует обратный прокси (например, Nginx), убедитесь, что IP-адрес, с которого идет запрос к базе данных, фиксирован. В некоторых конфигурациях Nginx меняет исходный IP-адрес клиента на адрес самого прокси. В этом случае в `pg_hba.conf` нужно указывать IP-адрес прокси-сервера, а не реального пользователя. Это можно проверить командой `curl -I` или просмотрев логи веб-сервера.
Завершая настройку, помните о принципе наименьших привилегий. Не создавайте универсальный пользователь `web_user` с полным доступом ко всем таблицам. Разделите доступ по ролям: один пользователь для чтения статистики, другой для записи транзакций. Это усложняет атаку: даже если злоумышленник получит доступ к одному пользователю, он не сможет удалить всю базу данных или изменить структуру таблиц.
Настройка пулинга подключений на стороне приложения
Эффективное управление соединениями начинается внутри вашего кода. Даже при идеальной настройке сервера базы данных, приложение может стать узким местом, если каждое запрос создаёт новое соединение и не возвращает его в пул. Это приводит к тому, что `max_connections` исчерпывается за секунды при всплеске трафика.
Для реализации этой задачи существуют два основных подхода: использование внешнего прокси-сервера типа `pgbouncer` или встроенная поддержка пулинга в языках программирования. Выбор зависит от архитектуры вашего стека и требований к транзакционности.
Если вы используете PHP, стандартный драйвер PDO_PGSQL поддерживает пулинг через параметр `PDO::ATTR_PERSISTENT`. Однако для веб-серверов (Nginx/Apache) часто рекомендуются сторонние библиотеки, такие как `pdo-pgsql` с настройкой `pool_size`, которые обеспечивают более гибкий контроль над жизненным циклом соединений. Важно понимать: постоянное соединение (`persistent`) не означает вечное существование; оно просто не закрывается после завершения скрипта, а возвращается в общий пул для повторного использования.
В экосистеме Python библиотека `psycopg2` предоставляет класс `pool`, который позволяет создать пул соединений с заданным размером. Параметр `pool_size` определяет максимальное количество активных подключений к базе данных одновременно. При превышении этого лимита запросы ставятся в очередь, что предотвращает падение приложения, но требует настройки адекватного размера пула относительно нагрузки.
Для Node.js ситуация аналогична: модуль `pg` поддерживает пулинг через параметр `pool`. Здесь также критически важно правильно задать `max` (максимум соединений) и `idleTimeoutMillis` (время простоя соединения перед его закрытием). Если соединение простаивает слишком долго, оно может быть использовано другим запросом, что повышает производительность.
Выбор между внешним пулером (`pgbouncer`) и встроенным пулингом зависит от требований к транзакциям. Встроенный пулинг в коде обычно работает в режиме `transaction` (по умолчанию), где соединение берётся из пула для начала транзакции и возвращается после её завершения. Это подходит для большинства веб-приложений, где каждая страница — это отдельная транзакция.
Использование внешнего уровня (`pgbouncer`) позволяет разделить нагрузку между приложением и базой данных более эффективно. В этом случае приложение подключается к `pgbouncer`, а тот управляет реальными соединениями с PostgreSQL. Параметр `pool_mode` в конфигурации `pgbouncer` определяет поведение: режим `transaction` возвращает соединение после каждой транзакции, что безопасно для большинства случаев, но может быть менее эффективным для приложений, где одна сессия обрабатывает множество запросов без явных коммитов.
Оценка результата настройки пулинга происходит через мониторинг метрик. Если вы видите, что соединения часто ждут в очереди (high wait time), значит, `pool_size` слишком мал для текущей нагрузки. Напротив, если соединения простаивают долго и не используются, можно уменьшить размер пула, чтобы освободить память.
Типичная ошибка — установка чрезмерно большого размера пула без учёта ресурсов сервера. Каждое соединение потребляет оперативную память и CPU на обработку запросов. Если `pool_size` превышает возможности сервера, это может привести к фрагментации памяти или падению производительности при пиковых нагрузках.
Другая ошибка — игнорирование настроек таймаутов. Если соединение не возвращается в пул вовремя из-за неправильных настроек таймаута, оно может занимать место в пуле бесконечно, блокируя доступ для новых запросов. Регулярный анализ логов приложения и базы данных помогает выявить такие проблемы на ранних стадиях.
Настройка параметра work_mem: баланс памяти и стабильности
Параметр `work_mem` определяет объем оперативной памяти, выделяемый для сортировки, группировки и операций с хеш-таблицами на уровне одного соединения. В отличие от общего пула кэша, эта память резервируется динамически под конкретную операцию запроса.
При высокой нагрузке увеличение `work_mem` может привести к фрагментации памяти и падению сервера. Это происходит потому, что каждая тяжелая операция (например, сортировка большого набора данных) потребляет выделенный лимит. Если одновременно выполняется множество таких операций, они могут исчерпать доступную память быстрее, чем система успеет её освободить.
Рекомендуется использовать значения по умолчанию или слегка увеличенные в зависимости от архитектуры сервера. Для большинства веб-приложений стандартное значение (обычно 4 МБ на соединение) является оптимальным компромиссом между скоростью выполнения сложных запросов и безопасностью системы.
Мониторинг подключений PostgreSQL
Для контроля состояния пула подключений используются системные команды и специализированные метрики. Основной инструмент — консольная утилита `psql`, которая позволяет в реальном времени видеть, сколько соединений активно, какие запросы выполняются и есть ли блокировки.
Второй уровень мониторинга строится на сборе метрик через Prometheus с визуализацией в Grafana. Это дает возможность отслеживать динамику нагрузки, выявлять аномалии и строить графики для анализа пиковых нагрузок.
Критическим признаком перегрузки является ситуация, когда все доступные соединения находятся в состоянии `active`. В этом случае новые запросы от веб-сервера будут отвергаться с ошибкой «too many connections», что приведет к падению функциональности сайта или приложения.
Настройка пула подключений PostgreSQL через pgbouncer
Для веб-приложений использование `pgbouncer` является стандартным решением, позволяющим экономить ресурсы базы данных. Однако выбор режима работы (`pool_mode`) критически влияет на корректность обработки транзакций и целостность данных.
Существует три основных режима: `transaction`, `statement` и `session`. Режим `transaction` создает отдельное соединение для каждой транзакции клиента, возвращая его в пул после завершения. Это наиболее безопасный вариант для большинства веб-приложений, так как гарантирует изоляцию транзакций.
Режим `statement` возвращает соединение в пул сразу после выполнения каждого SQL-запроса. Это позволяет обслуживать больше одновременных запросов при ограниченных ресурсах, но требует от приложения строгой дисциплины: каждая операция должна завершаться явным коммитом или ролбэком. Если приложение использует неявные транзакции (автокоммит), этот режим может привести к ошибкам.
Режим `session` держит соединение открытым на протяжении всего времени работы клиента. Он наиболее ресурсоемкий и подходит только для специфических сценариев, например, когда клиенту требуется постоянное соединение с базой данных.
Вопросы и ответы
Какой режим пулинга (pool_mode) выбрать в pgbouncer?
Выбор зависит от требований к транзакционности. Режим `transaction` позволяет одному клиенту использовать одно соединение для нескольких запросов, но требует, чтобы все запросы в рамках одной транзакции шли через это же соединение. Это подходит для большинства веб-приложений. Режим `statement` создает новое соединение для каждого отдельного SQL-запроса (даже внутри одной транзакции), что снижает нагрузку на приложение, но увеличивает количество соединений к БД. Режим `session` держит соединение открытым до конца сессии клиента, что может привести к исчерпанию лимитов при высокой нагрузке.
Как определить оптимальное значение для shared_buffers?
Обычно рекомендуется выделять от 25% до 40% доступной оперативной памяти сервера под общий кэш данных (shared_buffers). Остальную память следует оставить для операционной системы, процессов приложения и других служб. Точное значение зависит от типа нагрузки: если много чтений, можно увеличить долю памяти под кэш; при интенсивных вычислениях лучше сохранить больше памяти для work_mem.
Что делать, если база данных возвращает ошибку 'too many connections'?
Сначала проверьте текущее количество активных соединений через команду `SELECT count(*) FROM pg_stat_activity;`. Если оно близко к значению max_connections, необходимо либо увеличить этот лимит (с учетом доступной памяти), либо внедрить пул подключений (например, pgbouncer или встроенный в приложение). Также стоит проверить наличие «зомби»-соединений и настроить автоматическое завершение неактивных сессий.
Можно ли использовать trust для подключения веб-сервера?
Нет, использование trust для внешних сервисов или веб-серверов недопустимо. Этот метод позволяет подключаться без пароля, что создает критическую уязвимость безопасности. Для веб-приложений следует использовать scram-sha-256 или md5 с паролем, а также ограничить доступ через IP-адреса в файле pg_hba.conf.
Как настроить автоматическое завершение неактивных соединений?
В параметрах конфигурации PostgreSQL можно задать время ожидания неактивного соединения (keepalives) и автоматически разрывать сессии, которые не передают данные в течение заданного периода. Это помогает освобождать ресурсы при наличии «зависших» клиентов или скриптов, которые забывают закрыть соединения.
-- Пример безопасной строки для pg_hba.conf
-- Тип: hostssl (защищенное соединение)
-- Пользователь: web_user
-- Сеть: 192.168.1.0/24 (локальная подсеть)
-- Метод: scram-sha-256
hostssl all web_user 192.168.1.0/24 scram-sha-256
-- Пример с использованием md5 для локального хоста (если SSL не обязателен)
host all web_user 127.0.0.1/32 md5
-- ОШИБОЧНЫЙ пример: использование trust в продакшене
-- host all all 0.0.0.0/0 trust -- Никогда не используйте это!
<?php
// Пример настройки пулинга в PDO для PHP
define('PDO_PGSQL_PERSISTENT', true);
$dsn = 'pgsql:host=localhost;dbname=mydb';
$options = [
PDO::ATTR_PERSISTENT => true,
PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"
];
try {
$pdo = new PDO($dsn, $user, $pass, $options);
} catch (PDOException $e) {
echo 'Connection failed: ' . $e->getMessage();
}
?>
// Примечание: для более гибкого управления пулом в PHP часто используют сторонние библиотеки,
// такие как pdo-pgsql с параметром pool_size, которые обеспечивают лучший контроль над жизненным циклом соединений.import psycopg2
from psycopg2 import pool
# Создание пула соединений
connection_pool = pool.SimpleConnectionPool(
host="localhost",
port=5432,
database="mydb",
user="web_user",
password="secure_password",
min_size=2, # Минимальное количество соединений в пуле
max_size=10, # Максимальное количество соединений (pool_size)
max_overflow=5 # Доп. соединения при перегрузке
)
# Получение соединения из пула для выполнения запроса
conn = connection_pool.getconn()
cursor = conn.cursor()
cursor.execute("SELECT version();")
print(cursor.fetchone())
conn.commit()
connection_pool.putconn(conn) # Возврат соединения в пул# Пример настройки в postgresql.conf
# work_mem = 4MB (значение по умолчанию)
# work_mem = 16MB (увеличение для сложных аналитических запросов)
work_mem = 8MB-- Просмотр всех активных подключений
SELECT pid, usename, application_name, client_addr, state, query
FROM pg_stat_activity
WHERE datname = 'ваше_имя_бд' AND state = 'active'
ORDER BY query_start DESC;
-- Подсчет количества активных соединений по базе
SELECT count(*) as active_connections FROM pg_stat_activity WHERE datname = 'ваше_имя_бд';[databases]
mydb = host=/var/run/postgresql dbname=mydb
[pgbouncer]
pool_mode = transaction
max_client_conn = 1000
reserve_pool_size = 50
