Pgpool-II не завершает бездействующее соединение.

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение
Заключение

Вопрос или проблема

Мы используем pgpool II с тремя базами данных PostgreSQL – одной основной и двумя репликами. Среда работает в k8s, развернутая с помощью helm-чарта bitnami postgresql-ha.

Конфигурация pgpool II следующая:

Мы запускаем несколько java-сервисов, которые подключаются к базе данных. Сервисы основаны на Micronaut и используют HikariCP для источника данных. Проблема, которую мы видим, заключается в том, что со временем накапливаются IDLE-соединения с базой данных. В нашей stage-среде работают четыре сервиса, которые подключаются к базе данных. maxPool в HikariCP установлен на 10, поэтому наше понимание заключается в том, что мы должны видеть максимум 40-45 соединений. Но за ночь их накопилось до 56. Что еще более странно, кажется, что активно используются только около 12 – остальные кэшируются pgpool (так как они находятся в состоянии DISCARD ALL), но по конфигурации они должны были быть закрыты уже давно – некоторые существуют уже несколько часов:

Если мы подключаемся к базе данных напрямую с сервисами, то все работает без проблем, так что это определенно проблема конфигурации pgpool II. Мы что-то упускаем в конфигурации или есть какая-то проблема?

Ответ или решение

Pgpool-II — это мощный инструмент для управления соединениями в кластерах PostgreSQL, и, как в любой сложной системе, неправильная настройка может привести к неожиданным результатам. В описанном вами случае, проблема связана с накоплением неактивных (IDLE) подключений, которые, как кажется, налагают дополнительную нагрузку на систему и могут влиять на её производительность.

Теория

Прежде чем погрузиться в решение вашей проблемы, давайте разберёмся, как работает Pgpool-II. Это промежуточный слой между вашими приложениями и кластером баз данных, который оптимизирует управление соединениями и распределяет их между различными репликами и основным сервером. Основной механизм, лежащий в основании Pgpool-II, называется пуллингом соединений, который уменьшает накладные расходы на установку новых соединений к серверу базы данных посредством повторного использования существующих соединений.

Одним из ключевых параметров в этом контексте является idle_timeout, который определяет максимальное время ожидания неактивных соединений до их автоматического закрытия. Потенциальная проблема, с которой вы столкнулись, заключается в том, что этот механизм либо не настроен, либо не функционирует должным образом.

Пример

Ваше окружение работает с использованием кластера PostgreSQL, состоящего из основной базы данных и двух реплик, развернутых с помощью Bitnami PostgreSQL-HA Helm Chart в Kubernetes. Вы используете Pgpool-II для управления соединениями к этим базам данных от множества Java-сервисов, построенных на Micronaut и использующих HikariCP в качестве пула подключений.

Согласно вашему описанию, в ночное время, когда активность сервисов должна быть минимальной, количество соединений к базе данных значительно превышает ожидаемое число. Это может указывать на то, что соединения не закрываются должным образом, несмотря на то, что механизм DISCARD ALL (который удаляет временные данные сессии в PostgreSQL) запускается.

Применение

Теперь следует рассмотреть несколько возможных причин возникновения этой проблемы и способов её решения:

Проверка и корректировка конфигурации Pgpool-II:
- idle_timeout: Убедитесь, что в конфигурации Pgpool-II (обычно в pool.conf) правильно задан параметр idle_timeout. Стандартное значение может быть выше, чем ожидаемое, что и приводит к описанному поведению.
- connection_life_time: Дополнительно, проверьте connection_life_time. Этот параметр задаёт максимальное общее время существования соединения в пулах, и его значение также влияет на накопление соединений.
- Проверка лога Pgpool-II: Посмотрите логи Pgpool-II на предмет ошибок или предупреждений, которые могут указывать на проблемы с закрытием соединений.
Настройки HikariCP:
- Проверьте, как настроен пул HikariCP: важны параметры maxLifetime и idleTimeout.
- Убедитесь, что значения этих параметров согласованы с idle_timeout Pgpool-II для оптимальной работы пула соединений.
Мониторинг и отчетность:
- Используйте инструменты мониторинга для отслеживания состояния соединений. Это может помочь определить, когда и почему происходит накопление неактивных соединений.
Оптимизация базы данных и запросов:
- Убедитесь, что запросы, обрабатываемые через Pgpool-II, выполняются эффективно и не задерживают соединения дольше необходимого.
Обновление до последней версии:
- Убедитесь, что используемая вами версия Pgpool-II является последней. Если нет, то обновите её, так как в новых версиях могут быть исправлены обнаруженные баги, связанные с управлением соединениями.

Заключение

Подводя итог, проблема, с которой вы столкнулись, — это результат несогласованности настроек между вашим приложением, HikariCP и Pgpool-II. Основной задачей является обеспечение соответствия всех параметров управления соединениями. Особенно важно обратить внимание на настройки таймаутов в конфигурации Pgpool-II, а также на параметры вашего пула соединений. Проверьте журналы и обновите компоненты системы до последних версий, чтобы исключить влияние ранее известных технических проблем. Этот процесс потребует времени и тщательного анализа, но его выполнение значительно улучшит производительность и надежность вашего кластерного окружения.