2016-07-31 8 views
4

При настройке DBCP2 бассейна и на основе documentation я заметил, что - есть конфигурация называется timeBetweenEvictionRunsMillis, которая описана как:DBCP2 - Когда Idle соединение удаляется из пула

Количество миллисекунд, чтобы спать между пробеги незанятого объекта evictor thread. Когда неположительный, ни одна простаивающая тема evictor не будет запущена .

Его значение по умолчанию - -1.

Означает ли это, что поток evictor никогда не будет работать в конфигурации по умолчанию? Затем, как применяется параметр конфигурации maxIdle - пул должен выходить из простоя, если их количество больше maxIdle.

Мне кажется очень запутанным, что конфигурация по умолчанию такова, что незанятые соединения никогда не выселяются.

Существует также другая конфигурация softMiniEvictableIdleTimeMillis, которая, кажется, играет определенную роль в верхней части timeBetweenEvictionRunsMillis.

Любые разъяснения в этом отношении окажут огромную помощь.

На данный момент я настраиваю пул, как показано ниже, поскольку моя цель - не иметь никаких простоя подключений в моем пуле слишком долго (это было необходимо, поскольку мы используем AWS RDS и, кажется, a weird issue с ним которые мы часто используем)

BasicDataSource dataSource = new BasicDataSource(); 
    dataSource.setDriverClassName("com.mysql.jdbc.Driver"); 
    dataSource.setUrl(properties.getProperty("app.mysql.url")); 
    dataSource.setUsername(properties.getProperty("app.mysql.username")); 
    dataSource.setPassword(properties.getProperty("app.mysql.password")); 
    dataSource.setMaxIdle(20); 
    dataSource.setMaxWaitMillis(20000); //wait 10 seconds to get new connection 
    dataSource.setMaxTotal(200); 
    dataSource.setMinIdle(0); 
    dataSource.setInitialSize(10); 
    dataSource.setTestOnBorrow(true); 
    dataSource.setValidationQuery("select 1"); 
    dataSource.setValidationQueryTimeout(10); //The value is in seconds 

    dataSource.setTimeBetweenEvictionRunsMillis(600000); // 10 minutes wait to run evictor process 
    dataSource.setSoftMinEvictableIdleTimeMillis(600000); // 10 minutes wait to run evictor process 
    dataSource.setMinEvictableIdleTimeMillis(60000); // 60 seconds to wait before idle connection is evicted 
    dataSource.setMaxConnLifetimeMillis(600000); // 10 minutes is max life time 
    dataSource.setNumTestsPerEvictionRun(10); 

ответ

5

Да, поток evictor не будет запускаться по умолчанию. Причина в том, что значения maxIdle и maxTotal по умолчанию совпадают, что означает, что соединения не будут немедленно закрыты, и нет необходимости в выводе простоя. Таким образом, пул просто сохраняет некоторые ресурсы, не используя бесполезный поток.

Но когда вы меняете maxIdle и делаете его ниже maxTotal без запуска потока evictor, это не означает, что ваши соединения не будут закрыты. Это означает, что они будут закрыты сразу же после отпускания без задержки, пока их счет не упадет до maxIdle.

А потом minEvictableIdleTimeMillis и softMinEvictableIdleTimeMillis приходят играть (быть осторожным, есть опечатка в документации, это ...MinEvictalbe..., не ...MiniEvictable...). Разница между ними заключается в том, что первый не уважает minIdle, а последний делает. Это немного сложно, учитывая тот факт, что softMinEvictableIdleTimeMillis проверяется только после того, как прошло minEvictableIdleTimeMillis.

Предположим, что у нас есть minEvictableIdleTimeMillis=10000 и softMinEvictableIdleTimeMillis=-1 (по умолчанию). В этом случае незанятое соединение останется в пуле не более 10 секунд. Даже если количество соединений не превышает minIdle, оно будет закрыто. Если это приведет к уменьшению количества подключений ниже minIdle, новое соединение будет создано немедленно.

Предположим, что у нас есть minEvictableIdleTimeMillis=10000 и softMinEvictableIdleTimeMillis=30000. В этом случае простаивающее соединение после проверки на minEvictableIdleTimeMillis и обнаружение превышения будет дополнительно проверено на softMinEvictableIdleTimeMillis. Если время простоя превышает его, соединение будет закрыто.В противном случае он будет сидеть в бассейне до следующей положительной проверки против minEvictableIdleTimeMillis.

В конце концов, вы будете иметь связь между maxTotal и maxIdle закрыты немедленно, связи между maxIdle и minIdle закрыты после minEvictableIdleTimeMillis и связи между minIdle и 0 закрыты после softMinEvictableIdleTimeMillis и возобновлялось сразу. Дайте или возьмите период проверки выселения.

С вашей конфигурацией у вас будут все соединения закрыты сразу же, когда пул будет больше 20. И эти 20 соединений будут жить от 10 до 20 минут (даже если они простаивают), потому что у вас есть 10 минут как EvictableIdleTimeMillis плюс 10 минут TimeBetweenEvictionRunsMillis.

Я хотел бы также упомянуть потенциальную проблему с большим зазором между maxIdle и maxTotal. Если вы ожидаете, что maxIdle будет превышено очень часто, лучше его увеличить. В противном случае вы столкнетесь с постоянными открытиями и закрытиями соединений, которые создадут дополнительное давление на вашу базу данных (поскольку установление нового соединения db является относительно тяжелой операцией) и сетевой инфраструктуры сервера приложений (поскольку закрытые соединения будут зависать в статусе TIME_WAIT, обновляя ваши сетевые порты бассейн).

+0

Благодарим за подробную информацию. Эти незадействованные соединения в течение 10-20 минут окна - будут ли они повторно использоваться пулом соединений? Я предполагаю, что они будут повторно использованы. В вашем втором примере, когда вы говорите «Если время простоя превышает это» ... вы имеете в виду, что оно превышает 10000 + 30000? –

+0

Спасибо, я прочитал ваше редактирование сейчас. Довольно ясно сейчас, –

+0

@Wand Marker, пожалуйста. Что касается повторного использования соединения, если я правильно понял вопрос, конечно, пул будет их повторно использовать, если он им понадобится, и «таймер простоя» будет сброшен. –

 Смежные вопросы

  • Нет связанных вопросов^_^