web-dev-qa-db-ja.com

DBCP2-アイドル接続がいつプールから削除されるか

DBCP2プールの構成中に、 documentation に基づいて、次のように説明しました-timeBetweenEvictionRunsMillisという構成があることに気付きました。

アイドルオブジェクトEvictorスレッドの実行間でスリープするミリ秒数。正でない場合、アイドルオブジェクトEvictorスレッドは実行されません。

デフォルト値は-1。

これは、Evictorスレッドがデフォルト構成で実行されないことを意味しますか？次に、構成パラメータmaxIdleはどのように適用されますか？カウントがmaxIdleより大きい場合、プールはアイドル接続を削除する必要があります。

デフォルトの構成では、アイドル接続が削除されないようになっているので、非常に混乱しています。

softMiniEvictableIdleTimeMillisの上で何らかの役割を果たすように見える別の構成timeBetweenEvictionRunsMillisもあります。

この点に関する明確化は非常に役立ちます。

とりあえず、私は以下のようにプールを構成しています-私の目標は、プールにアイドル接続が長時間存在しないようにすることです（これはAWS RDSを使用しているため必要でした 奇妙な問題 私たちが頻繁に実行しているそれで）

    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);
javaconnection-poolingapache-commons-dbcp
12
Wand Maker

はい、Evictorスレッドはデフォルトでは実行されません。その理由は、maxIdleとmaxTotalの値はデフォルトで同じであるため、すぐに閉じる接続がなく、アイドル状態の接続を排除する必要がないためです。したがって、プールは役に立たないスレッドを実行しないことにより、一部のリソースを節約するだけです。

ただし、Evictorスレッドを開始せずにmaxIdleを変更してmaxTotalより低くしても、接続が閉じられないわけではありません。つまり、解放後すぐに、カウントが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分間のEvictableIdleTimeMillisと10分間のTimeBetweenEvictionRunsMillisがあるため、10〜20分（アイドル状態でも）存続します。

maxIdleとmaxTotalの間に大きなギャップがある潜在的な問題についても触れたいと思います。 maxIdleを頻繁に超えることが予想される場合は、増やすことをお勧めします。そうしないと、接続の開始と終了が絶え間なく発生し、データベース（新しいdb接続の確立は比較的負荷の高い操作であるため）とアプリサーバーのネットワークインフラストラクチャ（接続が終了するとTIME_WAITステータスでハングし、ネットワークポートが枯渇するため）になります。プール）。

14
Andrew Lygin