How to configure jedisPool parameters in redis
maxWait When the connection in the connection pool is exhausted, the new request wait time, milliseconds
timeBetweenEvictionRunsMillis timeBetweenEvictionRunsMillis is used together with minEvictableIdleTimeMillis, every time
timeBetweenEvictionRunsMillis milliseconds checks the idle connections in the connection pool once, and disconnects the connections whose idle time exceeds minEvictableIdleTimeMillis milliseconds until the number of connections in the connection pool reaches minIdle
minEvictableIdleTimeMillis The time when the connection in the connection pool can be idle, milliseconds
removeAbandoned true, false, whether to clean up active connections that are not used in removeAbandonedTimeout seconds, and not put back into the connection pool after cleaning
removeAbandonedTimeout Maximum idle time for active connections
logAbandoned true, false, whether to print a message when the connection pool reclaims idle active connections
The two parameters minEvictableIdleTimeMillis and removeAbandonedTimeout are for different connection objects, minEvictableIdleTimeMillis is for connection objects in the connection pool, and removeAbandonedTimeout is for active connections that have not been closed.
When configuring, the main difficult to understand are: removeAbandoned, logAbandoned, removeAbandonedTimeout, maxWait these four parameters, set rmoveAbandoned=true, then when getNumActive() is about to getMaxActive(), the system will recycle invalid connections. The recovered Connection is the Connection that is not used after the number of seconds set in removeAbandonedTimeout (default 300 seconds), and the activation recovery mechanism seems to be getNumActive()=getMaxActive()-2. :) If logAbandoned=true, the error message of reclaiming the Connection will be printed in the log after the recovery event, including where the Connection was used but forgot to close, which is very useful when debugging.
Here, it is suggested that the maxWait time should not be set too long. If maxWait is set too long, the client will wait for a long time before triggering the recycling event.
http://blog.csdn.net/feiyu8607/article/details/6551991
validationQuery
The validationQuery parameter provided by DBCP is used to pre-detect the connection. It will add some hooks in the process of interacting with the connection pool, and execute the SQL statement specified by the validationQuery at a fixed point. If the SQL statement is executed successfully, it means that the connection is valid and assigned to the application. If it fails, the connection will be discarded. This method can also deal with the problem of MySQL connection failure caused by network failures and other problems. Some other methods, such as idle connection detection, optimistic connection acquisition, etc., cannot be guaranteed to be completely transparent to the application, and the application can still perceive the failure of the database operation.
minEvictableIdleTimeMillis
The time when the connection in the connection pool has been idle for a period of time and is expelled from the connection pool
timeBetweenEvictionRunsMillis
When constructing GenericObjectPool [BasicDataSource also uses GenericObjectPool in its createDataSource () method], an embedded class Evictor is generated, which implements the Runnable interface. If timeBetweenEvictionRunsMillis is greater than 0, Evictor will call the evict() method every timeBetweenEvictionRunsMillis milliseconds to check whether the idle time of the connection in the connection pool is greater than minEvictableIdleTimeMillis milliseconds (ignore when _minEvictableIdleTimeMillis is less than or equal to 0, the default is 30 minutes), and if so, destroy the object , and then call the ensureMinIdle method to check to ensure that the number of objects in the pool is not less than _minIdle. If the number of connections in the connection pool is less than the minimum number of idle connections, create a database connection and check whether the connection in the connection pool is less than maxIdle. If yes, put the newly created connection into the connection pool, otherwise destroy the object.
http://blog.csdn.net/qyy333/article/details/17920051
https://github.com/xetorthio/jedis/issues/937
How to configure jedisPool parameters in redis
The configuration parameters of JedisPool largely depend on the actual application requirements, software and hardware capabilities, and most of the configuration parameters of JedisPool are assigned by the corresponding items of JedisPoolConfig.
maxActive: controls how many jedis instances can be allocated to a pool, obtained through pool.getResource(); if the value is -1, it means there is no limit; if the pool has allocated maxActive jedis instances, the status of the pool at this time becomes exhausted, in JedisPoolConfig
maxIdle: Controls the maximum number of jedis instances with idle status in a pool;
whenExhaustedAction: Indicates the action to be taken by the pool when all jedis instances in the pool are allocated; by default, there are three types of WHEN_EXHAUSTED_FAIL (indicating that no jedis instance is directly thrown NoSuchElementException), WHEN_EXHAUSTED_BLOCK (meaning blocking, or throwing when maxWait is reached) JedisConnectionException), WHEN_EXHAUSTED_GROW (meaning to create a new jedis instance, which means that the set maxActive is useless);
maxWait: Indicates the maximum waiting time when borrowing a jedis instance. If the waiting time is exceeded, JedisConnectionException will be thrown directly;
testOnBorrow: Whether to perform the validate operation in advance when borrowing a jedis instance; if true, the obtained jedis instances are all available;
testOnReturn: Whether to perform the validate operation in advance when returning to the pool;
testWhileIdle: If true, it means that there is an idle object evitor thread to scan the idle object. If the validate fails, the object will be dropped from the pool; this item is meaningful only when timeBetweenEvictionRunsMillis is greater than 0;
timeBetweenEvictionRunsMillis: Indicates the number of milliseconds to sleep between two scans of the idle object evitor;
numTestsPerEvictionRun: Indicates the maximum number of objects scanned by idle object evitor each time;
minEvictableIdleTimeMillis: Indicates that an object stays in the idle state for at least the shortest time before it can be scanned and expelled by the idle object evitor; this item is only meaningful when timeBetweenEvictionRunsMillis is greater than 0;
softMinEvictableIdleTimeMillis: On the basis of minEvictableIdleTimeMillis, at least minIdle objects are added that are already in the pool. If -1, evicted will not evict any objects based on idle time. If minEvictableIdleTimeMillis>0, this setting is meaningless, and only meaningful when timeBetweenEvictionRunsMillis is greater than 0;
lifo: When borrowObject returns an object, it uses DEFAULT_LIFO (last in first out, that is, the most frequently used queue similar to cache), if it is False, it means a FIFO queue;
The default settings of JedisPoolConfig for some parameters are as follows:
testWhileIdle=true
minEvictableIdleTimeMills = 60000
timeBetweenEvictionRunsMillis = 30000
numTestsPerEvictionRun=-1
http://www.2cto.com/database/201311/254449.html
+
+
=
=
=
+