db {
 default {
   url="jdbc:postgresql://master-db:9999/project"
   driver = org.postgresql.Driver
   username = ***
   password = ***
   logSql = true
   hikaricp {
     poolName="default"
     autoCommit=true
     maximumPoolSize=50
     connectionTestQuery="SELECT 1"
     connectionTimeout=15000
     idleTimeout=60000 #5 min for idle connection to be closed
     maxLifetime=180000 #10 min for connection life
     leakDetectionThreshold=300000 #15min. время которое коннект может быть вне пула, более уже утечка
     minimumIdle=1
     registerMbeans=true
   }
   jndiName = MainDS
 }
 slave {
   url="jdbc:postgresql://slave1:8888/project"
   driver = org.postgresql.Driver
   username = ***
   password = ***
   logSql = true
   hikaricp {
     poolName="slave"
     autoCommit=true
     maximumPoolSize=50
     connectionTestQuery="SELECT 1"
     connectionTimeout=15000
     minimumIdle=1
     registerMbeans=true
     readOnly=true
   }
   jndiName = SlaveDS
 }
}

печально, если это утечка hikari

а второй pool (slave) нормально работает в это время?

По конфигу default в простое, после idleTimeout, количество коннектов должно сократиться до одного. Программно в коде minimumIdle нигде не задаётся?

нет, конфиг программно не меняется

да.

Тогда я бы добавил отладочку в виде https://github.com/brettwooldridge/HikariCP/wiki/MBean-(JMX)-Monitoring-and-Management раз в 15 минут в лог. И посмотрел pg_top.

Кстати, вся работа с БД идёт через ORM? Hibernate?

да, hibernate jpa

это есть. я через него и вижу кол-во

Я подозреваю, что hibernate держит эти коннекты, но без кода, pg_stat_activity или pg_top адекватно судить не могу. ;) Есть деструктивный подход к анализу подобных утечек - ограничение максимального времени сессии. Если логирование настроено подобающим образом, вывалится "несколько" исключений. Опции на постгресе statement_timeout, idle_in_transaction_session_timeout.

возьму на вооружение)

пока пытаюсь из heapdump что-то получить. было бы хорошо если найти какой запрос бы последним. и от него уже отталкиваться.

У меня подобное поведение было на EBean ORM + c3po. Я решал через анализ суточной активности pgbadger-ом.

интересно. и как вы нашли проблемное место?

По факту проверки проблемных мест было много. От наличия кусков кода с кастомными SQL запросами в обход ORM, без вызова close(). До наличия огромного количества eager fetching запросов. Плюс вызов хранимых процедур из БД, написанных аналитиками для отчётов в ireport... которые выполнялись по 2ч и их можно было понатыкать неограниченно. И да, много где там не хватало индексов. Профилирование было комплексным, что сократило потребление ОЗУ в 3 раза, снизило нагрузку на БД на порядок и устранило необходимость в сервисных перезагрузках. Использовалось много утилит. Но самые решающие -  Mission control + fly record и pgbadger.

с openjdk проблем не будет?

Прежде всего, нужно запустить приложение со следующими флагами JVM:
-XX:+UnlockCommercialFeatures
-XX:+FlightRecorder

Не используйте эти опции на production системе без приобретения специальной лицензии Oracle!

насколько критично предупреждение о лицензии?

Java Flight Recorder (JFR) used to be a commercial add-on of the Oracle JDK. As it’s been open sourced along with Java Mission Control, everyone using OpenJDK 11 can now troubleshoot their Java apps with this excellent tool for free of charge.

Возможно я не прав, не имею знаний в юридических делах. @tairs  Возможно имеет другие мысли по этому поводу?