В банковской системе с нагрузкой 500–3000 RPS на чтение и 50–300 RPS на запись увеличение maximumPoolSize с 10 до 50 привело к деградации производительности. База данных не справлялась с конкуренцией за ресурсы между сотнями соединений. После снижения размера пула до 15 соединений на инстанс задержки нормализовались, а база перестала перегружаться.
На enterprise-платформе модуль генерации документов вызывал утечки соединений: метод с аннотацией @Transactional удерживал соединение до 40 секунд, ожидая завершения рендера через LibreOffice. Проблему решили разделением операций с БД и тяжелого I/O на разные транзакции, а также включением параметра leak-detection-threshold для отслеживания подобных ситуаций.
В банковском контуре сетевой экран разрывал простаивающие TCP-соединения через 15 минут, тогда как HikariCP считал их валидными до 30 минут. Это приводило к ошибкам 'Connection reset'. Инженеры настроили max-lifetime на 600 000 мс (10 минут) и активировали keepalive-time на 120 000 мс, чтобы поддерживать активность соединений.
Использование PgBouncer в режиме transaction pooling вызывает ошибки при работе с серверными prepared statements, так как соединение с БД меняется между транзакциями. Решением стало отключение серверных prepared statements на стороне драйвера через параметр prepareThreshold=0 или перевод пулера в режим session mode.
