Пул соединений HikariCP - «активный» - как отлаживать? - PullRequest
Новая
       10

Пул соединений HikariCP - «активный» - как отлаживать?

0 голосов
/ 30 мая 2018

Я создаю приложение, используя Spring-Boot / Hibernate с Postgres в качестве базы данных.Я использую Spring 2.0, поэтому Hikari является поставщиком пула соединений по умолчанию.

В настоящее время я пытаюсь выполнить нагрузочное тестирование приложения с конечной точкой REST, которая выполняет функцию update-if-существующие, и вставьте, еслиновый для сущности в базе данных.Это довольно маленькая сущность с первичным ключом 'BIGSERIAL' и без каких-либо ограничений на любое другое поле.

Размер пула соединений по умолчанию равен 10, и я на самом деле не настраивал другие параметры - ни HikariCP, ни Postgres.

Точка, в которой я застрял на данный момент, заключается в отладке соединений в «активном» состоянии и в том, что они делают или почему они зависают в данный момент.

Когда я запускаю '10 одновременных пользователей', это в основном переводит в 2 или 3 раза больше запросов, и поэтому, когда я включаю журналы отладки HikariCP, он зависает примерно так: (total=10, active=10, idle=0, waiting=2) и «активные» соединения на самом деле не освобождают соединения, чтоТо, что я пытаюсь выяснить, потому что запросы довольно просты, а сама таблица состоит из 4 полей (включая первичный ключ).

Как правило, лучшие практики HikariCP - это увеличение пула соединений.не правильный первый шаг к масштабированию.

Если я увеличу размер пула подключений до 20, все начнёт работать для 10 одновременных / одновременных пользователей, но опять же, это не является основной причиной / решением проблемы, которую я считаю.

есть ли способ регистрировать сообщения Hibernate или Postgres, которые могут помочь узнать, что ждут эти «активные» соединения и почему соединение не освобождается даже после увеличения времени ожидания до долгого времени?

Если это утечка соединения (как сообщается, когда leak-detection-threshold уменьшается до более низкого значения (например, 30 секунд)), то как я могу определить, отвечает ли Hibernate за эту утечку соединения или это что-тоеще?

Если это блокировка / ожидание на уровне базы данных, как я могу получить корень этого?

ОБНОВЛЕНИЕ После помощи @brettw я взялсброс потока, когда соединения были исчерпаны, и он указал в направлении утечки соединения.Потоки на HikariCP выдают плату - https://github.com/brettwooldridge/HikariCP/issues/1030#issuecomment-347632771 - которая указывает на то, что Hibernate не закрывает соединения, а затем указывает на https://jira.spring.io/browse/SPR-14548,, который говорит о настройке режима закрытия соединения Hibernate, так как режим по умолчанию удерживает соединение слишкомдолго.После установки spring.jpa.properties.hibernate.connection.handling_mode=DELAYED_ACQUISITION_AND_RELEASE_AFTER_TRANSACTION пул соединений работал отлично.

Кроме того, указанная здесь точка - https://github.com/brettwooldridge/HikariCP/issues/612#issuecomment-209839908 верна - утечка соединения не должна покрываться пулом.

1 Ответ

0 голосов
/ 31 мая 2018

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

Кроме того, я бы попробовал простой дамп потока, чтобы увидеть, где все потоки заблокированы.Это может быть тупик синхронизации на уровне кода.

  • Если все потоков заблокированы на getConnection(), это утечка.
  • Если всеиз потоков не работает в драйвере, в соответствии с трассировкой стека для каждого потока, это тупик базы данных.
  • Если все потоки заблокированы в ожидании блокировки в коде вашего приложения, то у вас есть синхронизацияdeadlock - вероятно, две блокировки с инвертированным порядком получения в разных частях кода.

HikariCP leakDetectionThreshold может быть полезен, но он будет показывать только то, где было получено соединение, а не то место, где в данный момент находится поток.застрял.Тем не менее, это может дать подсказку.

...