Добрый день.

Есть Tomcat 9.
Есть примерно N REST сервисов, каждое из которых - отдельное веб-приложение.
Все эти N сервисов задеплоены на один томкат.

Есть один инстанс Postgres.

Сейчас каждое из REST-приложений использует свой экземпляр ConnectionPool.
Предположим, каждый пул резервирует M -соединений.

Поэтому, может оказаться такая картина, что даже без нагрузки на web-приложения,
в памяти будет удерживаться N * M idle-соединений.

Либо другая ситуация:
веб-приложение A будет более высоконагруженное, чем приложение B.
В этом случае - ресурсы (connections) приложения B будут простаивать.

Мне кажется, лучше использовать общий пул, на весь tomcat. И каждое из приложений будет его использовать (например через JNDI).

Не будет ли в данном решении узких мест?
Тоесть, еще раз резюмируя главный вопрос:

Что лучше - отдельный ConnectionPool для каждого веб-приложения, либо общий пул на все?

BlazkowiczУ вас у каждого модуля свой пул внутри реализован?

У каждого модуля одинаковая конфигурация пула. Используется одинаковая БД.

unicornmirageBlazkowiczУ вас у каждого модуля свой пул внутри реализован?

У каждого модуля одинаковая конфигурация пула. Используется одинаковая БД.

Просто каждый модуль держит открытым свой инстанс пула.
Конфиг пула для каждого модуля примерно такой:

BlazkowiczunicornmirageУ каждого модуля одинаковая конфигурация пула. Используется одинаковая БД.
В Context.xml?

Нет, модули не используют конфиг из context.xml, а создают пул программно.

Petro123unicornmirageМне кажется, лучше использовать общий пул, на весь tomcat. И каждое из приложений будет его использовать (например через JNDI).
да вроде нет никаких противопоказаний.
JNDI он и в африке JNDI

Есть один аргумент против такого подхода - microservice architecture.
Если будет общий пул на все REST-сервисы, то при его переполнении - все выйдут из строя.
Если будет каждый пул на каждый REST-сервис - то выйдет из строя только одно (самое высоконагруженное)

no56892unicornmirage,
Что мешает сделать пул на каждое приложение + minIdleConnections = 0?

по-умолчанию этот параметр итак равен 0, согласно исходникам GenericObjectPool:

public static final int DEFAULT_MIN_IDLE = 0;

BlazkowiczunicornmirageЕсть один аргумент против такого подхода - microservice architecture.
Если будет общий пул на все REST-сервисы, то при его переполнении - все выйдут из строя.
Если будет каждый пул на каждый REST-сервис - то выйдет из строя только одно (самое высоконагруженное)
У вас все модули в одной JVM крутятся. Что нивелирует все вышеперечисленные аргументы.

Потому что узким местом здесь будет JVM, tomcat?

можно поподробнее, почему нивелирует?

Blazkowiczunicornmirageможно поподробнее, почему нивелирует?
Переполнение памяти одним модулем - все умрут.
Повышенная нагрузка на один модуль - все тормозят.
Поэтому достижение потолка соединений в пуле, это лишь одна из не многих потенциальных проблем.
Микросервисы же это отдельные процессы. Они на много более независимы чем JEE модули.

Ок, предположим проблем с переполнением самой памяти нет.
А существует только проблема переполнения connection pool (ведь мы указываем для него лимит соединеий).
В данном случае - пул будет узким местом.

Petro123unicornmirage,
..."Жениться или не жениться - вот в чём вопрос.
А если жениться, то куда девать нынешнюю жену?"
))

другими словами - в данном случае - надо использовать то, что удобнее. ))

По-поводу проблемы с idle-соединениями: я попробовал задать следующие параметры для пула:

setMaxActive = 30
setMaxIdle = 10
setInitialSize = 10
setTimeBetweenEvictionRunsMillis = 30000
setMinEvictableIdleTimeMillis = 60000

Такая конфирурация включает pool sweeper.

И получилась такая картина:
1. стартует сервис. При первом обращении выделяется 10 idle-connections в пуле.
2. если немного подождать (пару минут), то все idle-connections удаляются из пула.
3. если загрузить сервис кучей запросов, то пул вырастает согласно необходимому количеству, которое требуется для обработки.
4. если снова подождать пару минут - пул снова полностью очищается.

Кажется, это то, что нужно. И в данном случае не обязательно использовать общий пул на весь томкат.

Basil A. SidorovunicornmirageВ данном случае - пул будет узким местом.Ох уж это решение проблем, которые ещё даже не обозначились ...
Вам какая разница будет к базе тысяча подключение из одного пула или тысяча подключений из десяти пулов???

Разница обозначена в начальном топике:
если будет тысяча подключений из десяти пулов, и одна часть пулов будет менее загружена, чем другая - то часть idle-connections (из менее нагруженных пулов) не будет использоваться. Тоесть будут просто вхолостую висеть в памяти.

Petro123unicornmirage,
Почему вы все не конкретно?
Сколько байт в памяти занимает простаивающий коннект?

Вот статистика только одного пула (с помощью программы pg_top):

PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
10020 postgres 20 0 208M 9648K sleep 0:00 0.00% 0.00% postgres: postgres db1 127.0.0.1(57165) idle
10019 postgres 20 0 208M 7472K sleep 0:00 0.00% 0.00% postgres: postgres db1 127.0.0.1(57164) idle
10017 postgres 20 0 208M 7472K sleep 0:00 0.00% 0.00% postgres: postgres db1 127.0.0.1(57162) idle
10015 postgres 20 0 208M 7472K sleep 0:00 0.00% 0.00% postgres: postgres db1 127.0.0.1(57160) idle
10018 postgres 20 0 208M 7472K sleep 0:00 0.00% 0.00% postgres: postgres db1 127.0.0.1(57163) idle
10016 postgres 20 0 208M 7472K sleep 0:00 0.00% 0.00% postgres: postgres db1 127.0.0.1(57161) idle
10014 postgres 20 0 208M 7472K sleep 0:00 0.00% 0.00% postgres: postgres db1 127.0.0.1(57159) idle
10012 postgres 20 0 208M 7472K sleep 0:00 0.00% 0.00% postgres: postgres db1 127.0.0.1(57157) idle
10013 postgres 20 0 208M 7472K sleep 0:00 0.00% 0.00% postgres: postgres db1 127.0.0.1(57158) idle
10011 postgres 20 0 208M 7472K sleep 0:00 0.00% 0.00% postgres: postgres db1 127.0.0.1(57156) idle

Если на томкате поднять все 10 приложений, то pg_top будет показывать 100 idle-connections.
Я эту проблему решил, включив опции пула для pool sweeper. Который после некоторого времени бездействия, удаляет все idle-connections.