Вопрос к знатокам: Предыстория: у меня сервис с сотней нод на

NodeJS, которые подключены к PostgreSQL кластеру. Я заметил в метриках большие значения wait Client:ClientRead. Все квери очень быстрые, lookup by ID, поэтому быстрый поиск указывает скорее всего на долгую обработку в EventLoop в моих приложениях. Заскэйлить горизонтально увеличив количество нод можно, но я боюсь столкнуться с проблемой слишком большого количества connections. На данный момент каждая нода внутри имеет pool 5-20 connections, суммарное к БД в пике открыто 1K connections. для сервера с 4VCPU & 32Gb звучит как очень много.

Я думаю что проблему может решить pgbouncer перед кластером, который бужет менеджить небольшое количество конекшенов (128-256). Я ведь верно понимаю, что connection, который pg_bouncer использует для выполнения запроса моего клиентского придожения, вернется в pool как только PG вернет данные в pg_bouncer? А плтом уже connection между моим NodeJS app и PG_boucner будет залочено?

Я думаю в верном направлении?

У вас бд в виртуальной машине?

Стоит также проинспектировать ваши приложения на предмет логики в nodeJS с множеством обращений к бд при обработке одного запроса, которую можно одним чуть-более сложным sql-запросом решить. И еще одно: вы бд мониторите? На сколько эффективно оперативка используется? А то всего 4vCPU на 32GiB - возможно перекос по ресурсам (хотя это сильно зависит от вашей системы).

Если у вас внутри node уже есть пулы соединений, то зачем ещё один? Поднастройте те, что уже есть по минимальному размеру и допустимому периоду неактивности до закрытия соединения. Про пулы в ноде точно не знаю, но в сервисе на любом Ява фреймворке это легко настраивается, подозреваю что и в ноде тоже.

Запросы оптимизируем, есть еще пару мест где можно добиться уменьшения количества запросов. БД мониторим, в оперативке держаться весь нужный датасет.

Проблема в том, что каждая отдельная реплика nodejs использует свой отдельный пул, который суммируется и приводит к большому общему количеству открытых соединений к БД. А это крайне неоптимально: из тех рекомендаций что я видел, к БД должен быть открыто небольшое количество соединений, а перед ними пул, на который будут блокироваться приходящие запросы и ждать свободного соединения

Если она использует все соединения из пула - то добавление ещё одного пула не решит проблему, если соединения в пуле простаивают - это лечится настройками пула.

Вы меня видимо не понимаете. Дополнительный пул перед БД будет менеджить небольшое количество реальных конекшенов к бд. Все мои NodeJS приложениям будут соединяться с этим пулом и выполнять запросы. Это поможет ограничить количество реальных конекшенов к бд, а каждое nodejs сможет открыть большое количество дешевых конекшенов к proxy

Схему я понимаю. Но не понимаю чем она вам поможет - если у вас одновременно в работе 100 запросов, то у вас будет 100 реальных соединений к БД, как бы вы их не проксировали. Если у вас одновременно в работе 10 запросов, а реальных соединений к БД 100 - то у вас, скорее всего, неправильно настроены пулы в node.

У меня сотни нод с пулом 5-20, тысячи запросов к БД в секунду

Сделайте размер пула 0-10, отстрел соединения через несколько секунд неактивности. Если дело в кол-ве соединений то это, скорее всего, поможет.

Пгбаунсер надо использовать очень аккуратно. Не всегда он спасает, под него настраивать jdbc драйвер точно придется. Или что там у вас за соединение с сервером отвечает.

А как именно настраивать jdbc под баунсер, можете подсказать?

Зависит от приложения. У меня была проблема с препаред стейтмент