Неиспользуемые соединения DBCP2 BasicDataSource не очищаются

я вижу, что Idle-соединения не очищаются. Я не уверен, в чем причина?

InitialSize-10 maxtotal-20 maxidle-10 minidle-0 minEvictableIdleTimeMillis-30min numTestsPerEvictionRun-60min numTestsPerEvictionRun-20 testOnBorrow-true testWhileIdle-true validationQuery-выберите 1 из двойного

Из различных источников я понимаю, что maxtotal-maxactive подключений к источнику данных равно 20 в приведенном выше случае.

maxidle — количество незанятых соединений, которые могут оставаться в пуле. они удаляются подметальной машиной. В приведенном выше случае соединение простаивает, если оно остается бездействующим в течение 30 минут. Если подметальная машина запускается каждые 60 минут, она проверяет 20 незанятых соединений и очищает неиспользуемые соединения. Бездействующие соединения, превышающие это значение, будут немедленно закрыты.

Верно ли приведенное выше понимание?

Я использую BasicDataSourceMXBean для печати статистики

{"NumActive":"0","NumIdle":"10","isClosed":"false","maxTotal":"20","MaxIdle":"10","MinIdle":"0"}

Бездействующие соединения никогда не очищаются, даже если трафика нет. Что-то не так в приведенной выше конфигурации?

Также что такое minIdle и когда мы должны установить для него ненулевое значение?

Недавно обновлена ​​версия гибернации с 3.6.0.Final до 4.3.11.Final и весна до 4.2.9 из более старой весенней версии.

Раньше неиспользуемые соединения очищались. Но после обновления неиспользуемые соединения не очищаются.


spring hibernate jdbc database-connection apache-commons-dbcp
person Anonymous7    schedule 08.03.2017    source источник
comment
Вы уверены, что параметр не должен быть testWhileIdle, а не testOnIdle, чтобы неиспользуемые соединения были исключены?   -  person Naros    schedule 09.03.2017

Ответы (2)


arrow_upward
0
arrow_downward

Везде, где я смотрел, кажется, что свойство должно быть testWhileIdle, а не testOnIdle. По умолчанию установлено значение false, поэтому ваши бездействующие потоки не проверяются на достоверность и, следовательно, не удаляются.

minIdle в основном сообщает пулу соединений, сколько допустимых бездействующих потоков. Насколько я понимаю из документации, когда minIdle равно 0, не должно быть свободных соединений.

Обычно minIdle по умолчанию имеет то же значение, что и initialSize.

person Naros    schedule 09.03.2017
comment
его testWhileIdle. Я до сих пор не понимаю, почему через 90 минут появляются незанятые соединения. Есть ли какой-нибудь сценарий, в котором неиспользуемые соединения никогда не будут очищены? - person Anonymous7; 09.03.2017

arrow_upward
0
arrow_downward

я вижу, что Idle-соединения не очищаются. Я не уверен, в чем причина?

https://commons.apache.org/proper/commons-dbcp/configuration.html

Проблема testWhileIdle и testOnIdle, на которую указывали другие, должна решить ваш вопрос о том, почему простаивающие соединения остаются открытыми. Вы правы, предполагая, что ваши соединения initialSize=10 будут очищены чистильщиком выселения на отметке 60 минут, чтобы привести вас к minIdle=0. Почему вы хотели бы иметь minIdle=0, это другой вопрос? Весь смысл пула соединений на самом деле заключается в предварительной аутентификации, тестировании и установлении ваших соединений, чтобы они могли находиться в вашем пуле «в режиме ожидания» и доступны для «заимствования» по входящим запросам. Это повышает производительность за счет сокращения времени выполнения до сеанса SQL.

Также что такое minIdle и когда мы должны установить для него ненулевое значение?

Эти простаивающие соединения будут предварительно устанавливать и поддерживать ожидание ваших будущих запросов SQL. Размер minIdle зависит от вашего приложения, но значение по умолчанию для DBCP2 равно 8 и, вероятно, неплохое место для начала. Идея состоит в том, чтобы держать под рукой достаточно средств, чтобы не отставать от среднего спроса на пул. Вы должны установить maxIdle, чтобы иметь дело с теми пиковыми периодами, когда у вас есть всплески трафика. Конфигурация testWhileIdle=true, которую вы применили, будет запускать validationQuery, когда появится подметальная машина, но по умолчанию будет проверяться только 3 соединения за один запуск. Вы можете настроить numTestsPerEvictionRun на более высокое число, если хотите протестировать больше. Эти «тесты» гарантируют, что ваши соединения все еще находятся в хорошем состоянии, чтобы вы не захватили «плохое» незанятое соединение из пула во время выполнения.

Я подозреваю, что вас больше беспокоят "зависшие" соединения, чем "бездействующие". Если это так, вам нужно просмотреть «заброшенные» конфигурации, предназначенные для уничтожения «активных» соединений, которые работают дольше X времени. removeAbandonedOnMaintenance=true вместе с removeAbandonedTimeout={numberOfSecondsBeforeEligibleForRemoval}.

person Jason Hill    schedule 20.03.2017